Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

postgresql.org

Post reply on HN
Print view View original

51–60 of 105 posts

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#51

Post by sickpig »

themckman wrote: post #45
timdorr wrote: post #42

The commit that fixes it with a few more details: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitd... An oversight in commit e710b65c1c56ca7b91f662c63d37ff2e72862a94 allowed database names beginning with "-" to be treated as though they were secure command-line switches; and this switch processing occurs before client authentication, so that even an unprivileged remote attacker could exploit the bug, need…

That is a fantastic commit message. I try and convince anyone I work with that they should write commit messages like this. Slowly, but surely, they come around.

And the author is a fantastic coder/developer, really!

https://en.wikipedia.org/wiki/Tom_Lane_%28computer_scientist...

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#52

Post by jeltz »

qompiler wrote: post #11
sgift wrote: post #6

Earlier quoted context omitted.

Just from the quote cited by octo_t I would read that you are still vulnerable: A malicious database user could craft a _connection string_ which contains a database name starting with -. There's no hint that the database has to exist on your server for this to work, so I would read it could be a complete bogus request and still damage your files.

/* Is this all it takes? */ PQconnectdb("host=127.0.0.1 dbname=-exploit user=postgres password=postgres port=5432");

Yes, but that wouldn't do anything harmful. Something like dbname="-r /var/lib/postgresql/9.1/main/pg_clog/0000" would be required to cause any harm. I have not tested it in practice but that should cause the server to overwrite the file with log output.

EDIT: They are not overwritten but just appended to.

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#53

Post by thibaut_barrere »

mryan wrote: post #38
thibaut_barrere wrote: post #32

Earlier quoted context omitted.

I would definitely pay Heroku a bit more to restrict access of a Heroku PG instance to a given EC2 security group. I couldn't find a PG hosting provider with more useful features than Heroku - with that, it would be a killer option.

It certainly seems feasible with the use of VPC and Security Groups. At the very least I think they should offer an option that only you to restrict access so only your dynos have access to the postgres port.

I'd love to use it with any EC2 installation (EngineYard, stock EC2 etc).

If only they could limit access to EC2 security groups, it would be amazing.

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#54

Post by rst »

Bootvis wrote: post #8

I'm not an expert so I'll ask here: Is there an attack vector if you run PostgreSQL locally, no untrusted users are able to create connection strings and do not allow remote access? It seems to be no but I prefer to be sure ;)

A firewall might be adequate; configuring postgres itself seems not to be. The vulnerable code is invoked before client authentication, so anyone who can make a tcp connection to the postmaster process can exploit the attack, even if their source IP would otherwise get them unconditionally bounced.

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#55

Post by jeltz »

__alexs wrote: post #18
octo_t wrote: post #5

This is the main vulnerability I presume > A connection request containing a database name that begins with "-" may be crafted to damage or destroy files within a server's data directory I just. No words.

The FAQ makes no mention of this massive data loss possibility which seems a bit odd…

The exploit does not actually destroy the files. It allows appending data to the files making the server crash. The file could be recovered by simply removing the junk data added to it.

From the FAQ:

> Persistent Denial of Service: an unauthenticated attacker may use this vulnerability to cause PostgreSQL error messages to be appended to targeted files in the PostgreSQL data directory on the server. Files corrupted in this way may cause the database server to crash, and to refuse to restart. The database server can be fixed either by editing the files and removing the garbage text, or restoring from backup.

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#57

Post by joevandyk »

sickpig wrote: post #51
themckman wrote: post #45

Earlier quoted context omitted.

That is a fantastic commit message. I try and convince anyone I work with that they should write commit messages like this. Slowly, but surely, they come around.

And the author is a fantastic coder/developer, really! https://en.wikipedia.org/wiki/Tom_Lane_%28computer_scientist...

Tom committed the fix, he didn't author it.

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#58

Post by craigkerstiens »

gingerlime wrote: post #49
thibaut_barrere wrote: post #32

Earlier quoted context omitted.

I would definitely pay Heroku a bit more to restrict access of a Heroku PG instance to a given EC2 security group. I couldn't find a PG hosting provider with more useful features than Heroku - with that, it would be a killer option.

yes, when I did my little research for hosted PG, heroku was pretty much the only viable option. That said, I did come across some difficulties running `rake spec` against the heroku hosted db (since you can't drop the database, only individual tables). This was giving me some (unrelated) headache. Another thing I was really hoping for but couldn't find with heroku, was being able to do a point-in-time-restores via t…

Product manager of Heroku Postgres here; if you specifically need this functionality around point in time restores you should reach out to us. Would love to hear more around the use cases behind it.

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#59

Post by keypusher »

ipsin wrote: post #22

I'm a little confused about their release strategy. Perhaps someone can explain it to me. They took their repositories private to secretly develop the bug fix. Then they released the fixed versions along with what seem to be enough details to trigger the bug for anyone who hasn't patched. Sure the patch contains the same information in source form, but if they'd gone light on details while saying "seriously, go get t…

Take a lesson from open source, security through obscurity does not work. Better to be fully transparent and honest about the flaws and their fixes, and get the word out there so that people update their boxes quickly.

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#60

Post by __alexs »

jeltz wrote: post #55
__alexs wrote: post #18

Earlier quoted context omitted.

The FAQ makes no mention of this massive data loss possibility which seems a bit odd…

The exploit does not actually destroy the files. It allows appending data to the files making the server crash. The file could be recovered by simply removing the junk data added to it. From the FAQ: > Persistent Denial of Service: an unauthenticated attacker may use this vulnerability to cause PostgreSQL error messages to be appended to targeted files in the PostgreSQL data directory on the server. Files corrupted i…

You actually expect most users to figure that out? Especially if corrupted with stuff that looks vaguely like regular postgres data...
Post reply on HN