Is PB using zlib?

[Kukulkan]

Hi, recently the vulnerability CVE-2018-25032 in zlib has attracted some attention (at least in some programming forums and IT news services like heise (german).

Is PB using zlib? In this case, my application is vulnerable because we use the PB Packer library for compression of files from the user (which is the attack scenario).

If the answer is true, I would create a new post asking Fred to update the current PB LTS version with the most recent zlib package from https://www.zlib.net/.

[skywalk]

Thanks for the heads up!

[Rings]

imho is that png support is also using zlib ....

[Kukulkan]

imho is that png support is also using zlib ....

Yes, it does. Fortunately we do not generate PNG files from user content. So the packer lib is my main concern. And we had the first customer asking... I do not want to, and I do not have time to, replace the PB packer lib by some other lib

[idle]

you could use the dll of zlib and replace zlib.lib with the import library in PB perhaps
I don't have time now but it took all of 5 minutes to down load and build zlib but the problem is the crt

[skywalk]

Whoa! I was going to ask you(idle) if we could create our own "C:\PureBasic-x64\PureLibraries\Windows\Libraries\zlib.lib" from source?
I prefer this approach instead of carrying an external zlib.dll.
This is my static load condition:

Code: Select all

#ZL_OK                  = 0
#ZL_VERSION_ERROR       = -6
ImportC "zlib.lib"
  ; Allow alias Procedure names:
  ; Note different reference to functions on x64.
  zl_version.i()                                                  As "zlibVersion"  ;FYI; zl_version.l() fails on x64?
  zl_compress2.l(*mTo_i, *lenTo_l, *mFrom_i, lenFrom.l, Level.l)  As "compress2"
  zl_uncompress.l(*mTo_i, *lenTo_l, *mFrom_i, lenFrom.l)          As "uncompress"
  zl_compressBound.l(lenFrom.l)                                   As "compressBound"
  CompilerIf #PB_Compiler_Backend = #PB_Backend_C
    zl_crc32.l(crc32.l, *buf_i, len.l)                            As "crc32"
  CompilerElse
    ;BUG; PureBasic.asm [29]: :extrn crc32: error: reserved word used as symbol.
    Macro zl_crc32(crc32_l=#Null, buf_iptr=#Null, len_l=#Null)
      Val("$" + Fingerprint(buf_iptr, len_l, #PB_Cipher_CRC32))
    EndMacro
  CompilerEndIf
EndImport
Structure ZLIB_Info ;Align #PB_Structure_AlignC
  Pack_ver$
  zlib$
  PackFile$
  PackPath$
  PWD$
  Salt$
  UsePWD.l
  hPF.l
  nFiles.q
  Level.l
  e.l
  *mTo
  wN.l
EndStructure
Procedure.s ZL_VersionIs(*p.ZLIB_Info)
  Protected.i *s = zl_version()
  Protected.s v$
  If *s
    v$ = Space(64)
    v$ = PeekS(*s, -1, #PB_Ascii)
    *p\e = #ZL_OK
  Else
    *p\e = #ZL_VERSION_ERROR
  EndIf
  ProcedureReturn v$
EndProcedure
Define ZL.ZLIB_Info
Debug ZL_VersionIs(ZL)
Define.s s$ = "This is my string to test..."
Debug s$
Debug zl_crc32(#Null, @s$, StringByteLength(s$))  ;1930396447

[idle]

Yes we could do that the problem is the crt Fred uses we need to use the same version or it gets complicated I will look this evening I'm in the city.
edit:
The dll didn't work unfortunately.

[Kukulkan]

Hi. Thanks to both of you for having a look and trying.

As there is currently some LTS version of PureBasic, maybe that is a good reason to release an update for it? The current LTS version probably has some security issue in one of its components (CVE-2018-25032) and this is maybe worth an update?

For the moment I plan to disable compression in my software. It will cause higher bandwith consumption and needs more space. But better than customer discussions about a possible security issue

Mid term, I would have to replace the PB Packer Library with an external dll like minizip. But that would be another low punch for PureBasic here in the company. Therefore, I keep fingers crossed that Fred is also making updates for security related reasons.

[idle]

if its really critical to your business and customers maybe ask Fred directly for an update you can drop in to the library folder, If I can download and build zlib in 5 mins I'm sure he can too. I just don't have the right version of VS or the right windows SDK to build static libs that are compatible with the c runt time pb uses.

[Kukulkan]

Hi Idle,

thanks, yes, that is possibly a way. Currently here we agreed all for waiting until end of next week. We do not see a realistic attack on our system because of the process flow. It only would be for confidence. We will keep an eye on it and, if we decide for the need to do something, we will re-evaluate our options.

[fryquez]

is there a problem with MinGW compiled libs?

https://www.mediafire.com/file/yfpuzmji ... 2.zip/file

[Fred]

I will update it for next beta.

[Kukulkan]

I will update it for next beta.

Thanks Fred. The beta of the current 5.73 LTS version? That would be great!

If you do only for the upcomming PB 6 release, that would be a problem for us. Our software is commercial and we will not release with a PB beta version for sure. And we will not even try to port the whole software to PB 6 until the first patches are available. We have hundreds of workarounds, GTK, QT and WebGadget fixes and workarounds etc. Also we're using libcurl, sqlite and other libs linked directly. I hope you understand that we have to be careful with new releases. Of course, I will do tests if the new version 6 final is out and also report any issues here. But I doubt that using PB6 for production is possible that soon.

[Caronte3D]

In case my experience is useful for you...
After a lot of testing, we used PB6 in a complex commercial product with no problem and no source code changes.
I think it's worth (at least) testing if it works correctly in your case

[Kukulkan]

Thanks Caronte3D. This sounds promising