zlib 1.2.12 --> 1.2.13 upgrade

[mmirkows]

Hi,
there is a critical CVE https://nvd.nist.gov/vuln/detail/CVE-2022-37434 in zlib 1.2.12 which was fixed in zlib 1.2.13. Is there a plan to update this 3rd party to remove this vulnerability and to release a new version of PyInstaller?

Regards,
Michal Mirkowski

[bwoodsend]

We had a similar discussion on #6804 when another CVE came out. Vulnerabilities which lead to out of bounds read or write operations aren't applicable to PyInstaller's onefile extraction (the only place our statically compiled zlib is used) since to be exploited, a user would have to run an untrusted onefile executable given to them by the attacker, in which case the attacker is already able to put the malicious code into the executable rather than carefully crafting an invalid archive to do the same thing.

[mmirkows]

Thank you for explanation and integrating zlib update. Is there a plan for PyInstaller release with this update?

[rokm]

Not a dedicated release, if that's what you are asking. As explained above, the zlib upgrade is pretty minor issue in the context of PyInstaller, so it will have no impact on the release schedule.

[rokm]

That said, we've been trying to push out a new version on a monthly basis, so I would expect a new release in two weeks or so.

[mmirkows]

I see. I was asking because it requires additional work to use latest PyInstaller release in software project as the latest 5.5 version has a vulnerable 3rd party module. This has to go through appropriate security analysis, risk assessment and so on. It is far more straightforward to have a version without vulnerable 3rd party (no doubts) than to have a non-exploitable version with vulnerable 3rd party.
I would appreciate if there is an option to release a minor version with this update.

[rokm]

Well, if you put it that way... do you audit our pre-compiled bootloaders? How would you know that they were, in fact, built with the latest zlib sources (aside from the fact that it would take additional effort to swap them with something else...)? Or that malicious code was not added, either intentionally (us going rogue) or unintentionally (e.g., the machine used for building bootloaders being infected)?

If you had to perform security assessment and risk management for development version of PyInstaller, I'd say you should also be compiling your own bootloaders from source. And then it doesn't matter if you use development version, or 5.5 with manually updated zlib sources. (Also, I fail to see why development version would require extra assessment and new release would not - if we made the release right now, the difference between the two, content-wise, would be just a semantic).