3 ms·

I feel obliged to point this out here: Do not build zlib with the hand-optimized assembly code. The ASM code is a contribution and does not receive any suppor

I feel obliged to point this out here: Do not build zlib with the hand-optimized assembly code. The ASM code is a contribution and does not receive any support by the library authors. There are bugs in there and it will read/write out of bounds given just the right data - we've been bit by it. Note also [0]. The default Makefile gets this right - it stays far away from any hand-rolled assembly (or contributions in general). But the contributed Visual Studio solutions default to building with the ASM: [1] [2]. Make sure to choose ReleaseWithoutAsm, or set up your own configuration! You can check any zlib build for whether it was built with ASM via (zlibCompileFlags() & (1 << 9)): [3] Needless to say, an OOB in a library as fundamental (and as user-data-facing) as zlib is a serious vulnerability. I didn't find any distribution or major software that uses a vulnerable zlib build in a day of investigation (well, I think Telegram Desktop in a debug build might be vulnerable [4]), but if you are on Windows you might accidentally make one. Beware! I'll also point interested readers towards zlib-ng [5] (without any endorsement or affiliation). [0]: https://github.com/madler/zlib/blob/master/inffast.c#L12 https://github.com/madler/zlib/blob/master/inffast.c#L12 [1]: https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/contrib/vstudio/vc14/testzlib.vcxproj#L362 https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da... [2]: https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/contrib/vstudio/vc14/testzlib.vcxproj#L414 https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da... [3]: https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L1185 https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da... [4]: https://github.com/telegramdesktop/tdesktop/blob/6a3ad52aef0b48ea53aa9533335b1d791547c1dd/Telegram/build/prepare/prepare.py#L459 https://github.com/telegramdesktop/tdesktop/blob/6a3ad52aef0... [5]: https://github.com/zlib-ng/zlib-ng https://github.com/zlib-ng/zlib-ng

ihattendorf 5y ago
I'm surprised they don't rip it out if they don't want to spend the time to fix it. Or at least ensure nothing they provide builds it by default and you need to pass a `-DUSE_INSECURE_ASM` flag/`ReleaseWithInsecureAsm` in VS.
- MauranKilom 5y ago
  Well, the VS solutions (and the asm code) are both "contrib", so Mark Adler does not assume responsibility for either (which is fair - he has been stewarding this library for 30 something years already...). It could be made clearer that contrib does not come with the same implied fitness for purpose as the main library, but then open source licenses already disavow any and all such fitness in the first place...
injinj 5y ago
It looks like the input word is using lodsd instruction, loading a 4 byte word, instead of a ptr increment, which could cause a 3 byte oob read if the last byte was at address 1. I believe this is used in millions of builds, since it's been around for 20 years and Windows has a culture of winzip style software not packaged by Microsoft, but a lone programmer trying to get by with donations. Do you have a specific exploit description? Mark Adler can remove or mark it unsafe on the github repo given a reason.

ihattendorf 5y ago

I'm surprised they don't rip it out if they don't want to spend the time to fix it. Or at least ensure nothing they provide builds it by default and you need to pass a `-DUSE_INSECURE_ASM` flag/`ReleaseWithInsecureAsm` in VS.

MauranKilom 5y ago
Well, the VS solutions (and the asm code) are both "contrib", so Mark Adler does not assume responsibility for either (which is fair - he has been stewarding this library for 30 something years already...). It could be made clearer that contrib does not come with the same implied fitness for purpose as the main library, but then open source licenses already disavow any and all such fitness in the first place...

injinj 5y ago

It looks like the input word is using lodsd instruction, loading a 4 byte word, instead of a ptr increment, which could cause a 3 byte oob read if the last byte was at address 1. I believe this is used in millions of builds, since it's been around for 20 years and Windows has a culture of winzip style software not packaged by Microsoft, but a lone programmer trying to get by with donations. Do you have a specific exploit description? Mark Adler can remove or mark it unsafe on the github repo given a reason.