Re: 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(dot)owen(at)wgcr(dot)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(at)postgresql(dot)org)
>

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)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(dot)owen(at)wgcr(dot)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

Is there a way in PostgreSQL to have a client lock a row in a table for
exclusive access?
I need to be able to lock individual rows in a table for SELECT and UPDATE
in the one client and deny all other clients from accessing those rows at
all while the lock is being held. They do need to be able to access other
rows that are not locked.

Thank you,

Lance Ellinghaus

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(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Lance Ellinghaus wrote:

> Is there a way in PostgreSQL to have a client lock a row in a table for
> exclusive access?

Might want to start with section 9.6.2 of the PostgreSQL documentation,
"Row-Level Locks". You may want SELECT FOR UPDATE, too.

-Fran

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(at)libertyrms(dot)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(dot)owen(at)wgcr(dot)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(at)rogers(dot)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(dot)owen(at)wgcr(dot)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(dot)owen(at)wgcr(dot)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 something he
built himself or something he got from a secure source,
right? I mean, you don't feed some unknown script you found
on the net into the DB as the PostgreSQL superuser. In that
case, someone doesn't need to hand-craft such bad compressed
data, he can simply use the \! functionality of psql in his
script to do whatever he 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(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Jan Wieck <janwieck(at)yahoo(dot)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(at)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(at)halden teg]$

--
Trond Eivind Glomsrød
Red Hat, Inc.

teg(at)redhat(dot)com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) 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

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(at)gmx(dot)net

Peter Eisentraut <peter_e(at)gmx(dot)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