4 ms·

A disturbing thought here is that unit tests opened up an attack vector. Without the tests this would have been much harder to hide.

by vodou 3y ago

oogali 3y ago
Furthermore, the attacker covered their tracks on the initial payload with an innocuous paragraph in the README. ("Nothing to see here!") bad-3-corrupt_lzma2.xz has three Streams in it. The first and third streams are valid xz Streams. The middle Stream has a correct Stream Header, Block Header, Index and Stream Footer. Only the LZMA2 data is corrupt. This file should decompress if --single-stream is used. The strings of `####Hello####` and `####World####` are there so that if you actually follow the instructions in the README, you get a seemingly valid result. $ cat tests/files/bad-3-corrupt_lzma2.xz | xz -d --single-stream ####Hello#### They're shell comments so it won't interfere with payload execution. And lastly, they act as a marker that can be used by a later regex to locate the file _without_ referencing it by name directly nor using the actual Hello and World strings. $ gl_am_configmake=`grep -aErls "#{4}[[:alnum:]]{5}#{4}$" $srcdir/ 2>/dev/null` $ echo $gl_am_configmake ./tests/files/bad-3-corrupt_lzma2.xz
creato 3y ago
For security critical projects, it seems like it would make sense to try to set up the build infrastructure to error (or at least warn!) when binary files are being included in the build. This should be done transitively, so when linux distros attempted to update to this new version of liblzma, the build would fail (or warn) about this new binary dependency. I don't know how common this practice is in the linux distro builds. Obviously if it's common, it would take a lot of work to clean up to make this possible, even if it's even possible in the first place. It seems like something that would be doable with bazel, but I'm not sure about other build systems.
- bicolao 3y ago
  seems easily worked around with base64 and friends.

A disturbing thought here is that unit tests opened up an attack vector. Without the tests this would have been much harder to hide.

by vodou 3y ago

A disturbing thought here is that unit tests opened up an attack vector. Without the tests this would have been much harder to hide.

oogali 3y ago

Furthermore, the attacker covered their tracks on the initial payload with an innocuous paragraph in the README. ("Nothing to see here!") bad-3-corrupt_lzma2.xz has three Streams in it. The first and third streams are valid xz Streams. The middle Stream has a correct Stream Header, Block Header, Index and Stream Footer. Only the LZMA2 data is corrupt. This file should decompress if --single-stream is used. The strings of `####Hello####` and `####World####` are there so that if you actually follow the instructions in the README, you get a seemingly valid result. $ cat tests/files/bad-3-corrupt_lzma2.xz | xz -d --single-stream ####Hello#### They're shell comments so it won't interfere with payload execution. And lastly, they act as a marker that can be used by a later regex to locate the file _without_ referencing it by name directly nor using the actual Hello and World strings. $ gl_am_configmake=`grep -aErls "#{4}[[:alnum:]]{5}#{4}$" $srcdir/ 2>/dev/null` $ echo $gl_am_configmake ./tests/files/bad-3-corrupt_lzma2.xz

creato 3y ago

For security critical projects, it seems like it would make sense to try to set up the build infrastructure to error (or at least warn!) when binary files are being included in the build. This should be done transitively, so when linux distros attempted to update to this new version of liblzma, the build would fail (or warn) about this new binary dependency. I don't know how common this practice is in the linux distro builds. Obviously if it's common, it would take a lot of work to clean up to make this possible, even if it's even possible in the first place. It seems like something that would be doable with bazel, but I'm not sure about other build systems.

bicolao 3y ago
seems easily worked around with base64 and friends.