13 ms·
Google assigns a CVE for libwebp and gives it a 10.0 score
- 0xParlay 3y ago[flagged]
- pjmlp 3y agoUntil governments give an helping hand, it is going to take a while. However we are going into the right direction. Microsoft also has put this into place for all those codebases that aren't being rewritten any time soon, https://learn.microsoft.com/en-us/cpp/code-quality/build-reliable-secure-programs?view=msvc-170 https://learn.microsoft.com/en-us/cpp/code-quality/build-rel...
- sjsdaiuasgdia 3y agoWho do you nominate as the arbiter of what qualifies as critical software?
- mnw21cam 3y agoThere are more "safe" languages than rust, especially if it's only "critical" software, not drivers.
- frizlab 3y agoRust is not the only memory-safe language (not even the first).
- api 3y agoDownvotes of course. Programmers like to think they can write secure code with no guardrails. The fact that CVE lists are full of memory errors in 2023 says otherwise. Even if you can write secure code in unsafe languages, it’s still a problem. Bugs creep in over time as more people work on a project, changes are merged, it’s ported to other platforms, etc. If your project has any longevity you can’t bet on your pristine C code staying pristine. There are more safe languages than Rust though.
- jiofj 3y agoDownvotes because we are tired of the rust spam.
- api 3y agoI've been in tech for ages and I hate fads, and consider myself decent at spotting them. I was skeptical when I first started seeing Rust stuff but then I tried the language. Definitely not a fad. It's a real innovation. Not the best language ever for language nerds / purists, but it brings a lot of important innovations down into the realm of the practical stuff you can easily use for real projects. The only way it's going away is if something dramatically superior appears. Language design is very very hard and most "advanced" languages are impractical for real world use for various reasons, so I am not holding my breath. The other newish language I like is Go, but for different use cases. Has a different design philosophy and imposes less cognitive load, but it's also designed for a different niche.
- matheusmoreira 3y agoWe simply don't appreciate other people imposing their will on us. We should be able to start a C project in 2023 without shame if we want to. Simply because we like C and don't like Rust. There's literally no need to justify it any further. We are free to do what we want. If in doubt, remember: the software is distributed in the hopes it will be useful but with ABSOLUTELY NO WARRANTY OF ANY KIND.
- eviks 3y agoWhat's the mechanism for imposing their will? And how is the limitation of LEGAL liability relevant in the realm of moral one (shame etc)
- matheusmoreira 3y ago> And how is the limitation of LEGAL liability relevant It sure as hell matters when a guy comes here posting about how C programmers need to be sued for negligence. Can you imagine some asshole suing you because you started a project on GitHub but didn't use one of the approved languages?
- Cthulhu_ 3y agoThis is a needlessly aggressive take IMO, and hailing Rust as the be-all and end-all for secure software lacks nuance, giving the language and its adherents a bad reputation.
- mnw21cam 3y agoThe point about Android is particularly important. I wouldn't like to estimate the proportion of Android phones that are in regular use that no longer receive security updates.
- gjsman-1000 3y agoI’m surprised, given the history of exploits, Google didn’t decide to start shipping the image decoders as an APEX system component in the Play Store, with the built-in ones serving as a fallback. They just might now.
- tgv 3y agoI'm always suspicious of Google's behavior. It might be a good opportunity for them to tell everyone they need the latest version of Chrome because security. Manifest 3.0 and cohorts/FLoC, you can't escape them.
- pja 3y agoHaving spelunked through some Google announcements on this, it looks like they planned to do so back when Android 11 was in development (https://android-developers.googleblog.com/2020/02/Android-11-developer-preview.html https://android-developers.googleblog.com/2020/02/Android-11... ), but I can’t find any evidence that image decoders are included in the current Android Mainline system updates that ship via Google Play - video codecs are, but not image ones apparently. The image decoders are in android.graphics (https://developer.android.com/reference/android/graphics/package-summary https://developer.android.com/reference/android/graphics/pac... ) & that API subset is not listed in the Android Mainline system modules that are catalogued here: https://source.android.com/docs/core/ota/modular-system https://source.android.com/docs/core/ota/modular-system It looks as if they planned to include image decoders, but that was dropped sometime during the Android 11 development cycle, unless I’ve missed something (which is certainly possible). Edit: the final dev release announcement for Android 11 keeps the same paragraph about the native image decoder. So maybe it is there & I’m just not finding it? https://android-developers.googleblog.com/2020/09/android11-final-release.html https://android-developers.googleblog.com/2020/09/android11-...
- 3y ago
- kevincox 3y agoThe thing that concerns me most is looking at the fix it is very difficult to see why this fix is correct. It also appears as there is lots of code without explicit bounds checks. It makes me worried because while the logic may be safe this makes the logic very complex. I wonder what the cost would be to add an explicit, local bounds check at every array access. This would serve as a backup that is much easier to verify. I suspect the cost would be relatively small. Small enough that I personally would be happy to pay it. https://github.com/webmproject/libwebp/commit/902bc9190331343b2017211debcec8d2ab87e17a https://github.com/webmproject/libwebp/commit/902bc919033134... This is also a great reminder that fuzzing isn't a solution to memory unsafe languages and libraries. If anything the massive amount of bugs found via fuzzing should scare us as it is likely only scratching the surface of the vulnerabilities that still lie in the code, a couple too many branches away from being likely to be found by fuzzing.
- londons_explore 3y agoLooks pretty correct to me... We just keep track of the table size and make it bigger if necessary. We additionally have a mode where we just calculate the necessary size, without writing any data structures. So we have kinda added double safety against this particular bug.
- jsnell 3y agoThere was a great explanation a few days back on why the vulnerability existed, and on why the fix was correct: https://blog.isosceles.com/the-webp-0day/ https://blog.isosceles.com/the-webp-0day/ (Discussed in https://news.ycombinator.com/item?id=37600852 https://news.ycombinator.com/item?id=37600852)
- kevincox 3y agoI understand that the patch is correct. The point that I am trying to make is that the correctness of this code relies on non-local reasoning (the allocation/reallocation of the table before it is used). I believe that non-local reasoning raises the chance of error (and is likely one of the reasons why this bug existed in the first place). By adding length counts and explicit bounds checks locally you provide local reasoning to back up this non-local reasoning which is much *easier* to make and maintain correct. I think that would result in code that is less likely to have similar bugs in the future.
- albntomat0 3y agoAdditional timeline info, as I was curious myself. WebP is old enough that a memory safe language was not a feasible option when the project started. Android 12 was the first version to support Rust code, and came out in 2021 [0, link talks about the first year of integration]. On the iOS side (which also was affected by this), Swift 1.0 came out in ~2014. As far as I can tell, Chrome doesn't yet support a memory safe language, but do have a bunch of other safety things built in (see MiraclePtr, sandboxing, etc). Since both WebP and Chrome are from Google, this would stop a possible transition. WebP was announced in 2010, and had its first stable release in 2018 [1]. [0]: https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html https://security.googleblog.com/2022/12/memory-safe-language... [1]: https://en.wikipedia.org/wiki/WebP https://en.wikipedia.org/wiki/WebP
- postalrat 3y agoIs JavaScript a memory safe language?
- unilynx 3y agoIt is. and so is WASM, but both probably aren't fast enough
- Thews 3y agoI think there is a ~35% hit with emscripten
- albntomat0 3y agoYes, and so are Python, Lisp, Haskell, and a million other languages that were available in 2010. None of those are suitable options for an image decoding library on the range of WebP supported platforms.
- mrtksn 3y ago>None of those are suitable options for an image decoding library on the range of WebP supported platforms. What makes these unusable for this task?
- ramesh31 3y agoHow can buffer overflows still be happening in this day and age?
- deleted 3y ago[deleted]
- ojii 3y agoHubris and people thinking they can safely code in memory unsafe languages (they can't)
- delfinom 3y agoNot to worry, there are serialization and other vulnerabilities in memory safe languages :3
- JulianWasTaken 3y agoEliminating a whole class of vulnerabilities is the right thing to do regardless of whether other classes of vulnerabilities remain.
- unaindz 3y agoIn both safe and unsafe languages
- johnnyjeans 3y agoThe solution, if you can consider there to be one, was always languages with semantics to guarantee logical correctness. But we're never going to get that because it requires a pace of software development that's incompatible with the money people's fetish for churn and burn. So let's put all our eggs into the Rust basket and while we're at it trust the hardware to never lead us astray :)
- himinlomax 3y agoI never lock my door because burglars can break a window.
- 3y ago
- nickcw 3y agoAndroid is particularly troublesome here with the number of phones out there receiving no updates, and just a single download away from being exploited. For me, personally, it's a race to see if Google can get this patched for my Pixel 5 before security updates stop in October.
- izacus 3y agoBased on Mishaal's post on Twitter (https://twitter.com/mishaalrahman/status/1705934521751806033 https://twitter.com/mishaalrahman/status/1705934521751806033), the patch will be in SPL released marked with 2023-10-06 date. Pixel 5 should still qualifiy for it.
- changelink 3y agoI just checked, and in the last 30 minutes a update has become available for my Pixel 5. The security bulletin doesn't reference this CVE specifically but does mention a critical vulnerability that could lead to RCE.
- jacquesm 3y agoThe problem is that they'll use the opportunity to schlep a bunch of non-security related stuff into the update as well. That's the thing that really bothers me about these, that you can't say just the security patches and hold the telemetry/marketing/spyware/adware/crapware/malware/etc.
- izacus 3y agoUpdates outside the quarterly feature drops on Pixels are pretty much exclusively security patches so I have no idea what you're talking about.
- jacquesm 3y agoThis is what I'm talking about: https://support.google.com/product-documentation/answer/11412553 https://support.google.com/product-documentation/answer/1141... Good luck setting things up in such a way that you only get security patches and not a whole bunch of 'improvements' to go with them.
- ocdtrekkie 3y agoWow, Google really preferred a critical unfixable security flaw in Android sound like just an iOS zero day for over a week. Wonder why... "Oops"
- X6S1x6Okd1st 3y agoSo this could potentially be activated by opening up a WhatsApp or RCSChat that received a payload right? I'm turning off auto download for now
- ars 3y agoDoes Whatsapp even support webp? Don't they reencode everything as jpeg?
- jurgenkesker 3y agoIf I recall correctly, Whatsapp supports webp for their sticker packs. And those are open to anyone to develop and integrate in Whatsapp on device with a intent.
- izacus 3y agoThose apps don't render WebP as far as I know so they should be fine.
- aorth 3y ago> To put this in context: if this bug does affect Android, then it could potentially be turned into a remote exploit for apps like Signal and WhatsApp. I'd expect it to be fixed in the October bulletin. Interesting quote from Ben Hawkes (former Project Zero manager) in the article. I regularly compile Signal-Android from source and happened to notice they vendored libwebp a few days ago: https://github.com/signalapp/Signal-Android/commit/a7d9fd19d9269201a276fbbff683355f1287efb1 https://github.com/signalapp/Signal-Android/commit/a7d9fd19d...
- peter_d_sherman 3y agoObservation: Uncompressed bitmaps, while bloated in terms of necessary bandwidth, still are provably the most secure form of bitmap -- just as uncompressed video (again, while super-bloaty and bandwidth intensive) would be... That is, to abstract, our security issue exists because: A) There is complex compression/decompression software/code; B) To implement this compression/decompression -- there are one or more lookup tables in effect; C) The software implementing those lookup tables and the decompression side of things were never properly fuzzed, bound-checked, and/or mathematically proven not to create out-of-bounds errors, that is, for every potential use of the lookup table to be guaranteed as correct mathematically given any possibility, any combination of data in an input stream. Also -- Didn't stuff like this already happen in GIF and PNG formats? Weren't there past security vulnerabilities for those formats? Isn't this just (I dare to say) -- computer history repeating itself ? Point: Software Engineering Discipline: If you as a Software Engineer implement a decompressor for whatever format (or hell, more broadly and generically something that uses lookup tables on incoming streams of data) -- then the "burden of proof" is on you, to prove (one way or another) that it does not have vulnerabilities. Fuzzing can help, mathematics and inductive/deductive logic can help, testing can help, and paranoid coding (always bounds-checking array accesses, etc.) can help, running in virtual machines and other types of limited environments and sandboxes can help. Running as interpreted code (albeit slower) could help. Deferring decompression to other local network attached resources running in limited execution environments could help. In short... a monumental challenge... summed up as: "Prove that all code which uses lookup tables can not generate hidden/unwanted states."
- Pxtl 3y agoYes, but as counterargument: there are battle-tested compression formats that offer pretty-damned-good compression. If anything, this shows some questions of calculus when it comes to risk-vs-reward of embracing new standards for compression formats. When was the last time there was a serious vulnerability in major JPEG libs? Or even h.264, which is much newer? Yes, a .webp is like 2/3 the size of a similar JPEG, but for most people are JPEG image sizes a huge cause for concern? Once you're doing lossy compression you're already sacrificing fidelity for filesize so you don't see a lot of machine-crushing-huge JPEGs.
- mistrial9 3y agoI have never liked this format, unfamiliar with the origins.. not shocking news here
- michaelmrose 3y agoRemember when it was a problem that 19 flatpaks had 19 different versions of a library. Storage wasn't the primary problem.
- kirbyfan64sos 3y agoRemember when the primary purpose of flatpak's shared runtimes was so that libraries like libwebp are not actually bundled per-application? libwebp in the runtimes has been patched with a fix for over a week.
- yellow_lead 3y agoRepro steps here: https://blog.isosceles.com/the-webp-0day/ https://blog.isosceles.com/the-webp-0day/ This is pretty bad, there will be many vulnerable applications and someone just posted how to exploit it. I just reproduced it on a VM: SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/<name>/webp_test/examples/dwebp+0xb24e9) in BuildHuffmanTable Shadow bytes around the buggy address: ... Also, here's the webp it generated as base64, but chrome doesn't crash or anything. Other apps may handle it differently, but many just say invalid format. UklGRukAAABXRUJQVlA4TN0AAAAvAAAAAPAAWgAAsKwlnZsEAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAALRt27Zt27Zt27Zt27Zt2/b92fUAWgAAsLTknJskSQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAALw/23oALQAAWFpyzk2SJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAN6f bT2AFgAALC055yZJEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO/Pth7A/xsAQoutz/f3 fwAwMzNvVVXt7p5zLw==
- xavxav 3y agoI'm tired and cranky today so this will lack subtlety, but: You don't have to use Rust but you **can't** use C. There's no reason to be finding these bugs in 2023; period, we can do better and we know how to do better, there's just no reason apart from legacy code (and even then) that you should be using memory unsafe languages in production.
- ck45 3y agoOne example for a safer language developed at Google: https://github.com/google/wuffs https://github.com/google/wuffs
- radlad 3y agoOn this note, I was really surprised to find Red Hat's OCI runtime is written in C: https://github.com/containers/crun https://github.com/containers/crun Is anyone working on a Rust version?
- yjftsjthsd-h 3y agoWell runc is in Go, which isn't Rust but at least isn't C.
- sbt567 3y agoThere is https://github.com/containers/youki https://github.com/containers/youki
- 3y ago