Announcement

Collapse
No announcement yet.

VP8/VP9's libvpx 1.13.1 Released Due To A High Severity Vulnerability

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by M@yeulC View Post
    What's the advantage of generating Rust code? The original language needs to be memory-safe as well (unless it's leaning on the Rust compiler, bit in that case you're almost writing Rust already). If you have that, you can directly generate LLVI IR or whatnot (even the C code should be safe...).
    It's an order of magnitude easier to cross-compile pure Rust projects than Rust projects that also depend on C libraries beyond just libc. Same as with Go vs. cgo.

    (Bear in mind that statically linking musl-libc for a Linux binary that depends only on the kernel's syscall interface also counts as cross-compiling.)

    Comment


    • #12
      Originally posted by peterdk View Post
      I expect that in the long run people/companies will require that codecs are written in memory safe languages.
      This might not be related at all, but this reminds me of https://github.com/GrapheneOS/hardened_malloc

      Comment


      • #13
        There isn't a magic bullet that stops security problems. You need to invest in code reviews and improvements (so that people don't misuse it/break it in future).

        Yes, even if you write it in Rust... If your API returns "0 fail, 1 success, -1 error" someone is going to do the wrong thing eventually...

        Comment


        • #14
          Originally posted by OneTimeShot View Post
          There isn't a magic bullet that stops security problems. You need to invest in code reviews and improvements (so that people don't misuse it/break it in future).

          Yes, even if you write it in Rust... If your API returns "0 fail, 1 success, -1 error" someone is going to do the wrong thing eventually...
          *nod* When I came to Rust from Python, it wasn't for greater memory safety, it was for the increased ability to teach the type system to watch my back through good design.

          Comment


          • #15
            Originally posted by peterdk View Post
            I expect that in the long run people/companies will require that codecs are written in memory safe languages.
            What a tangled web of canned worms you weaved there ;-)

            Tools are instruments we select and use to make our task "better" by some metric. "Better" could mean faster, more reliable, more replicable ("repeatable"), cheaper, documentable, etc. The selection of the tool and the method of its use is typically done by the person performing the task. That would mean that a programmer chooses his/her tools.

            YOU have implied that YOU prioritize "memory-safe languages" [hyphen mine] and in so doing YOU prioritize that over other potential project goals such as, for example, codebase size, internal comments and documentation, supportability*, and price.

            Fundamentally, good coding technique, rigor, and training are more important in all languages --computer or not-- --compiled or assembled or machined-- wihout regard for the choice of compiler or language used. There's nothing wrong with C, C++, C#, BCPL, Rust, etc. Some of these lend themselves to obfuscation. (See e.g. the annual obfuscated C contest). Some do not. Either way, it's the choice of the programmer just like it's the choice of the digging crew which earth excavating machine to use based on the specific project requirements.

            Whatever tool (language, compiler, IDE) you choose, maintain a docuemtation cadence so everything is documented to the max. Just because you prefer a shovel doesn't mean the guy who comes behind you with a backhoe will know where not to dig up buried fiber-optic conduit...

            E

            * I'm sitting here at a lunch table with three other guys, all experienced coders all making very nice six-figures a year. Your comment (above) got a chuckle and some nods but nobody said "Oh yeah I'll switch all my coding to rust." There was no explicit "I won't use rust" but the concensus was that we'll use the right tool for the job.

            Comment


            • #16
              Originally posted by gavron View Post

              What a tangled web of canned worms you weaved there ;-)

              Tools are instruments we select and use to make our task "better" by some metric. "Better" could mean faster, more reliable, more replicable ("repeatable"), cheaper, documentable, etc. The selection of the tool and the method of its use is typically done by the person performing the task. That would mean that a programmer chooses his/her tools.

              YOU have implied that YOU prioritize "memory-safe languages" [hyphen mine] and in so doing YOU prioritize that over other potential project goals such as, for example, codebase size, internal comments and documentation, supportability*, and price.

              Fundamentally, good coding technique, rigor, and training are more important in all languages --computer or not-- --compiled or assembled or machined-- wihout regard for the choice of compiler or language used. There's nothing wrong with C, C++, C#, BCPL, Rust, etc. Some of these lend themselves to obfuscation. (See e.g. the annual obfuscated C contest). Some do not. Either way, it's the choice of the programmer just like it's the choice of the digging crew which earth excavating machine to use based on the specific project requirements.

              Whatever tool (language, compiler, IDE) you choose, maintain a docuemtation cadence so everything is documented to the max. Just because you prefer a shovel doesn't mean the guy who comes behind you with a backhoe will know where not to dig up buried fiber-optic conduit...

              E

              * I'm sitting here at a lunch table with three other guys, all experienced coders all making very nice six-figures a year. Your comment (above) got a chuckle and some nods but nobody said "Oh yeah I'll switch all my coding to rust." There was no explicit "I won't use rust" but the concensus was that we'll use the right tool for the job.
              Funny stance, given that we're already seeing browsers slowly migrating their parsers/codecs into memory-safe languages because they're one of the biggest attack surfaces. (What with being the boundary where you ingest and validate/sanitize untrusted input and all.)

              One of the less talked-about things in Mozilla's Oxidation effort is that the very first Firefox component to be rewritten in Rust was the MP4 parser, back in 2017.

              Likewise, I can't remember if it's shipped yet, but Microsoft was rewriting Windows font parsing in Rust last year.
              Last edited by ssokolow; 01 October 2023, 09:51 PM.

              Comment


              • #17
                Originally posted by ssokolow View Post
                ...
                Likewise, I can't remember if it's shipped yet, but Microsoft was rewriting Windows font parsing in Rust last year.

                The link in the article is from "learn.microsoft.com" and the code example is dissected well by the redditors. I'm sure MS is looking at Rust and if that's the right tool to help correct the issues (the fonts parser was 0-dayed 3 times) then good on them.

                I'll save my criticism on how this ever passed code review (see reddit comments) or why MS chose to change the source language rather than just fire the coder and put someone competent on it. It's a simple iterative search and is done every day by everything from SQL queries to 'ls', 'dir', etc. without a 0-day hole. But then, the #1 attack vector target that has directly lead to the malware/ransomware industry is MS Windows.

                Comment


                • #18
                  Originally posted by gavron View Post
                  https://www.reddit.com/r/rust/commen..._windows_font/
                  The link in the article is from "learn.microsoft.com" and the code example is dissected well by the redditors. I'm sure MS is looking at Rust and if that's the right tool to help correct the issues (the fonts parser was 0-dayed 3 times) then good on them.
                  The source I'm remembering was a talk being given by a Microsoft employee.

                  Comment


                  • #19
                    CVE-2023-5217 is due to a heap buffer overflow within the VP8 encoding path in libvpx used by Google Chrome.
                    Ok, this makes sense. Send a malicious sequence to the encoder, it craps out, you get to where you're not supposed to.

                    ith prior Chrome versions and pre-1.13.1 for libvpx, a remote attacker could potentially exploit heap corruption via a specially crafted HTML page.
                    Wait, what? A web page that tells my browser to encode things? Wth? I mean, it's possible, technically, but who really visits page that make them encode video?

                    Comment


                    • #20
                      Originally posted by M@yeulC View Post
                      If you are looking for a C/C++ successor, Zig has gained quite a bit of traction in some fields like embedded.
                      Wow, thanks.
                      I heard of Zig, for some reason I thought it's a toy language for low level stuff. But now that I see that structs can have methods... it's very close to what I actually wanted (Rust without ownership). And from what I read it has plenty of (unexpected to me) cool stuff thanks to being a new modern language on top of modern compiler stacks.

                      Comment

                      Working...
                      X