18 ms·

The WebP 0day

440 points by benhawkes 3y ago

Macha 3y ago
It feels like this bug has only really flown down under the radar because the discoverers are not in the habit of giving bugs names and landing pages. Both because of level of access (remote code execution), the vector (image rendering, often done with untrusted data) and the widespread nature of the affected library.
- jsnell 3y ago
  Did it really fly under the radar? It was widely reported in the mainstream media. There were at least two "top of HN frontpage" submissions on it. https://news.ycombinator.com/item?id=37425007 https://news.ycombinator.com/item?id=37425007 https://news.ycombinator.com/item?id=37478403 https://news.ycombinator.com/item?id=37478403
  - Macha 3y ago
    Compared to the likes of log4shell, shellshock or heartbleed, yes. It feels like the immediately exploit possibility of it is arguably more than heartbleed, but I don't see every security person chasing after it in the same way. I've been following the progress of some of the fixes in apps I use and it's meandering through intermediates at an urgency that is more akin to the ssh 9.1p1 vulnerability which required peopel to ssh into an affected server.
    - pvg 3y ago
      It's nothing close to heartbleed which was 'extract key material from every TLS-serving endpoint in the universe'. There are almost certainly exploitable buffer overflows in whatever device you're using right now.
  - mmsc 3y ago
    I would argue that it has flown under the radar because it has only been contextualized with respect to Chrome and iOS. The issue has and continues to affect many other critical places, including server-side image processing services.
- jandrese 3y ago
  BLASTPASS is an ok exploit name, but it is kinda specific. People might think it was only about bypassing BlastDoor on iPhones. A better name might have been something like "WebPwn", which would have made it much more clear that it was a vulnerability in the image format.
  - AdmiralAsshat 3y ago
    "BLASTPASS" made me initially think it was the exploit used to breach LastPass.
  - olliej 3y ago
    WebPwn is a great name and I almost want a direct RCE in WebP just so it can get that name
  - halJordan 3y ago
    Blastpass is the exploit that broke open Blastdoor. The webp exploit is just a neat privilege escalation after you blastdoor'd the target.
- deleted 3y ago
  [deleted]
freitzkriesler2 3y ago
Ah webp, let me count the ways I hate thee...
- Jigsy 3y ago
  I don't get the praise for webp either. Out of images I see, jpg has better details preserved than webp.
  - freitzkriesler2 3y ago
    It's an annoying format that Google made that's proprietary and reinvents the wheel. Had Microsoft done this the tech world would be up in arms. When Google does it, it's OK. I have to add extensions to convert this crap when I want to download images. I hope that Google loses their dominance to Microsoft with AI.
    - madars 3y ago
      webp is not proprietary. There is a patent grant https://groups.google.com/a/webmproject.org/g/webp-discuss/c/W4_j7Tlofv8 https://groups.google.com/a/webmproject.org/g/webp-discuss/c... and reference implementation is BSD-licensed.
    - nayuki 3y ago
      You might be interested that Microsoft developed JPEG XR: https://en.wikipedia.org/wiki/JPEG_XR https://en.wikipedia.org/wiki/JPEG_XR , https://www.microsoft.com/en-us/research/project/jpeg-xr/ https://www.microsoft.com/en-us/research/project/jpeg-xr/ . And in the past, they tried to shove Windows Media Video and Audio down our throats, which are inferior relatives of MPEG-4, AAC, FLAC, etc.
    - halJordan 3y ago
      But you don't have to add extensions to convert this crap. You do that to yourself. If you quit making your life hard it would be so much easier, but probably less complaining- so i guess that's the trade off.
Syonyk 3y ago
Good writeup, thanks for sharing it! And yet another argument for "You ought to be using Qubes." Random web access needs to be treated as "Genuinely high risk" anymore. A disposable VM with nothing of value in it for "casual web use" seems the right option for exploring the security hostile environment of "the internet."
- deleted 3y ago
  [deleted]
- bennyg 3y ago
  This is a fun idea, are there any browsers that hide the VM from end users so it looks and feels like a browser instance but is actually a tunnel into a sandboxed VM that’s being painted to?
  - mminer237 3y ago
    The problem is that browsers are the biggest attack vectors but also the most valuable targets. Getting a user's email password or cookie is probably the most damaging thing they could get unless you're the type to buy cryptocurrencies.
    - hiatus 3y ago
      Not your bank? Email and bank login should be sufficient to change mfa and other settings and lock you out long enough to have forged checks drawn and cashed against your account.
  - Chabsff 3y ago
    That's kinda-sorta what they all do already. Not full OS-level VM abstraction, but surprisingly close to it. Exploits like this need to be paired with sandbox-escaping in order to do damage beyond the current browsing session (which VMs wouldn't help with in the first place). And the distinction between sandbox-escaping and VM-escaping is rather thin.
    - 3y ago
omginternets 3y ago
I have a few questions I'm not able to find clear answers to: 1. Are other Chrome-based browsers (e.g. Brave) affected by this? 2. Is desktop Chrome affected, or is this purely a mobile thing? 3. Why haven't I heard of WebP before? Am I living under a rock, or is this a mobile-first technology?
- dboreham 3y ago
  It's a Google-first technology.
  - fiddlerwoaroof 3y ago
    It’s pretty broadly supported now: https://caniuse.com/webp https://caniuse.com/webp
    - oittaa 3y ago
      Many CDNs use it automatically. They detect you're on a modern browser and transparently compress sub-optimal images like PNGs without loss of quality.
      - nyanpasu64 3y ago
        Considering that "lossless" WebP comes with mandatory chroma subsampling, I'd say that WebP and not PNG is the sub-optimal image format.
        NavinF 3y ago
        > "lossless" WebP comes with mandatory chroma subsampling Source? I've roundtripped bitmap->WebP->bitmap and got the same bits out
        nyanpasu64 3y ago
        I did find that `ffmpeg -i file.png -lossless 1 test.webp` could produce a full-res chroma image, recognized as WebP by file and opening successfully in Chrome and Firefox. I was under the impression this was not possible, but I suppose it is (today, not sure in the past). Why do I see WebP as an image format used to sneakily degrade PNG files? I've seen gaming wikis and CDNs serve PNG URLs as lossy WebP, ruining pixel art and degrading color detail in 2D art. And Discord CDN's "file.webp?size=1024&quality=lossless" serves icons/emotes with chroma subsampling (and ffprobe doesn't say the file is lossless, unlike test.webp above).
Yeroc 3y ago
I'm surprised the summary of the article only talked about over-reliance on fuzzing and then suggested 1) more thorough code reviews and 2) sandboxing as solutions?! To me, the solution lies in using memory-safe languages.
- nolist_policy 3y ago
  I think sandboxing is the more powerful solution. You think in terms of "What privileges can the attacker gain if this code blows up?" and limit the code's privileges to the minimum. Problem is, sandboxing is harder to implement so it's often done suboptimally or not at all.
  - Yeroc 3y ago
    Yes and Google Chrome has invested heavily in sandboxing and still had to ship this as a high-priority fix. I'd say sandboxing in conjunction with memory-safe languages is the future.
    - kentonv 3y ago
      The problem is that rewriting existing code into a memory-safe language is a huge investment -- and realistically the world depends on a lot of code built over many decades that cannot be rewritten overnight. Consider that Mozilla created Rust specifically so they could rewrite their browser in it, yet still only a small fraction of Firefox code is Rust today -- much more is still C/C++. Realistically we're going to have a lot of heavily used C/C++ code forever. The singularity will come before we can replace it all. The nice thing about sandboxing and fuzzing can be applied to existing code.
      - Yeroc 3y ago
        Yes, but sandboxing and fuzzing are insufficient. As pointed out in the article Google had been fuzzing this library and it didn't find the issue. They even tweaked the fuzzing after this issue was found to specifically target the area of the vulnerability and it apparently still didn't trigger the issue. Google Chrome also implements sandboxing and many areas. It's not feasible everywhere. So for new code / libraries we should default to a memory-safe language.
pja 3y ago
So if your Android device is out of support, there’s now a 0-click exploit floating about in the wild? Or will updating the SMS App, Chrome, WhatsApp, Signal etc be sufficient to cover all the likely input routes?
- benhawkes 3y ago
  Well, we don't know for sure that an exploit exists for this bug on Android yet (the original exploit was for iOS via iMessage), but there's a reasonably high chance that one has been developed already. These types of exploits are in very high demand for Android right now, I've heard some eye-watering prices being mentioned recently. Updating Chrome on an unsupported device would fix the issue, but you would still need an Android OS upgrade to fix the issue for apps like Signal and WhatsApp. Chrome bundles its own version of libwebp, but messaging apps and other highly exposed stuff like Gmail all use the OS provided interfaces for displaying images. Hopefully we'll start getting updates for security-supported Android devices in early October.
  - pja 3y ago
    So there’s a webp system library as well as the one in Chrome? Nice of Google to drop security support for the Pixel 4a just before this bug drops.
    - vuln 3y ago
      You’re saying that Google knew about the bug and purposely dropped security support for the pixel 4a right before? Support didn’t age out, like it typically does (age of device)? Google just pulled security support for this one device?
      - pja 3y ago
        No, I’m saying it’s extremely frustrating that Google just drops security support entirely for devices like this, when they could continue to at least patch egregious platform bugs like this one, even if they can’t fix everything. It’s just icing on the proverbial cake that a month after they drop security support for the 4a a 0-click remote exploit is found.
skilled 3y ago
> The good news is that Apple and Chrome did an amazing job at responding to this issue with the urgency that it deserves Excuse me? It is Google that assigned this as Chrome only. Over the last 7 days alone every single major Linux distribution has had to push an update (including Red Hat which assigned this a 9.6 score), and Docker images like Python which has over 1 billion pulls, not to mention Puppeteer(hello?), WordPress, Node.js, etc. and CRBug is still private to this day. I am not being condescending but sites like BleepingComputer reported this as they saw it rather than doing any investigation. And the same goes for a lot of security companies that reported on this issue in third person. It’s really difficult to foster trust when you know that the person on the other side hasn’t bothered to do any due diligence. Adam Caudill (1Password was one of the first to patch it) did a nice blog post, “Whose CVE is it anyway?”[0] highlighting the issue I am talking about in my comment. Citizen Lab has refused to comment on whether both are related, but it doesn’t take a genius does it… [0]: https://adamcaudill.com/2023/09/14/whose-cve-is-it-anyway/ https://adamcaudill.com/2023/09/14/whose-cve-is-it-anyway/
- deleted 3y ago
  [deleted]
- albntomat0 3y ago
  Apple and Chrome specifically matter here because those where the targets being exploited in the wild, and have the most direct attack surface with the largest number of users. The author mentions that many other systems need to patch as well. However, wow many of those billion Python docker pulls are rendering untrusted WebP images? Same for Node, etc. These should also be promptly patched, but they're not in the same ballpark here as iOS/Android/Chrome.
johnklos 3y ago
Funny, because for ages I was running macOS on a 2011 MacBook Pro which had a version of Safari that was so old it didn't support webp. At the same time, my Amiga 3000 running AmigaDOS 3.2.2 could support webp by virtue of an operating system-wide datatype plugin for webp. Updating the OS-wide datatype means all apps are updated, not just the browser. Why is this STILL not the case on supposedly modern OSes these days?
- arp242 3y ago
  I don't really want this to be the case. Remember when Firefox accidentally exposed all gstreamer plugins to the web? Having some insecure unaudited badly written codec is fine for a lot of use cases because it operates on trusted data. But this is of course quite a different situation than being exposed to all webpages you visit. The Amiga 3000 lived in a different world with a different internet.
- deleted 3y ago
  [deleted]
- chatmasta 3y ago
  FYI, you can install Safari Technology Preview (and Safari Beta) as a standalone app, without upgrading the entire OS: https://developer.apple.com/safari/technology-preview/ https://developer.apple.com/safari/technology-preview/
- pornel 3y ago
  The reason is most likely security and stability. OS vendors don't want every application to be potentially vulnerable or unstable, because user installed some dubious codec pack. One place where macOS allows arbitrary codecs is Quicklook plugins, but these are designed to run in a separate process. It'd be wise to implement image codecs the same way, but so far they're typically a library linked in the same process.
- callalex 3y ago
  Especially infuriating because MacOS has the brilliant generic file viewing framework that they brand as Quick Look Plugins (QLPlugin). The name comes from where the feature started (pressing spacebar in the file viewer to ostensibly view literally any file) but it is used all over the place in Mac and iOS software.
_rdvw 3y ago
re Android: My DivestOS 14.1 (A7) through 19.1 (A12) has this patched, and 20.0 (A13) is currently compiling: https://divestos.org/pages/news#2023-09.2 https://divestos.org/pages/news#2023-09.2 GrapheneOS shipped it: https://grapheneos.org/releases#2023091800 https://grapheneos.org/releases#2023091800 CalyxOS has it staged for next update: https://review.calyxos.org/c/CalyxOS/platform_external_webp/+/20327 https://review.calyxos.org/c/CalyxOS/platform_external_webp/... LineageOS 18.1+ also pulled it in: https://review.lineageos.org/q/topic:%22CVE-2023-4863%22 https://review.lineageos.org/q/topic:%22CVE-2023-4863%22 Additionally all of the above have shipped Chromium 117.0.5938.60 which contained the same fix as well: https://divestos.org/misc/ch-dates.txt https://divestos.org/misc/ch-dates.txt
- deleted 3y ago
  [deleted]
not2b 3y ago
Ubuntu and Fedora have put out security updates for libwebp, so any program that uses the shared library to access WEBP images is safe, once security updates are applied. Not sure about other Linux distros, but I expect that almost everyone has dealt with this. Unfortunately, snap and flatpak applications are a problem; it's hard to tell which ones might have a bundled, vulnerable WEBP decoder linked in.
- deleted 3y ago
  [deleted]
  - deleted 3y ago
    [deleted]
- ComputerGuru 3y ago
  Not really “any” program but those that don’t ship their own version and didn’t statically link against libwebp (if that’s an option?). Notably, browsers often don’t use the system version of the library. That’s not the end of the world since browser vendors are on top of the security game for the most part - but the million Electron apps you might be running also each need to be updated individually! Basically, don’t rest easy and get complacent. Updating the OS distros is not enough.
  - sirsinsalot 3y ago
    They did say any that use the shared library, not just any.
  - eigenlicht 3y ago
    I've just had a look into my flatpak installation, where my default "Platform" (runtime) is still vulnerable. That didn't even seem too much of a worry though since as I found out all of the flatpak apps I use that have a dependency ship their own libwebp. And sure enough, except for Firefox which is patched, none of them is. $ flatpak update --no-related --force remove Checking for updates... Nothing to do. My base system (Debian) got the patch almost two weeks ago. Might as well trash flatpak for good.
keyle 3y ago
Millions of people in the world are affected by this library, 10 times over for every devices and apps they use. I'm sorry but I call for libraries used by millions around the world to NOT use C. And I love C... But this risk ratio is off the charts and they ought to not use C for such critical libraries. Even as a C guru, you are going to make a mistake, at some point. I think this is the fix https://github.com/webmproject/libwebp/commit/dce8397fec159c9edfeec7c6388cb81428c87ed8 https://github.com/webmproject/libwebp/commit/dce8397fec159c... "malloc fail"? :facepalm: (oh yes, Slack, Discord, Teams, everything is affected, including all modern OS).
- deleted 3y ago
  [deleted]
- saagarjha 3y ago
  This is the fix: https://github.com/webmproject/libwebp/commit/902bc9190331343b2017211debcec8d2ab87e17a https://github.com/webmproject/libwebp/commit/902bc919033134...
  - keyle 3y ago
    Thanks!
    - chrisbolt 3y ago
      There's a follow-up fix, according to Debian[0]: https://github.com/webmproject/libwebp/commit/95ea5226c870449522240ccff26f0b006037c520 https://github.com/webmproject/libwebp/commit/95ea5226c87044... [0]: https://security-tracker.debian.org/tracker/CVE-2023-4863 https://security-tracker.debian.org/tracker/CVE-2023-4863
- ctz 3y ago
  Not a single test, either here or in adjacent commits. !?!
- 1letterunixname 3y ago
  Same here. Rust should be the "new C". Because you can code in C doesn't mean you should produce large quantities of complex code in it for "performance", "portability", or "legacy compatibility" "reasons". C/C++ as well as dynamic languages create huge surfaces of undefined behavior and subtle bugs that are too difficult to lint and too burdensome for even the most astute coders. Fundamental libraries should also be formally verified in a manner similar to seL4. Also, another problem is a pervasive attitude of unprofessionalism and dismissiveness of rigor, quality, correctness, and security in FOSS. The current approach of building empires on quicksand is foolish.
est 3y ago
Why can't modern software pack with more "modules"? e.g. Just upgrade a webp.dll and we're set.
- NavinF 3y ago
  That's how most linux distros work, but it also leads to nasty diamond dependency problems
  - deleted 3y ago
    [deleted]
pvg 3y ago
Couple of interesting things in the post that aren't about 'what to patch now' It can be quite a bit of work to recreate a POC of the exploit even knowing the location and the fix. A lossless decompressor in an image decoder can be quite fuzzing resistant. Maybe obvious to security people but fun to read about as a muggle.
- matthewdgreen 3y ago
  The answer to this stuff isn't to fuzz, it's to cut this code out like it's a tumor. Then if it breaks stuff throughout the OS/browser, write one heavily sandboxed and memory-safe format converter that can handle the problem. I'd rather have an iPhone or browser that is annoying in a few edge cases than have code like this where vulnerabilities are almost guaranteed (irrespective of fuzzing.) I know I'm being optimistic here, but I'm positive this won't the last chapter in this story.
  - pvg 3y ago
    I'm positive this won't the last chapter in this story I'm sure you're right about that.'Fuzzing resistant, takes human-directed fuzzing to recreate a PoC' seemed fun, but, as you say, that's the magic of memory unsafety.
userbinator 3y ago
It's surprising that this isn't in a "newer" part of the image format; Huffman compression has been around for over 70 years, Canonical Huffman for a few decades less, but even JPEG uses Huffman. This is a decades-old technology that should've had the bugs worked out of its many implementations by now and there are also countless articles about how to implement it. I've read the JPEG spec (and written a decoder) before, so I decided to look at the WebP spec: https://developers.google.com/speed/webp/docs/webp_lossless_bitstream_specification https://developers.google.com/speed/webp/docs/webp_lossless_... The important information is in section 6. The first thing I notice is that it's not very clear how the codes are constructed, unlike the JPEG one (which actually has a ton of very readable flowcharts on the process), but it appears to be similar to LZH/deflate(zlib). The "specification" looks more like a selected set of source code fragments with accompanying descriptions. Perhaps I should try writing a WebP decoder too, having already done GIF, JPEG, and PNG, but based on the above "specification", it's almost as if they don't want you to.
- lifthrasiir 3y ago
  > it's not very clear how the codes are constructed I agree the specification really lacks examples, but it explicitly states that it uses canonical Huffman trees so that only code lengths have to be transmitted. I think this is clear enough to pinpoint the actual tree. (I don't think there is any canonical Huffman tree implementation that uses the inverse lexicographical order.) > This is a decades-old technology that should've had the bugs worked out of its many implementations by now and there are also countless articles about how to implement it. Because there are many implementations of Huffman trees with different trade-offs? Charles Bloom once said that the definitive 1997 paper on Huffman optimizations [1] is still not well known at that point (2010) and many optimizations were rediscovered and then forgotten, so there should be many inefficient implementations out there. [1] https://cbloomrants.blogspot.com/2010/08/08-12-10-lost-huffman-paper.html?m=1 https://cbloomrants.blogspot.com/2010/08/08-12-10-lost-huffm...
- deleted 3y ago
  [deleted]
- nigeltao 3y ago
callalex 3y ago
The gigantic “Subscribe” button on this page is infuriating and highly distracting. It effectively covers 1/3 to 1/2 of the page if you scroll once a paragraph like me and many others.
- deleted 3y ago
  [deleted]
lifthrasiir 3y ago
To me, this bug is most similar to the Timsort bug back in 2015 [1]. Timsort is an ingenious hybrid sorting algorithm originated from CPython and many implementations including OpenJDK adopted it mostly via a source-by-source translation. Timsort particularly maintains a stack of sorted runs, and due to the construction there is a small enough finite limit in the maximum possible stack size. However the original CPython implementation didn't exactly match what was proven, so there were rare cases where stack overflow could happen. So this was a serious security bug in CPython, but wasn't in OpenJDK because Java instead threw an exception in that case. Similarly, this WebP bug occurred because the largest table size was formally proven but it didn't match what was fed to the source code. This kind of bugs is not only hard to verify but also hard to review, because of course there is a proof and the source code seems to match the proof, so it should be okay! This bug suggests strong needs for approachable formal verification, including the use of memory-safe languages (type systems can be regarded as a weak form of formal verification), not human reviews. [1] http://envisage-project.eu/wp-content/uploads/2015/02/sorting.pdf http://envisage-project.eu/wp-content/uploads/2015/02/sortin...
- 3abiton 3y ago
  TIL Stack Overflow is not just the name of a website.
  - defrost 3y ago
    If that's a serious TIL then you might enjoy the Ye Olde Timey classic Smashing The Stack For Fun And Profit (1996) (OG Phrack link) http://phrack.org/issues/49/14.html http://phrack.org/issues/49/14.html (Text-zine) (TISM Berkeley CS coursework) https://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf https://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smas... (PDF)
    - tedunangst 3y ago
      But unrelated to the stack overflow in Tim sort.
hughw 3y ago
To what extent did the source code enable NSO to find this bug? Had the code been blob-only, would modern decompilers have worked well enough to help them understand the code and find this obscure bug?
- pornel 3y ago
  A blob would not stop the attackers. To write a successful exploit they need to understand the compiled binary anyway.
  - hughw 3y ago
    But that’s my point. Without source code it would be hard to understand the program.
    - pornel 3y ago
      Of course having source is more convenient, but not as much as it may seem. The attacker is looking for something the source did not intend to do, so they're already "reading between the lines". Many memory safety bugs can be found by fuzzing code as a black box. Fuzzing is used by code authors too, because even people who wrote the source code don't fully understand what edge cases exist based on the source code! If the code has Undefined Behavior bugs, then the source code may not even match what the actual program does. There are good decompilers, and as I've mentioned, writing an exploit will necessary depend on working with compiled code — you must know what's in memory, on the stack, and where "gadgets" are the exploit can jump to. This information is not present in the source code. Deep understanding of compiled code is a prerequisite for writing an exploit. Bugs have been found in closed-source Windows for as long as it existed. Even the recent attack on Apple Messages combined this bug with a bug in Apple's closed-source sandbox. Security by obscurity has always been tempting, and never worked as well as hoped.
dvrp 3y ago
one can't even see images without sec concerns
- Zuiii 3y ago
  One can avoid the most egregious security concerns (rce) if software vendors use slightly slower libraries to render their images. Avoid libraries written in C. It'll almost eliminate all rce and your users will be safer because of it.
  - spicybright 3y ago
    Can't see that happening any time soon, browsers/users love render speed. If one is concerned about this as an end user, I've seen some extensions that block webp and try to request a png/jpg/etc. version from the host. I can't attest to how effective it is as I didn't use it long. But it worked with some of the big image hosting sites like imgur. For me, this was just so I was able to download images in a usable format. Most OSs can't treat webp like normal images, like generating thumbnails or opening a preview app. That was a few years ago though so maybe things have changed.
- spicybright 3y ago
  I might be making stuff up here but I do remember the same happening to I think png and jpg at least once, to some degree. It just sounds like typical growing pains from using non-safe languages (C). I get the appeal for browser speeds, but I really wish we as an industry could move away from methods that encourage the same mistakes we've been making since we started writing in C. It feels like we're using self tapping screws to build a bridge instead of rivets because it's faster. And we can just keep adding more screws if the bridge starts to sag.
peter_d_sherman 3y ago
>In practice there are many such inputs that will overflow huffman_tables This looks like the generalized version of the problem... In other words, you have Software A, it generates a lookup table B which is then used to process an input stream of data. Now the responsibility shifts to you as a software developer (if you care even a little bit about security/correctness of your code) -- to either assert that: A) The software is written in such a way that there are NO possible cases of input data misusing/failing the lookup table, or B) The software will only be used in a controlled environment (i.e., point to point communication where both communicants are trusted) such that the stream is guaranteed never to contain data that misuses/fails/causes anomalies with the lookup table. Since B is all-but-impossible for anything other than a small group or office, that is, truly impossible on the Internet scale, that leaves only A). Thus, the generalized "best practice" for present or future Software Engineering, can be summarized as follows: If a lookup table is used in someone's software for whatever reasons -- then then the responsibility goes to the software developer(s) to assert that that lookup table functions correctly and for all types or data, OR that the software detects and appropriately handles erroneous data BEFORE it gets to the lookup table... In fact, if I were a serious security researcher and had the time -- I'd collect a list of ALL reported security vulnerabilities in the past that had to do, one way or another with lookup tables... Then I'd read through them, one by one, and compare them for generalities. I'm guessing (but not knowing) -- that there is a pattern there... Then I'd go through all software that used lookup tables on streams of data in one way or another -- and audit ALL of them for security vulnerabilities. Now, clearly this is not a task for one man in one lifetime... This is a "team sport"... But if I were a serious security vulnerability researcher -- that is the generalized path that I would take...

440 points by benhawkes 3y ago

It feels like this bug has only really flown down under the radar because the discoverers are not in the habit of giving bugs names and landing pages. Both because of level of access (remote code execution), the vector (image rendering, often done with untrusted data) and the widespread nature of the affected library.

jsnell 3y ago
Did it really fly under the radar? It was widely reported in the mainstream media. There were at least two "top of HN frontpage" submissions on it. https://news.ycombinator.com/item?id=37425007 https://news.ycombinator.com/item?id=37425007 https://news.ycombinator.com/item?id=37478403 https://news.ycombinator.com/item?id=37478403
- Macha 3y ago
  Compared to the likes of log4shell, shellshock or heartbleed, yes. It feels like the immediately exploit possibility of it is arguably more than heartbleed, but I don't see every security person chasing after it in the same way. I've been following the progress of some of the fixes in apps I use and it's meandering through intermediates at an urgency that is more akin to the ssh 9.1p1 vulnerability which required peopel to ssh into an affected server.
  - pvg 3y ago
    It's nothing close to heartbleed which was 'extract key material from every TLS-serving endpoint in the universe'. There are almost certainly exploitable buffer overflows in whatever device you're using right now.
- mmsc 3y ago
  I would argue that it has flown under the radar because it has only been contextualized with respect to Chrome and iOS. The issue has and continues to affect many other critical places, including server-side image processing services.
jandrese 3y ago
BLASTPASS is an ok exploit name, but it is kinda specific. People might think it was only about bypassing BlastDoor on iPhones. A better name might have been something like "WebPwn", which would have made it much more clear that it was a vulnerability in the image format.
- AdmiralAsshat 3y ago
  "BLASTPASS" made me initially think it was the exploit used to breach LastPass.
- olliej 3y ago
  WebPwn is a great name and I almost want a direct RCE in WebP just so it can get that name
- halJordan 3y ago
  Blastpass is the exploit that broke open Blastdoor. The webp exploit is just a neat privilege escalation after you blastdoor'd the target.
deleted 3y ago
[deleted]

freitzkriesler2 3y ago

Ah webp, let me count the ways I hate thee...

Jigsy 3y ago
I don't get the praise for webp either. Out of images I see, jpg has better details preserved than webp.
- freitzkriesler2 3y ago
  It's an annoying format that Google made that's proprietary and reinvents the wheel. Had Microsoft done this the tech world would be up in arms. When Google does it, it's OK. I have to add extensions to convert this crap when I want to download images. I hope that Google loses their dominance to Microsoft with AI.
  - madars 3y ago
    webp is not proprietary. There is a patent grant https://groups.google.com/a/webmproject.org/g/webp-discuss/c/W4_j7Tlofv8 https://groups.google.com/a/webmproject.org/g/webp-discuss/c... and reference implementation is BSD-licensed.
  - nayuki 3y ago
    You might be interested that Microsoft developed JPEG XR: https://en.wikipedia.org/wiki/JPEG_XR https://en.wikipedia.org/wiki/JPEG_XR , https://www.microsoft.com/en-us/research/project/jpeg-xr/ https://www.microsoft.com/en-us/research/project/jpeg-xr/ . And in the past, they tried to shove Windows Media Video and Audio down our throats, which are inferior relatives of MPEG-4, AAC, FLAC, etc.
  - halJordan 3y ago
    But you don't have to add extensions to convert this crap. You do that to yourself. If you quit making your life hard it would be so much easier, but probably less complaining- so i guess that's the trade off.

Syonyk 3y ago

Good writeup, thanks for sharing it! And yet another argument for "You ought to be using Qubes." Random web access needs to be treated as "Genuinely high risk" anymore. A disposable VM with nothing of value in it for "casual web use" seems the right option for exploring the security hostile environment of "the internet."

deleted 3y ago
[deleted]
bennyg 3y ago
This is a fun idea, are there any browsers that hide the VM from end users so it looks and feels like a browser instance but is actually a tunnel into a sandboxed VM that’s being painted to?
- mminer237 3y ago
  The problem is that browsers are the biggest attack vectors but also the most valuable targets. Getting a user's email password or cookie is probably the most damaging thing they could get unless you're the type to buy cryptocurrencies.
  - hiatus 3y ago
    Not your bank? Email and bank login should be sufficient to change mfa and other settings and lock you out long enough to have forged checks drawn and cashed against your account.
- Chabsff 3y ago
  That's kinda-sorta what they all do already. Not full OS-level VM abstraction, but surprisingly close to it. Exploits like this need to be paired with sandbox-escaping in order to do damage beyond the current browsing session (which VMs wouldn't help with in the first place). And the distinction between sandbox-escaping and VM-escaping is rather thin.
  - 3y ago

omginternets 3y ago

I have a few questions I'm not able to find clear answers to: 1. Are other Chrome-based browsers (e.g. Brave) affected by this? 2. Is desktop Chrome affected, or is this purely a mobile thing? 3. Why haven't I heard of WebP before? Am I living under a rock, or is this a mobile-first technology?

dboreham 3y ago
It's a Google-first technology.
- fiddlerwoaroof 3y ago
  It’s pretty broadly supported now: https://caniuse.com/webp https://caniuse.com/webp
  - oittaa 3y ago
    Many CDNs use it automatically. They detect you're on a modern browser and transparently compress sub-optimal images like PNGs without loss of quality.
    - nyanpasu64 3y ago
      Considering that "lossless" WebP comes with mandatory chroma subsampling, I'd say that WebP and not PNG is the sub-optimal image format.
      - NavinF 3y ago
        > "lossless" WebP comes with mandatory chroma subsampling Source? I've roundtripped bitmap->WebP->bitmap and got the same bits out
        nyanpasu64 3y ago
        I did find that `ffmpeg -i file.png -lossless 1 test.webp` could produce a full-res chroma image, recognized as WebP by file and opening successfully in Chrome and Firefox. I was under the impression this was not possible, but I suppose it is (today, not sure in the past). Why do I see WebP as an image format used to sneakily degrade PNG files? I've seen gaming wikis and CDNs serve PNG URLs as lossy WebP, ruining pixel art and degrading color detail in 2D art. And Discord CDN's "file.webp?size=1024&quality=lossless" serves icons/emotes with chroma subsampling (and ffprobe doesn't say the file is lossless, unlike test.webp above).

Yeroc 3y ago

I'm surprised the summary of the article only talked about over-reliance on fuzzing and then suggested 1) more thorough code reviews and 2) sandboxing as solutions?! To me, the solution lies in using memory-safe languages.

nolist_policy 3y ago
I think sandboxing is the more powerful solution. You think in terms of "What privileges can the attacker gain if this code blows up?" and limit the code's privileges to the minimum. Problem is, sandboxing is harder to implement so it's often done suboptimally or not at all.
- Yeroc 3y ago
  Yes and Google Chrome has invested heavily in sandboxing and still had to ship this as a high-priority fix. I'd say sandboxing in conjunction with memory-safe languages is the future.
  - kentonv 3y ago
    The problem is that rewriting existing code into a memory-safe language is a huge investment -- and realistically the world depends on a lot of code built over many decades that cannot be rewritten overnight. Consider that Mozilla created Rust specifically so they could rewrite their browser in it, yet still only a small fraction of Firefox code is Rust today -- much more is still C/C++. Realistically we're going to have a lot of heavily used C/C++ code forever. The singularity will come before we can replace it all. The nice thing about sandboxing and fuzzing can be applied to existing code.
    - Yeroc 3y ago
      Yes, but sandboxing and fuzzing are insufficient. As pointed out in the article Google had been fuzzing this library and it didn't find the issue. They even tweaked the fuzzing after this issue was found to specifically target the area of the vulnerability and it apparently still didn't trigger the issue. Google Chrome also implements sandboxing and many areas. It's not feasible everywhere. So for new code / libraries we should default to a memory-safe language.

pja 3y ago

So if your Android device is out of support, there’s now a 0-click exploit floating about in the wild? Or will updating the SMS App, Chrome, WhatsApp, Signal etc be sufficient to cover all the likely input routes?

benhawkes 3y ago
Well, we don't know for sure that an exploit exists for this bug on Android yet (the original exploit was for iOS via iMessage), but there's a reasonably high chance that one has been developed already. These types of exploits are in very high demand for Android right now, I've heard some eye-watering prices being mentioned recently. Updating Chrome on an unsupported device would fix the issue, but you would still need an Android OS upgrade to fix the issue for apps like Signal and WhatsApp. Chrome bundles its own version of libwebp, but messaging apps and other highly exposed stuff like Gmail all use the OS provided interfaces for displaying images. Hopefully we'll start getting updates for security-supported Android devices in early October.
- pja 3y ago
  So there’s a webp system library as well as the one in Chrome? Nice of Google to drop security support for the Pixel 4a just before this bug drops.
  - vuln 3y ago
    You’re saying that Google knew about the bug and purposely dropped security support for the pixel 4a right before? Support didn’t age out, like it typically does (age of device)? Google just pulled security support for this one device?
    - pja 3y ago
      No, I’m saying it’s extremely frustrating that Google just drops security support entirely for devices like this, when they could continue to at least patch egregious platform bugs like this one, even if they can’t fix everything. It’s just icing on the proverbial cake that a month after they drop security support for the 4a a 0-click remote exploit is found.

skilled 3y ago

> The good news is that Apple and Chrome did an amazing job at responding to this issue with the urgency that it deserves Excuse me? It is Google that assigned this as Chrome only. Over the last 7 days alone every single major Linux distribution has had to push an update (including Red Hat which assigned this a 9.6 score), and Docker images like Python which has over 1 billion pulls, not to mention Puppeteer(hello?), WordPress, Node.js, etc. and CRBug is still private to this day. I am not being condescending but sites like BleepingComputer reported this as they saw it rather than doing any investigation. And the same goes for a lot of security companies that reported on this issue in third person. It’s really difficult to foster trust when you know that the person on the other side hasn’t bothered to do any due diligence. Adam Caudill (1Password was one of the first to patch it) did a nice blog post, “Whose CVE is it anyway?”[0] highlighting the issue I am talking about in my comment. Citizen Lab has refused to comment on whether both are related, but it doesn’t take a genius does it… [0]: https://adamcaudill.com/2023/09/14/whose-cve-is-it-anyway/ https://adamcaudill.com/2023/09/14/whose-cve-is-it-anyway/

deleted 3y ago
[deleted]
albntomat0 3y ago
Apple and Chrome specifically matter here because those where the targets being exploited in the wild, and have the most direct attack surface with the largest number of users. The author mentions that many other systems need to patch as well. However, wow many of those billion Python docker pulls are rendering untrusted WebP images? Same for Node, etc. These should also be promptly patched, but they're not in the same ballpark here as iOS/Android/Chrome.

johnklos 3y ago

Funny, because for ages I was running macOS on a 2011 MacBook Pro which had a version of Safari that was so old it didn't support webp. At the same time, my Amiga 3000 running AmigaDOS 3.2.2 could support webp by virtue of an operating system-wide datatype plugin for webp. Updating the OS-wide datatype means all apps are updated, not just the browser. Why is this STILL not the case on supposedly modern OSes these days?

arp242 3y ago
I don't really want this to be the case. Remember when Firefox accidentally exposed all gstreamer plugins to the web? Having some insecure unaudited badly written codec is fine for a lot of use cases because it operates on trusted data. But this is of course quite a different situation than being exposed to all webpages you visit. The Amiga 3000 lived in a different world with a different internet.
deleted 3y ago
[deleted]
chatmasta 3y ago
FYI, you can install Safari Technology Preview (and Safari Beta) as a standalone app, without upgrading the entire OS: https://developer.apple.com/safari/technology-preview/ https://developer.apple.com/safari/technology-preview/
pornel 3y ago
The reason is most likely security and stability. OS vendors don't want every application to be potentially vulnerable or unstable, because user installed some dubious codec pack. One place where macOS allows arbitrary codecs is Quicklook plugins, but these are designed to run in a separate process. It'd be wise to implement image codecs the same way, but so far they're typically a library linked in the same process.
callalex 3y ago
Especially infuriating because MacOS has the brilliant generic file viewing framework that they brand as Quick Look Plugins (QLPlugin). The name comes from where the feature started (pressing spacebar in the file viewer to ostensibly view literally any file) but it is used all over the place in Mac and iOS software.

_rdvw 3y ago

re Android: My DivestOS 14.1 (A7) through 19.1 (A12) has this patched, and 20.0 (A13) is currently compiling: https://divestos.org/pages/news#2023-09.2 https://divestos.org/pages/news#2023-09.2 GrapheneOS shipped it: https://grapheneos.org/releases#2023091800 https://grapheneos.org/releases#2023091800 CalyxOS has it staged for next update: https://review.calyxos.org/c/CalyxOS/platform_external_webp/+/20327 https://review.calyxos.org/c/CalyxOS/platform_external_webp/... LineageOS 18.1+ also pulled it in: https://review.lineageos.org/q/topic:%22CVE-2023-4863%22 https://review.lineageos.org/q/topic:%22CVE-2023-4863%22 Additionally all of the above have shipped Chromium 117.0.5938.60 which contained the same fix as well: https://divestos.org/misc/ch-dates.txt https://divestos.org/misc/ch-dates.txt

deleted 3y ago
[deleted]

not2b 3y ago

Ubuntu and Fedora have put out security updates for libwebp, so any program that uses the shared library to access WEBP images is safe, once security updates are applied. Not sure about other Linux distros, but I expect that almost everyone has dealt with this. Unfortunately, snap and flatpak applications are a problem; it's hard to tell which ones might have a bundled, vulnerable WEBP decoder linked in.

deleted 3y ago
[deleted]
- deleted 3y ago
  [deleted]
ComputerGuru 3y ago
Not really “any” program but those that don’t ship their own version and didn’t statically link against libwebp (if that’s an option?). Notably, browsers often don’t use the system version of the library. That’s not the end of the world since browser vendors are on top of the security game for the most part - but the million Electron apps you might be running also each need to be updated individually! Basically, don’t rest easy and get complacent. Updating the OS distros is not enough.
- sirsinsalot 3y ago
  They did say any that use the shared library, not just any.
- eigenlicht 3y ago
  I've just had a look into my flatpak installation, where my default "Platform" (runtime) is still vulnerable. That didn't even seem too much of a worry though since as I found out all of the flatpak apps I use that have a dependency ship their own libwebp. And sure enough, except for Firefox which is patched, none of them is. $ flatpak update --no-related --force remove Checking for updates... Nothing to do. My base system (Debian) got the patch almost two weeks ago. Might as well trash flatpak for good.

keyle 3y ago

Millions of people in the world are affected by this library, 10 times over for every devices and apps they use. I'm sorry but I call for libraries used by millions around the world to NOT use C. And I love C... But this risk ratio is off the charts and they ought to not use C for such critical libraries. Even as a C guru, you are going to make a mistake, at some point. I think this is the fix https://github.com/webmproject/libwebp/commit/dce8397fec159c9edfeec7c6388cb81428c87ed8 https://github.com/webmproject/libwebp/commit/dce8397fec159c... "malloc fail"? :facepalm: (oh yes, Slack, Discord, Teams, everything is affected, including all modern OS).

deleted 3y ago
[deleted]
saagarjha 3y ago
This is the fix: https://github.com/webmproject/libwebp/commit/902bc9190331343b2017211debcec8d2ab87e17a https://github.com/webmproject/libwebp/commit/902bc919033134...
- keyle 3y ago
  Thanks!
  - chrisbolt 3y ago
    There's a follow-up fix, according to Debian[0]: https://github.com/webmproject/libwebp/commit/95ea5226c870449522240ccff26f0b006037c520 https://github.com/webmproject/libwebp/commit/95ea5226c87044... [0]: https://security-tracker.debian.org/tracker/CVE-2023-4863 https://security-tracker.debian.org/tracker/CVE-2023-4863
ctz 3y ago
Not a single test, either here or in adjacent commits. !?!
1letterunixname 3y ago
Same here. Rust should be the "new C". Because you can code in C doesn't mean you should produce large quantities of complex code in it for "performance", "portability", or "legacy compatibility" "reasons". C/C++ as well as dynamic languages create huge surfaces of undefined behavior and subtle bugs that are too difficult to lint and too burdensome for even the most astute coders. Fundamental libraries should also be formally verified in a manner similar to seL4. Also, another problem is a pervasive attitude of unprofessionalism and dismissiveness of rigor, quality, correctness, and security in FOSS. The current approach of building empires on quicksand is foolish.

est 3y ago

Why can't modern software pack with more "modules"? e.g. Just upgrade a webp.dll and we're set.

NavinF 3y ago
That's how most linux distros work, but it also leads to nasty diamond dependency problems
- deleted 3y ago
  [deleted]

pvg 3y ago

Couple of interesting things in the post that aren't about 'what to patch now' It can be quite a bit of work to recreate a POC of the exploit even knowing the location and the fix. A lossless decompressor in an image decoder can be quite fuzzing resistant. Maybe obvious to security people but fun to read about as a muggle.

matthewdgreen 3y ago
The answer to this stuff isn't to fuzz, it's to cut this code out like it's a tumor. Then if it breaks stuff throughout the OS/browser, write one heavily sandboxed and memory-safe format converter that can handle the problem. I'd rather have an iPhone or browser that is annoying in a few edge cases than have code like this where vulnerabilities are almost guaranteed (irrespective of fuzzing.) I know I'm being optimistic here, but I'm positive this won't the last chapter in this story.
- pvg 3y ago
  I'm positive this won't the last chapter in this story I'm sure you're right about that.'Fuzzing resistant, takes human-directed fuzzing to recreate a PoC' seemed fun, but, as you say, that's the magic of memory unsafety.

userbinator 3y ago

It's surprising that this isn't in a "newer" part of the image format; Huffman compression has been around for over 70 years, Canonical Huffman for a few decades less, but even JPEG uses Huffman. This is a decades-old technology that should've had the bugs worked out of its many implementations by now and there are also countless articles about how to implement it. I've read the JPEG spec (and written a decoder) before, so I decided to look at the WebP spec: https://developers.google.com/speed/webp/docs/webp_lossless_bitstream_specification https://developers.google.com/speed/webp/docs/webp_lossless_... The important information is in section 6. The first thing I notice is that it's not very clear how the codes are constructed, unlike the JPEG one (which actually has a ton of very readable flowcharts on the process), but it appears to be similar to LZH/deflate(zlib). The "specification" looks more like a selected set of source code fragments with accompanying descriptions. Perhaps I should try writing a WebP decoder too, having already done GIF, JPEG, and PNG, but based on the above "specification", it's almost as if they don't want you to.

lifthrasiir 3y ago
> it's not very clear how the codes are constructed I agree the specification really lacks examples, but it explicitly states that it uses canonical Huffman trees so that only code lengths have to be transmitted. I think this is clear enough to pinpoint the actual tree. (I don't think there is any canonical Huffman tree implementation that uses the inverse lexicographical order.) > This is a decades-old technology that should've had the bugs worked out of its many implementations by now and there are also countless articles about how to implement it. Because there are many implementations of Huffman trees with different trade-offs? Charles Bloom once said that the definitive 1997 paper on Huffman optimizations [1] is still not well known at that point (2010) and many optimizations were rediscovered and then forgotten, so there should be many inefficient implementations out there. [1] https://cbloomrants.blogspot.com/2010/08/08-12-10-lost-huffman-paper.html?m=1 https://cbloomrants.blogspot.com/2010/08/08-12-10-lost-huffm...
deleted 3y ago
[deleted]
nigeltao 3y ago

callalex 3y ago

The gigantic “Subscribe” button on this page is infuriating and highly distracting. It effectively covers 1/3 to 1/2 of the page if you scroll once a paragraph like me and many others.

deleted 3y ago
[deleted]

lifthrasiir 3y ago

To me, this bug is most similar to the Timsort bug back in 2015 [1]. Timsort is an ingenious hybrid sorting algorithm originated from CPython and many implementations including OpenJDK adopted it mostly via a source-by-source translation. Timsort particularly maintains a stack of sorted runs, and due to the construction there is a small enough finite limit in the maximum possible stack size. However the original CPython implementation didn't exactly match what was proven, so there were rare cases where stack overflow could happen. So this was a serious security bug in CPython, but wasn't in OpenJDK because Java instead threw an exception in that case. Similarly, this WebP bug occurred because the largest table size was formally proven but it didn't match what was fed to the source code. This kind of bugs is not only hard to verify but also hard to review, because of course there is a proof and the source code seems to match the proof, so it should be okay! This bug suggests strong needs for approachable formal verification, including the use of memory-safe languages (type systems can be regarded as a weak form of formal verification), not human reviews. [1] http://envisage-project.eu/wp-content/uploads/2015/02/sorting.pdf http://envisage-project.eu/wp-content/uploads/2015/02/sortin...

3abiton 3y ago
TIL Stack Overflow is not just the name of a website.
- defrost 3y ago
  If that's a serious TIL then you might enjoy the Ye Olde Timey classic Smashing The Stack For Fun And Profit (1996) (OG Phrack link) http://phrack.org/issues/49/14.html http://phrack.org/issues/49/14.html (Text-zine) (TISM Berkeley CS coursework) https://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf https://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smas... (PDF)
  - tedunangst 3y ago
    But unrelated to the stack overflow in Tim sort.

hughw 3y ago

To what extent did the source code enable NSO to find this bug? Had the code been blob-only, would modern decompilers have worked well enough to help them understand the code and find this obscure bug?

pornel 3y ago
A blob would not stop the attackers. To write a successful exploit they need to understand the compiled binary anyway.
- hughw 3y ago
  But that’s my point. Without source code it would be hard to understand the program.
  - pornel 3y ago
    Of course having source is more convenient, but not as much as it may seem. The attacker is looking for something the source did not intend to do, so they're already "reading between the lines". Many memory safety bugs can be found by fuzzing code as a black box. Fuzzing is used by code authors too, because even people who wrote the source code don't fully understand what edge cases exist based on the source code! If the code has Undefined Behavior bugs, then the source code may not even match what the actual program does. There are good decompilers, and as I've mentioned, writing an exploit will necessary depend on working with compiled code — you must know what's in memory, on the stack, and where "gadgets" are the exploit can jump to. This information is not present in the source code. Deep understanding of compiled code is a prerequisite for writing an exploit. Bugs have been found in closed-source Windows for as long as it existed. Even the recent attack on Apple Messages combined this bug with a bug in Apple's closed-source sandbox. Security by obscurity has always been tempting, and never worked as well as hoped.

dvrp 3y ago

one can't even see images without sec concerns

Zuiii 3y ago
One can avoid the most egregious security concerns (rce) if software vendors use slightly slower libraries to render their images. Avoid libraries written in C. It'll almost eliminate all rce and your users will be safer because of it.
- spicybright 3y ago
  Can't see that happening any time soon, browsers/users love render speed. If one is concerned about this as an end user, I've seen some extensions that block webp and try to request a png/jpg/etc. version from the host. I can't attest to how effective it is as I didn't use it long. But it worked with some of the big image hosting sites like imgur. For me, this was just so I was able to download images in a usable format. Most OSs can't treat webp like normal images, like generating thumbnails or opening a preview app. That was a few years ago though so maybe things have changed.
spicybright 3y ago
I might be making stuff up here but I do remember the same happening to I think png and jpg at least once, to some degree. It just sounds like typical growing pains from using non-safe languages (C). I get the appeal for browser speeds, but I really wish we as an industry could move away from methods that encourage the same mistakes we've been making since we started writing in C. It feels like we're using self tapping screws to build a bridge instead of rivets because it's faster. And we can just keep adding more screws if the bridge starts to sag.

peter_d_sherman 3y ago

>In practice there are many such inputs that will overflow huffman_tables This looks like the generalized version of the problem... In other words, you have Software A, it generates a lookup table B which is then used to process an input stream of data. Now the responsibility shifts to you as a software developer (if you care even a little bit about security/correctness of your code) -- to either assert that: A) The software is written in such a way that there are NO possible cases of input data misusing/failing the lookup table, or B) The software will only be used in a controlled environment (i.e., point to point communication where both communicants are trusted) such that the stream is guaranteed never to contain data that misuses/fails/causes anomalies with the lookup table. Since B is all-but-impossible for anything other than a small group or office, that is, truly impossible on the Internet scale, that leaves only A). Thus, the generalized "best practice" for present or future Software Engineering, can be summarized as follows: If a lookup table is used in someone's software for whatever reasons -- then then the responsibility goes to the software developer(s) to assert that that lookup table functions correctly and for all types or data, OR that the software detects and appropriately handles erroneous data BEFORE it gets to the lookup table... In fact, if I were a serious security researcher and had the time -- I'd collect a list of ALL reported security vulnerabilities in the past that had to do, one way or another with lookup tables... Then I'd read through them, one by one, and compare them for generalities. I'm guessing (but not knowing) -- that there is a pattern there... Then I'd go through all software that used lookup tables on streams of data in one way or another -- and audit ALL of them for security vulnerabilities. Now, clearly this is not a task for one man in one lifetime... This is a "team sport"... But if I were a serious security vulnerability researcher -- that is the generalized path that I would take...