Az LZO két évtizedes bugja és a "média hype"

Bug

A Lab Mouse Security arról ír, hogy a Lempel-Ziv-Oberhumer (LZO) tömörítési algoritmussal (illetve annak implementációival) gondok vannak. A blog szerint egy 20 éves bug van jelen benne/bennük. Mivel az LZO gyors és hatékony, számos, sokak által nap mint nap használt nyílt és zárt programban, projektben előfordul. A blog említ is néhányat: OpenVPN, MPlayer2, Libav, FFmpeg, a Linux kernel, Juniper Junos stb. Sőt, nem csak a Földön használják. A blog szerint az LZO a Marsot is megjárta.

Mivel népszerű megoldásról van szó, számos cég újraírta az LZO-t. Viszont a blog szerint közös mindegyik átiratban, hogy kivétel nélkül az eredeti szerző, Markus F.X.J. Oberhumer nyílt forrású alapimplementációját vette alapul. Az elérhető nyílt forrású implementációk:

A Lab Mouse Security szerint noha észrevehetően eltérő implementációkról van szó, mindegyik ugyanúgy sebezhető.

A meglehetősen bő lére eresztett blogbejegyzés a bugról elolvasható itt.

A sebezhetőség híre eljutott az eredeti szerzőhöz, Markus F.X.J. Oberhumer-hez is, aki kiadta a LZO 2.07-es verzióját, amely javítja a potenciális sebezhetőséget. (Majd kiadta a 2.08-as verziót is, ami kisebb bejelentett fordítási hibákat orvosol.)

Oberhumer a következőket mellékelte a 2.07-es kiadás mellé:

TL;DR: the Linux kernel is *not* affected; media hype.

Részletek itt.

( log69 | 2014. 06. 29., v – 14:34 )

A lényeg:

"... Each variant of the LZO and LZ4 implementation is vulnerable in slightly different ways. The attacker must construct a malicious payload to fit each particular implementation. One payload cannot be used to trigger more than a DoS on each implementation. Because of the slightly different overflow requirements, state machine subtleties, and overflow checks that must be bypassed, even a worldwide DoS is not a simple task.

This results in completely different threats depending on the implementation of the algorithm, the underlying architecture, and the memory layout of the target application. Remote Code Execution (RCE) is possible on multiple architectures and platforms, but absolutely not all. Denial of Service is possible on most implementations, but not all. Adjacent Object Over-Write (OOW) is possible on many architectures."

( Zahy v | 2014. 06. 29., v – 14:39 )

Ha már a listázásnál tartunk. ZFS-ben is *lehet* LZO tömörítést használni.

Ha jól értem, akkor
- Csak 32 bites rendszerek érintettek
- És egy rosszindulatúan összerakott tömörített adatot kell megetetni az LZO kicsomagoló részével

A sima becsomagolom-kicsomagolom esetben nem jön elő a hiba.

A ZFS maximum olyankor érintett, ha egy idegen helyről származó, rosszindúlatúan módosított ZFS poolt fel akarnék mountolni. Azért ez elég ritka csillag-együttálásnál fordul csak elő, míg mondjuk egy OpenVPN gyakran találkozik olyan csomaggal, amit nem ő maga tömörített be előtte.

"If buffers of sixteen (16) megabytes or more can be passed to the LZO or LZ4 decompress routine in one call, then exploitation of the integer overflow is possible. For example, ZFS constrains buffer sizes to 128k. So, even though they use a vulnerable implementation of LZ4, an attack is not possible without a second bug to bypass the buffer size constraint. "

( artifex | 2014. 06. 29., v – 23:34 )

Akkor lehet élnek a Marson, csak meghekkelték a Curiosity-t.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."