* Daniel Stenberg <dan...@haxx.se> [2025-02-05 09:21]:
[...]
> This problem can only trigger when using a run-time zlib version 1.2.0.3 or
> older. zlib 1.2.0.4 was relased on August 10, 2003. This means zlib versions
> that do not trigger this problem have been available and used for more than
> twenty-one years already. A zlib version 1.2.0.3 or earlier still in use is
> vulnerable to a wide range of security problems and a user using this is
> already in a spectacularly bad position.
> 
> libcurl featured code that at run-time takes a different code path for zlib
> versions before 1.0.2.4 because of lack of functionality in those old
> versions, and this rarely used piece of code contained the vulnerable code
> path.

I assume this last version should have been 1.2.0.4 as before and not 1.0.2.4?

[...]
> SOLUTION
> ------------
> 
> Starting in version 8.12.0, libcurl no longer supports zlib < 1.2.0.4. Using
> such a version will now instead cause a run-time error.
> 
> - Fixed-in: https://github.com/curl/curl/commit/76f83f0db23846e254d940ec7
[...]

Looking at the patch it seems the version check is using a string comparison
instead of a proper numeric one on the version tuple (major, minor, revision,
subrevison):

  if(strcmp(v, "1.2.0.4") >= 0) {

Which, whilst I doubt we'll see such a zlib version any time soon if ever
(though zlib-ng compat might get there a lot faster), would give an incorrect
result for e.g. version "1.10.0.0".

- Fay

Reply via email to