4 ms·

Last year we had a great public example of why eliminating attack surface should always be prioritized over legacy support. Support for a compression format spe

by mike_d 4y ago

Last year we had a great public example of why eliminating attack surface should always be prioritized over legacy support. Support for a compression format specific to fax machines was used by a government to hack the cell phones of activists. https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...

fegu 4y ago
That article was today's most fascinating read for me. Thanks!
KennyBlanken 4y ago
Should be noted that a)virtually nobody used the compression method in question and b)in the few examples they did, it was quickly found to be harmful, modifying digits and letters. That compression format should have been aggressively removed once the flaws were uncovered. It presented a real-life danger on so many fronts. Imagine engineering documents, medication orders, architectural specs, you name it. That compression algorithm easily could have killed people.
- misnome 4y ago
  From what I remember from the kerfuffle around JBIG a few years ago, it was specifically a single manufacturers bad implementation that regularly swapped numbers. I believe that correct implementations weren't found to exhibit this problem except on symbols that were hard to read already?
  - mrguyorama 4y ago
    The problem was that JBIG had multiple different option sets, including an option that was explicitly "lossy" which here means that it is apt to replace one portion of an image with another. For some unfathomable reason, Xerox set this option as the default on many of their products, instead of the lossless, nearly as well compressing option.
- josefx 4y ago
  > virtually nobody used the compression method in question and JBIG2 came out around 2000, when the compression issue went public in 2013 it was in widespread use by many Xerox scanners that could scan to PDF and could not be turned off. Of course as non American I have only heard that xerox is synonymous with copying so I might misinterpret the impact the issue had. > b)in the few examples they did, it was quickly found to be harmful, modifying digits and letters. If I understand it correctly the refinement encoding that was exploited in this case would have prevented the replacement issues by storing visible differences along with the glyph replacement. However Xerox did not seem to make use of this feature, resulting in the problematic changes even at the highest quality settings. > you name it. I think Obamas birth certificate was among the victims. Some of the artifacts conspiracy theorists found on available images of it may have been caused by the JBIG2 compression algorithm of a Xerox scanner.
- oynqr 4y ago
  Who would ever want to compress bitonal images, right?
tablespoon 4y ago
> Last year we had a great public example of why eliminating attack surface should always be prioritized over legacy support. That's obviously not a good rule as stated, since the best way to follow it to run "rm -rf /" everything, which will give you zero attack surface and zero legacy support. A more reasonable formulation is: legacy support should not always be prioritized over eliminating attack surface.
benj111 4y ago
On the other hand a.out is about as basic as you can get, whereas elf isn't. So if you want to minimise bugs and attack surface surely a.out is the format to stick with.
- jbn 4y ago
  heh, that makes it sound like one would want to have a a.out format toolchain and kernel support to run such executables... kinda the opposite of the direction of history here :) Maybe even running a.out under docker would be desirable?
ale42 4y ago
JBIG2 is not specific to fax machines... Adobe Acrobat proposes CCITT group 4 (which is probably the most widely supported compression type on fax machines, by the way), and two flavours of JBIG2, when compressing scanned monochrome documents. Whence the need to support this in PDF files (JBIG2 is accepted since PDF version 1.4). JBIG2 is _not_ a legacy format, even if the use of its lossy variant must be heavily discouraged because of possible issues (e.g. invisible corruption of scanned documents).
hulitu 4y ago
> Last year we had a great public example of why eliminating attack surface should always be prioritized over legacy support. Earlier there was make and imake. Now there is make, imake, cmake, ninja, meson etc. My impression is that modern SW does everything what it can to increase the attack surface.

by mike_d 4y ago

fegu 4y ago

That article was today's most fascinating read for me. Thanks!

KennyBlanken 4y ago

Should be noted that a)virtually nobody used the compression method in question and b)in the few examples they did, it was quickly found to be harmful, modifying digits and letters. That compression format should have been aggressively removed once the flaws were uncovered. It presented a real-life danger on so many fronts. Imagine engineering documents, medication orders, architectural specs, you name it. That compression algorithm easily could have killed people.

misnome 4y ago
From what I remember from the kerfuffle around JBIG a few years ago, it was specifically a single manufacturers bad implementation that regularly swapped numbers. I believe that correct implementations weren't found to exhibit this problem except on symbols that were hard to read already?
- mrguyorama 4y ago
  The problem was that JBIG had multiple different option sets, including an option that was explicitly "lossy" which here means that it is apt to replace one portion of an image with another. For some unfathomable reason, Xerox set this option as the default on many of their products, instead of the lossless, nearly as well compressing option.
josefx 4y ago
> virtually nobody used the compression method in question and JBIG2 came out around 2000, when the compression issue went public in 2013 it was in widespread use by many Xerox scanners that could scan to PDF and could not be turned off. Of course as non American I have only heard that xerox is synonymous with copying so I might misinterpret the impact the issue had. > b)in the few examples they did, it was quickly found to be harmful, modifying digits and letters. If I understand it correctly the refinement encoding that was exploited in this case would have prevented the replacement issues by storing visible differences along with the glyph replacement. However Xerox did not seem to make use of this feature, resulting in the problematic changes even at the highest quality settings. > you name it. I think Obamas birth certificate was among the victims. Some of the artifacts conspiracy theorists found on available images of it may have been caused by the JBIG2 compression algorithm of a Xerox scanner.
oynqr 4y ago
Who would ever want to compress bitonal images, right?

tablespoon 4y ago

> Last year we had a great public example of why eliminating attack surface should always be prioritized over legacy support. That's obviously not a good rule as stated, since the best way to follow it to run "rm -rf /" everything, which will give you zero attack surface and zero legacy support. A more reasonable formulation is: legacy support should not always be prioritized over eliminating attack surface.

benj111 4y ago

On the other hand a.out is about as basic as you can get, whereas elf isn't. So if you want to minimise bugs and attack surface surely a.out is the format to stick with.

jbn 4y ago
heh, that makes it sound like one would want to have a a.out format toolchain and kernel support to run such executables... kinda the opposite of the direction of history here :) Maybe even running a.out under docker would be desirable?

ale42 4y ago

JBIG2 is not specific to fax machines... Adobe Acrobat proposes CCITT group 4 (which is probably the most widely supported compression type on fax machines, by the way), and two flavours of JBIG2, when compressing scanned monochrome documents. Whence the need to support this in PDF files (JBIG2 is accepted since PDF version 1.4). JBIG2 is _not_ a legacy format, even if the use of its lossy variant must be heavily discouraged because of possible issues (e.g. invisible corruption of scanned documents).

hulitu 4y ago

> Last year we had a great public example of why eliminating attack surface should always be prioritized over legacy support. Earlier there was make and imake. Now there is make, imake, cmake, ninja, meson etc. My impression is that modern SW does everything what it can to increase the attack surface.