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

  • ssokolow
    replied
    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.

    Leave a comment:


  • OneTimeShot
    replied
    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...

    Leave a comment:


  • KoenDG
    replied
    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

    Leave a comment:


  • ssokolow
    replied
    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.)

    Leave a comment:


  • ssokolow
    replied
    Originally posted by cl333r View Post

    I did program in Rust for like a year and while initially a big fan, eventually I came to the conclusion that I'd much prefer a new successor to C++ which hopefully Carbon will be.

    Though Rust in its own right is a good lang that easily gets out of control.
    I use Rust as "A replacement for Python with stronger compile-time type-safety guarantees, easier deployment, and an ecosystem more ideologically aligned with 'if it compiles/installs/works today, it'll continue to do so in five or ten years" (and I think of it as "Haskell without the bad parts"), I'm a liberal use of #![forbid(unsafe_code)] in my own projects, and I have high standards for what I consider acceptable use and responsible implementation of unsafe in dependencies I choose to add to my project.

    I think C and assembly language are the only things further from what I'd want to use in my general day-to-day programming than C++ and Carbon. (Bear in mind that I say "in my general day-to-day programming". I do use Open Watcom C/C++ for DOS retro-hobby programming.)

    Leave a comment:


  • M@yeulC
    replied
    pWe00Iri3e7Z9lHOX2Qx so you are telling me this is yet another vulnerability? Otherwise yeah, poorly disclosed and coordinated.

    Originally posted by cl333r View Post

    I did program in Rust for like a year and while initially a big fan, eventually I came to the conclusion that I'd much prefer a new successor to C++ which hopefully Carbon will be.

    Though Rust in its own right is a good lang that easily gets out of control.
    If you are looking for a C/C++ successor, Zig has gained quite a bit of traction in some fields like embedded.

    Originally posted by ssokolow View Post

    I'm looking forward to seeing success on google/wuffs#38 so I can have the Wuffs transpiler generate Rust instead of C and have the best of both worlds. (The better-than-existing-Rust-solutions speed of existing examples of parsers written in Wuffs and the stronger safety of a DSL written specifically for safe parsing, without the cgo-esque annoyances and complications that show up as soon as C dependencies are added to a Rust project. (eg. it's much easier to cross-compile a Rust project with no C dependencies beyond libc.)
    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...).

    Leave a comment:


  • cl333r
    replied
    Originally posted by ssokolow View Post

    I'm looking forward to seeing success on google/wuffs#38 so I can have the Wuffs transpiler generate Rust instead of C and have the best of both worlds. (The better-than-existing-Rust-solutions speed of existing examples of parsers written in Wuffs and the stronger safety of a DSL written specifically for safe parsing, without the cgo-esque annoyances and complications that show up as soon as C dependencies are added to a Rust project. (eg. it's much easier to cross-compile a Rust project with no C dependencies beyond libc.)
    I did program in Rust for like a year and while initially a big fan, eventually I came to the conclusion that I'd much prefer a new successor to C++ which hopefully Carbon will be.

    Though Rust in its own right is a good lang that easily gets out of control.

    Leave a comment:


  • pWe00Iri3e7Z9lHOX2Qx
    replied
    I'm surprised this Google lib story was covered but the absolute clusterf*ck around the libwebp vulnerability wasn't.



    They originally said it was only a vulnerability in Google Chrome, but it was really in libwebp, and a crap ton of software was effected (Firefox, Thunderbird, LibreOffice, hell most apps that support webp because they all use that library). It was being actively exploited by a nation state to install NSO's Pegasus spyware on a targeted individual's iPhone. Distros were scrambling to patch things quickly.

    There's an interesting write up about how the vulnerability works here:
    Early last week, Google released a new stable update for Chrome. The update included a single security fix that was reported by Apple's Security Engineering and Architecture (SEAR) team. The issue, CVE-2023-4863, was a heap buffer overflow in the WebP image library, and it had a familiar warning attached: "Google

    Leave a comment:


  • Quackdoc
    replied
    Firefox was effected too, and man, their advisories really need to be touched up on. it certainly made is sound a lot more scary then it was with lots of people thinking that a maliciously encoded video file could trip it.

    Specific handling of an attacker-controlled VP8 media stream could lead to a heap buffer overflow in the content process. We are aware of this issue being exploited in other products in the wild.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by cl333r View Post
    And then people will fight over what to consider a memory safe language and what are the requirements to qualify for a good language to write codecs in.
    I'm looking forward to seeing success on google/wuffs#38 so I can have the Wuffs transpiler generate Rust instead of C and have the best of both worlds. (The better-than-existing-Rust-solutions speed of existing examples of parsers written in Wuffs and the stronger safety of a DSL written specifically for safe parsing, without the cgo-esque annoyances and complications that show up as soon as C dependencies are added to a Rust project. (eg. it's much easier to cross-compile a Rust project with no C dependencies beyond libc.)
    Last edited by ssokolow; 30 September 2023, 08:46 AM.

    Leave a comment:

Working...
X