Decades-Old Vulnerability Threatens 'Internet Of Things' (Dark Reading)
Patches for the integer overflow bug, which allows an attacker to cripple systems running the so-called Lempel-Ziv-Oberhumer (LZO) code with denial-of-service type attacks as well as remote code execution, were issued the past few days for the Linux kernel, as well as for various open-source media libraries. LZO handles high-speed compression and decompression of IP network traffic and files, typically images, in embedded systems. 'The most popular use is in image data, decompressing photos taken, raw images taken from a camera or video stream,' says Don Bailey, mobile and embedded systems security expert with Lab Mouse Security, who discovered the vulnerability while manually auditing the code."
Posted Jun 27, 2014 0:18 UTC (Fri)
by cesarb (subscriber, #6266)
[Link] (11 responses)
Posted Jun 27, 2014 1:24 UTC (Fri)
by PaXTeam (guest, #24616)
[Link] (10 responses)
Posted Jun 27, 2014 6:59 UTC (Fri)
by nmav (guest, #34036)
[Link] (5 responses)
Posted Jun 27, 2014 16:25 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (4 responses)
Just to point out, my 24MP DSLR chucks out files up to 32Mb in size ...
But does "block size" refer to the entire file, or is it broken down into chunks for compression? Probably the latter.
Either way, I would have thought most of the "internet of things" wouldn't have a lot of memory, to even have 16Mb chunks. It's hard to tell, but I got the impression that most embedded devices have - what would seem to us people used to PCs - an incredibly tiny amount of ram.
Cheers,
Posted Jun 28, 2014 4:11 UTC (Sat)
by proski (subscriber, #104)
[Link] (3 responses)
Just a thought - exploiting a compression bug in a camera would require making a malicious image in the real world and taking its picture. That would be exteremely hard to accomplish.
Posted Jun 29, 2014 19:59 UTC (Sun)
by rgmoore (✭ supporter ✭, #75)
[Link] (1 responses)
Which still wouldn't work, because real-world cameras have measurable noise in the least significant digits of their images. If you somehow created an image that could theoretically cause problems, the noise would probably throw everything off.
Posted Jun 30, 2014 8:16 UTC (Mon)
by BlueLightning (subscriber, #38978)
[Link]
Posted Jun 29, 2014 21:39 UTC (Sun)
by dvdeug (guest, #10998)
[Link]
Posted Jun 27, 2014 22:22 UTC (Fri)
by PaXTeam (guest, #24616)
[Link] (3 responses)
Posted Jun 29, 2014 16:04 UTC (Sun)
by Huchev (guest, #92991)
[Link] (2 responses)
But no, that's where the core of the problem is.
This is all scare mongering strategy. The objective is to create big headlines, ensuring the majority of the press won't get into the little boring technical details and will simply forward the scary-looking headline to maximize clicks.
Posted Jun 29, 2014 16:42 UTC (Sun)
by PaXTeam (guest, #24616)
[Link] (1 responses)
Posted Jul 9, 2014 22:04 UTC (Wed)
by nix (subscriber, #2304)
[Link]
(Yeah, right. Threat model, guys: you don't have one.)
Posted Jun 27, 2014 0:58 UTC (Fri)
by ewen (subscriber, #4772)
[Link] (2 responses)
A blog post with some more technical details, including source snippets with the problem. (Link buried well down in article linked to by LWN.) Ewen
Posted Jun 27, 2014 8:41 UTC (Fri)
by jezuch (subscriber, #52988)
[Link] (1 responses)
Posted Jun 27, 2014 10:21 UTC (Fri)
by kiko (subscriber, #69905)
[Link]
Posted Jul 1, 2014 18:54 UTC (Tue)
by arielb1@mail.tau.ac.il (guest, #94131)
[Link] (1 responses)
And of course the bug is a pointer overflow (http://lwn.net/Articles/278137/).
In addition the code (http://lxr.free-electrons.com/source/lib/lz4/lz4_decompre...) seems to read uninitialised memory on a read of offset 0 (but maybe I just don't understand it well enough).
Posted Jul 3, 2014 21:42 UTC (Thu)
by ewen (subscriber, #4772)
[Link]
https://code.google.com/p/lz4/issues/detail?id=52
It appears the bug was found some time ago, but initially thought not exploitable. Whereas the reality is that it might be exploitable in some environments (eg, 32 bit and allowing very large compressed blocks). So it got patched.
There's also something of an apology/explanation for how the bug got handled in regard to LZ4 (and a hint patches got published a little earlier than planned).
Thanks for the pointer.
Ewen
zlib all over again?
or maybe not
zlib all over again?
zlib all over again?
zlib all over again?
Wol
What matters is whether the camera would accept large blocks when showing images from the memory. The bug is in decompression.
zlib all over again?
zlib all over again?
Just a thought - exploiting a compression bug in a camera would require making a malicious image in the real world and taking its picture.
zlib all over again?
zlib all over again?
and the empire strikes back, sort of ;)
zlib all over again?
zlib all over again?
The article just claims that the vulnerability exists, which was *never disputed*. It's a rhetorical attempt at being right by association : if he's right for the existence of the vulnerability, he must be right for its gravity ?
Both Oberhummer & Collet state that the vulnerability existed and is fixed, but could never be exploited in currently known software. In contrast, Bailey produces a summary table pretending the vulnerability is "practical for RCE attacks". In a word, "heartbleed" like. Practical really ? With no implementation known to be exploitable ? That's a curious definition of "practical".
This is really lame, especially from the security firm which deliberately triggered this hype-reporting process.
zlib all over again?
zlib all over again?
Decades-Old Vulnerability Threatens 'Internet Of Things' (Dark Reading)
Decades-Old Vulnerability Threatens 'Internet Of Things' (Dark Reading)
Decades-Old Vulnerability Threatens 'Internet Of Things' (Dark Reading)
Decades-Old Vulnerability Threatens 'Internet Of Things' (Dark Reading)
Decades-Old Vulnerability Threatens 'Internet Of Things' (Dark Reading)