Re: [BUGS] 7.2.1 segfaults.
Stephen Amadei <[EMAIL PROTECTED]> writes: > #0 0x255843 in strncpy (s1=0xbfffead0 "n\013", s2=0x8213414 "n\013", >n=4294967292) at ../sysdeps/generic/strncpy.c:82 > #1 0x81516ab in GetRawDatabaseInfo () > #2 0x81511fb in InitPostgres () Hmm. It looks like GetRawDatabaseInfo is reading a zero for the VARSIZE of datpath, and then computing -4 (which strncpy will take as a huge unsigned value) as the string length to copy. You could try applying a patch like this, in src/backend/utils/misc/database.c (about line 225 in current sources): /* Found it; extract the OID and the database path. */ *db_id = tup.t_data->t_oid; pathlen = VARSIZE(&(tup_db->datpath)) - VARHDRSZ; + if (pathlen < 0) + pathlen = 0;/* pure paranoia */ if (pathlen >= MAXPGPATH) pathlen = MAXPGPATH - 1;/* pure paranoia */ strncpy(path, VARDATA(&(tup_db->datpath)), pathlen); path[pathlen] = '\0'; However this really shouldn't be needed; I'm wondering whether the database's row in pg_database has been clobbered somehow. If so, it probably won't get much further before dying. Two questions: does the same thing happen for all available databases? Have you tried to create a database with a nonstandard location (nondefault datpath)? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] Why does Postgres need the /bin/sh?
Stephen Amadei <[EMAIL PROTECTED]> writes: > However, if someone was to know that Postgres needs a /bin/rm, an exploit > could be created that runs /bin/rm instead of /bin/sh and trashes the > databases postgres owns. Of course, this is a big IF. ;-) The attacker won't be able to do any of this unless he's already managed to connect to the database, no? There are much easier ways to zap your data at the SQL level. Sorry but I'm having a hard time getting excited about this proposition... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] 7.2.1 segfaults.
On Sat, 4 May 2002, Tom Lane wrote: > Hmm. It looks like GetRawDatabaseInfo is reading a zero for the VARSIZE > of datpath, and then computing -4 (which strncpy will take as a huge > unsigned value) as the string length to copy. You could try applying > a patch like this, in src/backend/utils/misc/database.c (about line > 225 in current sources): Wierd. > However this really shouldn't be needed; I'm wondering whether the > database's row in pg_database has been clobbered somehow. If so, > it probably won't get much further before dying. Good point. And deleting the $PGDATA directory and recreating it fixed it without a patch. > Two questions: does the same thing happen for all available databases? > Have you tried to create a database with a nonstandard location > (nondefault datpath)? No... I was creating the database in /usr/local/pgsql/data and then 'cp -aRp'ing it into the chroot. So I had two copies of the same corrupt database. Thanks for the help. Steve Stephen Amadei Dandy.NET! CTO Atlantic City, NJ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Why does Postgres need the /bin/sh?
On Sat, 4 May 2002, Tom Lane wrote: > Stephen Amadei <[EMAIL PROTECTED]> writes: > > However, if someone was to know that Postgres needs a /bin/rm, an exploit > > could be created that runs /bin/rm instead of /bin/sh and trashes the > > databases postgres owns. Of course, this is a big IF. ;-) > > The attacker won't be able to do any of this unless he's already managed > to connect to the database, no? Besides dbcommands.c, I have not looked over any Postgres code, so I cannot be certain of what happens between socket connection and authentication. I'm just paranoid. ;-) > There are much easier ways to zap your > data at the SQL level. This assumes the user authenticated. If the user authenticates, I couldn't care less if they trash their own database via SQL. > Sorry but I'm having a hard time getting excited > about this proposition... I don't blame you... it looks hard to do. Maybe I'll try it later if I get the time... for now I'm trying to wring out the last bugs of the fork/execl change. Steve Stephen Amadei Dandy.NET! CTO Atlantic City, NJ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
