PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

[timdorr]

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, needing only connectivity to the postmaster's port.  Assorted
    exploits for this are possible, some requiring a valid database login,
    some not.  The worst known problem is that the "-r" switch can be invoked
    to redirect the process's stderr output, so that subsequent error messages
    will be appended to any file the server can write.  This can for example be
    used to corrupt the server's configuration files, so that it will fail when
    next restarted.  Complete destruction of database tables is also possible.

    Fix by keeping the database name extracted from a startup packet fully
    separate from command-line switches, as had already been done with the
    user name field.
    
    The Postgres project thanks Mitsumasa Kondo for discovering this bug,
    Kyotaro Horiguchi for drafting the fix, and Noah Misch for recognizing
    the full extent of the danger.
    
    Security: CVE-2013-1899

[themckman]

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.

[ashray]

I'm really happy that the PostgreSQL team was able to fix this so quickly and it does appear to be a massive security issue. However, on the flip side, in 13+ years of web development work, I've never really seen a database name beginning with "-".

[gingerlime]

"Heroku was given access to updated source code which patched the vulnerability at the same time as other packagers. Because Heroku was especially vulnerable, the PostgreSQL Core Team worked with them both to secure their infrastructure and to use their deployment as a test-bed for the security patches, in order to verify that the security update did not break any application functionality. Heroku has a history both of working closely with community developers, and of testing experimental features in their PostgreSQL service."

I believe all the heroku hosted postgresql servers are externally accessible and there's no way to filter access by IP.

Of course hindsight is always 20:20, but perhaps it's a good idea for heroku to consider adding some basic (optional) firewall layer to allow customers to control who can connect to the hosted db?

Disclaimer: I'm not a heroku customer. I did however consider moving our pg's over to them a little while ago.

[thibaut_barrere]

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.

[edwinvlieg]

More information about the security release can also be found in the special FAQ:

http://www.postgresql.org/support/security/faq/2013-04-04/

[ipsin]

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 this", there'd probably be fewer curious vandals trying to delete your database while you're reading HN.

[mryan]

I like to know exactly why I'm updating my database before I apply any patches. I doubt they could have been sufficiently light on the details, while still giving admins enough information to decide whether or not to upgrade.

"Apply this patch, don't worry what it does, just do it" is not something I want to hear from my database vendor :-)

Had the repos remained public, this detailed information would have been available to a lot more people, a lot sooner. Temporarily "going dark" to work on the patch seems like an acceptable compromise.

[sophacles]

Not really, any big project has people going over every commit to see what changed. Any commits that are associated with a security release are particularly scrutinized. Within an hour of release there would already be people talking about the vulnerability, as well as example code for triggering it. Full disclosure is better, because even if people can't do an upgrade, they can choose to block ports at firewalls, turn off databases, and other mitigation methods immediately, as they are allowed to.

Hiding the information just weakens the defender position, not the attacker position. Secrecy in implementation is not security, it is just stupidity.

[danielweber]

If they were closed source, they could probably get away with it, buying hours to days of time before someone reverse-engineers the attack.

They are open source, though, and many people who use it build from source. It is very very easy for complete amateurs to look through the source and see what changed in a manner of minutes.

[mkopinsky]

While this comment is wrong, it does not deserve the downvotes that it's gotten. The guy asked a reasonable question, now let's be polite and answer it (as this comment's sibling indeed do). Downvotes should be reserved for comments that undermine productive discussion.

[keypusher]

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.

[facorreia]

"This update fixes a high-exposure security vulnerability in versions 9.0 and later. All users of the affected versions are strongly urged to apply the update immediately."

[simon_kun]

It's testament to Canonical that Ubuntu 8.04 LTS still gets security patches backported to 8.3. If you (still) have servers running Hardy, it's 'apt-get upgrade' time: http://www.ubuntu.com/usn/usn-1789-1/

[Bootvis]

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 ;)

[gingerlime]

as far as I understand from the FAQ page, as long as connections to your PG database are blocked from external sources, you should be safe. Seems like a good idea to upgrade as soon as possible anyway though.

  > How can users protect themselves?
  > * Download the update release and update all of your servers as soon as possible.
  > * Ensure that PostgreSQL is not open to connections from untrusted networks.
  > * Audit your database users to be certain that all logins require proper credentials, and that the only logins which exist are legitimate and in current use.

EDIT: added a quote from the FAQ for clarity.

[mark_l_watson]

I would like an answer to this, quickly, also. I am scheduled to leave on a 6 hour hike in one hour - I have time to update if I have to. I only permit localhost connections.

[rst]

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.

[rmc]

To be sure, you should upgrade. Why do you not want to upgrade?

[calpaterson]

Ubuntu repos already seem to have the fix

[joevandyk]

Sorta surprised I don't see people complaining that this release contained other changes besides the security fix.

Lots of folks complained about that (unintended) ActiveRecord change in Rails during the last security update.

[dkulchenko]

So if I have no databases that start with "-", I'm not vulnerable? Didn't quite understand what they meant by that.

[sgift]

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.

[masklinn]

Nope. Looking at the release notes:

> Fix insecure parsing of server command-line switches (Mitsumasa Kondo, Kyotaro Horiguchi)

So I assume command-line switch parsing is somehow involved in parsing the connection string (probably because the same connection strings can be used from API and from CLI?), I guess a database name with a leading `-` can be interpreted as a switch and execute corrupting commands.

edit: according to the dedicated FAQ:

> The vulnerability allows users to use a command-line switch for a PostgreSQL connection intended for single-user recovery mode while PostgreSQL is running in normal, multiuser mode. This can be used to harm the server.

[jsaxton86]

From the FAQ originally shared by edwinvlieg, you are still vulnerable:

The vulnerability allows users to use a command-line switch for a PostgreSQL connection intended for single-user recovery mode while PostgreSQL is running in normal, multiuser mode. This can be used to harm the server.

[instakill]

Should one update the local postgres version? Any write ups on how exactly to go about it?

[selenamarie]

Yes. http://www.postgresql.org/docs/9.2/static/upgrading.html , second paragraph:

PostgreSQL major versions are represented by the first two digit groups of the version number, e.g., 8.4. PostgreSQL minor versions are represented by the third group of version digits, e.g., 8.4.2 is the second minor release of 8.4. Minor releases never change the internal storage format and are always compatible with earlier and later minor releases of the same major version number, e.g., 8.4.2 is compatible with 8.4, 8.4.1 and 8.4.6. To update between compatible versions, you simply replace the executables while the server is down and restart the server. The data directory remains unchanged — minor upgrades are that simple.

[octo_t]

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.

[phillmv]

Getting this stuff right is hard. Don't be a hater.

Just because the attack vector looks simple doesn't mean the bug was obvious.

[danielweber]

If you have never released software with a security hole, it is because you have never released software.

Very smart and conscientious people can mess things up here. Shaming serves no purpose.

[__alexs]

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

[r4vik]

defense in depth though, users shouldn't be able to craft connection requests to begin with