Horton
Menu

Thread

  1. Zlib vulnerability heads-up.

    Lamar Owen <lamar.owen@wgcr.org> — 2002-03-12T16:05:24Z

    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

  2. Re: Zlib vulnerability heads-up.

    Trond Eivind Glomsrød <teg@redhat.com> — 2002-03-12T16:24:10Z

    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.

  3. Re: Zlib vulnerability heads-up.

    Jan Wieck <janwieck@yahoo.com> — 2002-03-12T16:34:13Z

    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

  4. Re: Zlib vulnerability heads-up.

    Lamar Owen <lamar.owen@wgcr.org> — 2002-03-12T16:45:31Z

    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

  5. Re: Zlib vulnerability heads-up.

    Lamar Owen <lamar.owen@wgcr.org> — 2002-03-12T16:46:49Z

    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

  6. Exclusive Row access???

    Lance Ellinghaus <lellinghaus@yahoo.com> — 2002-03-12T17:12:29Z

    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

  7. Re: Zlib vulnerability heads-up.

    John Gray <jgray@azuli.co.uk> — 2002-03-12T17:18:35Z

    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

  8. Re: Zlib vulnerability heads-up.

    Jan Wieck <janwieck@yahoo.com> — 2002-03-12T17:58:59Z

    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

  9. Re: Exclusive Row access???

    Fran Fabrizio <ffabrizio@mmrd.com> — 2002-03-12T18:03:15Z

    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

  10. Re: Zlib vulnerability heads-up.

    Andrew Sullivan <andrew@libertyrms.info> — 2002-03-12T18:20:17Z

    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

  11. Re: Zlib vulnerability heads-up.

    Neil Conway <nconway@klamath.dyndns.org> — 2002-03-12T18:51:14Z

    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. Re: Zlib vulnerability heads-up.

    Greg Copeland <greg@copelandconsulting.net> — 2002-03-12T20:18:02Z

    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

  13. Re: Zlib vulnerability heads-up.

    Trond Eivind Glomsrød <teg@redhat.com> — 2002-03-12T20:22:45Z

    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.

  14. Re: Zlib vulnerability heads-up.

    Lamar Owen <lamar.owen@wgcr.org> — 2002-03-12T20:50:01Z

    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

  15. Re: Zlib vulnerability heads-up.

    Jan Wieck <janwieck@yahoo.com> — 2002-03-12T21:00:56Z

    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

  16. Re: Zlib vulnerability heads-up.

    Trond Eivind Glomsrød <teg@redhat.com> — 2002-03-12T23:30:42Z

    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.

  17. Re: Zlib vulnerability heads-up.

    Tom Lane <tgl@sss.pgh.pa.us> — 2002-03-13T14:50:16Z

    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

  18. Re: Zlib vulnerability heads-up.

    Peter Eisentraut <peter_e@gmx.net> — 2002-03-13T19:46:00Z

    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

  19. Re: Zlib vulnerability heads-up.

    Tom Lane <tgl@sss.pgh.pa.us> — 2002-03-13T20:01:39Z

    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