Thread: Zlib vulnerability heads-up.
As PostgreSQL uses the zlib library (for TOAST?), this is a headsup that a bug has been found in the zlib library that could cause data corruption or a security breach. See http://www.gzip.org/zlib/advisory-2002-03-11.txt for more details. Updating zlib is strongly recommended by many sources, and a patch is available. I have only posted this to HACKERS; if a cross-post to GENERAL or ADMIN is useful, that can be arranged. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes: > As PostgreSQL uses the zlib library (for TOAST?), this is a headsup that a > bug has been found in the zlib library that could cause data corruption or a > security breach. > > See http://www.gzip.org/zlib/advisory-2002-03-11.txt for more details. > > Updating zlib is strongly recommended by many sources, and a patch is > available. > > I have only posted this to HACKERS; if a cross-post to GENERAL or ADMIN is > useful, that can be arranged. FWIW, I really doubt this is much of a problem for postgresql. It's mainly a problem for applications dealing with untrusted, compressed data (webbrowsers, imageviewers, programs with skins downloaded from the Internet) etc. -- Trond Eivind Glomsrød Red Hat, Inc.
Lamar Owen wrote: [Charset iso-8859-15 unsupported, filtering to ASCII...] > As PostgreSQL uses the zlib library (for TOAST?), this is a headsup that a > bug has been found in the zlib library that could cause data corruption or a > security breach. PostgreSQL does not use the zlib library for toast. The algorithm used in toast is based on Adisak Pochanayon's SLZ. Jan > > See http://www.gzip.org/zlib/advisory-2002-03-11.txt for more details. > > Updating zlib is strongly recommended by many sources, and a patch is > available. > > I have only posted this to HACKERS; if a cross-post to GENERAL or ADMIN is > useful, that can be arranged. > -- > Lamar Owen > WGCR Internet Radio > 1 Peter 4:11 > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com # _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
On Tuesday 12 March 2002 11:34 am, Jan Wieck wrote: > Lamar Owen wrote: > [Charset iso-8859-15 unsupported, filtering to ASCII...] > > As PostgreSQL uses the zlib library (for TOAST?), this is a headsup that > > a bug has been found in the zlib library that could cause data > > corruption or a security breach. > PostgreSQL does not use the zlib library for toast. The > algorithm used in toast is based on Adisak Pochanayon's SLZ. Good. I think. But what _does_ use zlib in PostgreSQL? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Tuesday 12 March 2002 11:24 am, Trond Eivind Glomsrød wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > Updating zlib is strongly recommended by many sources, and a patch is > > available. > FWIW, I really doubt this is much of a problem for postgresql. It's > mainly a problem for applications dealing with untrusted, compressed > data (webbrowsers, imageviewers, programs with skins downloaded from > the Internet) etc. It's probably NOT a big problem; but it IS a bug in an underlying library. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Tue, 2002-03-12 at 16:05, Lamar Owen wrote: > As PostgreSQL uses the zlib library (for TOAST?), this is a headsup that a > bug has been found in the zlib library that could cause data corruption or a > security breach. > True enough, ldd on my system says that postgres is linked against zlib, but I knew that TOAST didn't use it (it uses src/backend/utils/adt/pg_lzcompress.c), so what does? After a quick look, I offer the following summary: "zlib" is listed as a loadable module in PL/Python (but I don't know whether this is related to the same zlib at all) zlib.h *is* used by the "custom" format of pg_dump. Maybe I'm missing something, though - I just did a grep for "zlib" and HAVE_LIBZ through the source. This also suggests that the postgres backend needn't be linked against zlib at all, if pg_dump is the only utility using it. The risk from this vulnerability is that someone receiving a dump in custom format and using pg_restore on it might be at risk of a trojan attack - but this seems like a very slim risk (how many people would attempt to load a data dump from an untrusted source into their DB?). Nonetheless, it's useful to know this (and it also means I've spotted the (possibly) unnecessary library link :) Regards John
Lamar Owen wrote: > On Tuesday 12 March 2002 11:34 am, Jan Wieck wrote: > > Lamar Owen wrote: > > [Charset iso-8859-15 unsupported, filtering to ASCII...] > > > As PostgreSQL uses the zlib library (for TOAST?), this is a headsup that > > > a bug has been found in the zlib library that could cause data > > > corruption or a security breach. > > > PostgreSQL does not use the zlib library for toast. The > > algorithm used in toast is based on Adisak Pochanayon's SLZ. > > Good. I think. > > But what _does_ use zlib in PostgreSQL? On a quick search I can only see pg_backup using it. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com # _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
On Tue, Mar 12, 2002 at 11:45:31AM -0500, Lamar Owen wrote: > > But what _does_ use zlib in PostgreSQL? I thought it was only pg_dump (the binary output format). A -- ---- Andrew Sullivan 87 Mowat Avenue Liberty RMS Toronto, Ontario Canada <andrew@libertyrms.info> M6K 3E3 +1 416 646 3304 x110
On Tue, 2002-03-12 at 11:46, Lamar Owen wrote: > On Tuesday 12 March 2002 11:24 am, Trond Eivind Glomsrød wrote: > > Lamar Owen <lamar.owen@wgcr.org> writes: > > > Updating zlib is strongly recommended by many sources, and a patch is > > > available. > > > FWIW, I really doubt this is much of a problem for postgresql. It's > > mainly a problem for applications dealing with untrusted, compressed > > data (webbrowsers, imageviewers, programs with skins downloaded from > > the Internet) etc. > > It's probably NOT a big problem; but it IS a bug in an underlying library. Can we just add an item to the 7.2.1 release notes suggesting that zlib 1.1.4 or greater is installed? AFAICT that should be sufficient. Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
IIRC, the issue here is that it was a double free and that it was ONLY of possible concern in the even that a specific sequence of calls were made AND a very cleaver hack was available to allow for uncontrolled/unvalidated input. While it may be worth noting, I seriously doubt this is a security issue for PostgresSQL. Greg On Tue, 2002-03-12 at 10:46, Lamar Owen wrote: > On Tuesday 12 March 2002 11:24 am, Trond Eivind Glomsrød wrote: > > Lamar Owen <lamar.owen@wgcr.org> writes: > > > Updating zlib is strongly recommended by many sources, and a patch is > > > available. > > > FWIW, I really doubt this is much of a problem for postgresql. It's > > mainly a problem for applications dealing with untrusted, compressed > > data (webbrowsers, imageviewers, programs with skins downloaded from > > the Internet) etc. > > It's probably NOT a big problem; but it IS a bug in an underlying library. > -- > Lamar Owen > WGCR Internet Radio > 1 Peter 4:11 > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html
On 12 Mar 2002, Greg Copeland wrote: > IIRC, the issue here is that it was a double free and that it was ONLY > of possible concern in the even that a specific sequence of calls were > made AND a very cleaver hack was available to allow for > uncontrolled/unvalidated input. > > While it may be worth noting, I seriously doubt this is a security issue > for PostgresSQL. It's an easy DOS for things like mozilla, netscape. For postgres, using it internally? Nah. -- Trond Eivind Glomsrød Red Hat, Inc.
On Tuesday 12 March 2002 03:22 pm, Trond Eivind Glomsrød wrote: > On 12 Mar 2002, Greg Copeland wrote: > > While it may be worth noting, I seriously doubt this is a security issue > > for PostgresSQL. > It's an easy DOS for things like mozilla, netscape. For postgres, using > it internally? Nah. Thus the subject line ending with the words 'heads-up' -- not a serious issue, but something to just take note of. Now, had it been that TOAST used it, it might have been possible, however remote it may seem, to craft something like a form item entry on a web page backended by PostgreSQL that could end up being processed by that code. Stranger things _have_ happened. And the non-script-kiddie malicious crackers out there are that devious. You really can't be too careful. And maybe all of the people on HACKERS haven't seen the CERT advisory as yet; a heads-up is just that. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen wrote: > On Tuesday 12 March 2002 11:24 am, Trond Eivind Glomsrød wrote: > > Lamar Owen <lamar.owen@wgcr.org> writes: > > > Updating zlib is strongly recommended by many sources, and a patch is > > > available. > > > FWIW, I really doubt this is much of a problem for postgresql. It's > > mainly a problem for applications dealing with untrusted, compressed > > data (webbrowsers, imageviewers, programs with skins downloaded from > > the Internet) etc. > > It's probably NOT a big problem; but it IS a bug in an underlying library. If fact, it isn't a problem at all. The only data any PostgreSQL DBA would ever pump into a restore is somethinghe built himself or something he got from a secure source, right? I mean, you don't feed some unknownscript you found on the net into the DB as the PostgreSQL superuser. In that case, someone doesn't need tohand-craft such bad compressed data, he can simply use the \! functionality of psql in his script to do whateverhe wants as user postgres. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com # _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Jan Wieck <janwieck@yahoo.com> writes: > Lamar Owen wrote: > > On Tuesday 12 March 2002 11:34 am, Jan Wieck wrote: > > > Lamar Owen wrote: > > > [Charset iso-8859-15 unsupported, filtering to ASCII...] > > > > As PostgreSQL uses the zlib library (for TOAST?), this is a headsup that > > > > a bug has been found in the zlib library that could cause data > > > > corruption or a security breach. > > > > > PostgreSQL does not use the zlib library for toast. The > > > algorithm used in toast is based on Adisak Pochanayon's SLZ. > > > > Good. I think. > > > > But what _does_ use zlib in PostgreSQL? > > On a quick search I can only see pg_backup using it. I see many more, including the postmaster: [teg@halden teg]$ ldd /usr/bin/postmaster libssl.so.2 => /lib/libssl.so.2 (0x4002e000)libcrypto.so.2 => /lib/libcrypto.so.2(0x4005c000)libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x4011f000)libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3(0x40176000)libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0x40186000)libz.so.1=> /usr/lib/libz.so.1 (0x40188000)libcrypt.so.1 => /lib/libcrypt.so.1 (0x40196000)libresolv.so.2 =>/lib/libresolv.so.2 (0x401c4000)libnsl.so.1 => /lib/libnsl.so.1 (0x401d5000)libdl.so.2 => /lib/libdl.so.2 (0x401ea000)libm.so.6=> /lib/i686/libm.so.6 (0x401ed000)libreadline.so.4 => /usr/lib/libreadline.so.4 (0x4020f000)libtermcap.so.2=> /lib/libtermcap.so.2 (0x40235000)libc.so.6 => /lib/i686/libc.so.6 (0x4023a000)/lib/ld-linux.so.2=> /lib/ld-linux.so.2 (0x40000000) [teg@halden teg]$ -- Trond Eivind Glomsrød Red Hat, Inc.
teg@redhat.com (Trond Eivind Glomsrød) writes:
>>> But what _does_ use zlib in PostgreSQL?
>>
>> On a quick search I can only see pg_backup using it.
> I see many more, including the postmaster:
AFAIK the only actual *use* of zlib is in pg_dump/pg_restore.
Pretty much all our executables will be *linked* to it, however.
This is because Autoconf doesn't conveniently support making different
LIBS lists for every executable, and so we just use one one-size-fits-
all list for all of 'em. (Perhaps AC 2.5* will make this better?)
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
> We could probably replace $(LIBS) with $(filter {the libraries you really
> want}, $(LIBS)) everywhere (see libpq Makefile). But it might be hard to
> maintain. Not sure.
I'm concerned about cross-library dependencies with that sort of thing.
eg, on some platforms maybe -lcurses requires -ltermcap, on others no.
The existing process for building the LIBS list gets this right, but
extracting a subset of the LIBS list isn't guaranteed to be right.
I'm all for trimming the LIBS list for particular executables if we
can do it ... but as Peter says, it might be a headache.
regards, tom lane
Tom Lane writes:
> This is because Autoconf doesn't conveniently support making different
> LIBS lists for every executable, and so we just use one one-size-fits-
> all list for all of 'em. (Perhaps AC 2.5* will make this better?)
Autoconf has no knowledge of what your build system looks like. It merely
tests what libraries exist and stores that knowledge in a list. It's up
to you what you do with that list.
We could probably replace $(LIBS) with $(filter {the libraries you really
want}, $(LIBS)) everywhere (see libpq Makefile). But it might be hard to
maintain. Not sure.
--
Peter Eisentraut peter_e@gmx.net