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

Tue, 12 Mar 2002 11:05:24 -0500
Lamar Owen <lamar.owen@wgcr.org>
Zlib vulnerability heads-up.
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.

12 Mar 2002 11:24:10 -0500
teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=)
Re: Zlib vulnerability heads-up.
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


Tue, 12 Mar 2002 11:34:13 -0500 (EST)
Jan Wieck <janwieck@yahoo.com>
Re: Zlib vulnerability heads-up.
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

Tue, 12 Mar 2002 11:45:31 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: Zlib vulnerability heads-up.
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

Tue, 12 Mar 2002 11:46:49 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: Zlib vulnerability heads-up.
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


Tue, 12 Mar 2002 11:12:29 -0600
"Lance Ellinghaus" <lellinghaus@yahoo.com>
Exclusive Row access???
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



12 Mar 2002 17:18:35 +0000
John Gray <jgray@azuli.co.uk>
Re: Zlib vulnerability heads-up.
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


Tue, 12 Mar 2002 12:58:59 -0500 (EST)
Jan Wieck <janwieck@yahoo.com>
Re: Zlib vulnerability heads-up.
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



Tue, 12 Mar 2002 13:03:15 -0500
Fran Fabrizio <ffabrizio@mmrd.com>
Re: Exclusive Row access???
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


Tue, 12 Mar 2002 13:20:17 -0500
Andrew Sullivan <andrew@libertyrms.info>
Re: Zlib vulnerability heads-up.
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


12 Mar 2002 13:51:14 -0500
Neil Conway <nconway@klamath.dyndns.org>
Re: Zlib vulnerability heads-up.
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
12 Mar 2002 14:18:02 -0600
Greg Copeland <greg@CopelandConsulting.Net>
Re: Zlib vulnerability heads-up.
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.


Tue, 12 Mar 2002 15:22:45 -0500 (EST)
=?ISO-8859-1?Q?Trond_Eivind_Glomsr=F8d?= <teg@redhat.com>
Re: Zlib vulnerability heads-up.
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

Tue, 12 Mar 2002 15:50:01 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: Zlib vulnerability heads-up.
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 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@Yahoo.com #



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


Tue, 12 Mar 2002 16:00:56 -0500 (EST)
Jan Wieck <janwieck@yahoo.com>
Re: Zlib vulnerability heads-up.
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.

12 Mar 2002 18:30:42 -0500
teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=)
Re: Zlib vulnerability heads-up.
teg@redhat.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

Wed, 13 Mar 2002 09:50:16 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Zlib vulnerability heads-up. 
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


Wed, 13 Mar 2002 14:46:00 -0500 (EST)
Peter Eisentraut <peter_e@gmx.net>
Re: Zlib vulnerability heads-up. 
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

Wed, 13 Mar 2002 15:01:39 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Zlib vulnerability heads-up. 