News for hackers. Stuff that matters.
Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by timdorr on Thursday April 04, 2013 @10:42AM (#5492929)
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
Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by themckman on Thursday April 04, 2013 @10:59AM (#5493023)
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.
Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by sickpig on Thursday April 04, 2013 @11:23AM (#5493172)
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 by drbawb on Thursday April 04, 2013 @12:16PM (#5493453)
What gets me about Tom Lane is that he's _so active_ on the mailing list(s).

It seems that every time I search the archives regarding an issue I'm having: I find a reply authored by Tom Lane.

Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by joevandyk on Thursday April 04, 2013 @11:53AM (#5493335)
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 by mkopinsky on Thursday April 04, 2013 @12:10PM (#5493422)
Who writes commit messages for these kinds of user-submitted patches? The author or the committer?
Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by selenamarie on Thursday April 04, 2013 @01:25PM (#5493858)
Generally the committer writes the commit message. There is occassionally discussion of specific wording ahead of time.
Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by jeltz on Thursday April 04, 2013 @01:24PM (#5493848)
Usually the committer. Most patches sent to the mailing list does not contain a commit message.
Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by weaksauce on Thursday April 04, 2013 @12:08PM (#5493419)
The author of the commit message I think is what the op was implying.
Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by sickpig on Thursday April 04, 2013 @12:31PM (#5493544)
Yep this is what I meant. I could have chosen my words in a better way though, since we were talking about a git commit. Having said that quoting commit message 2nd last paragraph:

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.

We can't exclude without further info that Tom contributed to the fix, just saying.

Knowing him after a few years spent following postgres dev process I bet on co-authoring at least :)

Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by ashray on Thursday April 04, 2013 @10:47AM (#5492967)
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 "-".
Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by ceejayoz on Thursday April 04, 2013 @11:06AM (#5493076)
I don't think you have to have a database starting with - for the bug to work.
Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by jonknee on Thursday April 04, 2013 @01:13PM (#5493784)
No, but thankfully you do need postgres to be accessible remotely.
Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by achillean on Thursday April 04, 2013 @03:33PM (#5494744)
Which is not an uncommon situation actually. I've only started surveying the Internet for PostgreSQL for a bit more than a day and I've already discovered more than a hundred thousand (168,031) remotely-accessible PostgreSQL instances: http://www.shodanhq.com/search?q=port%3A5432
Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by krg on Thursday April 04, 2013 @03:51PM (#5494837)
I'm surprised this is so common. I've never set up any database accessible to the public-- I've already got to worry about securing the public-facing web server, why add another vector for attack?
Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by siddboots on Friday April 05, 2013 @03:38AM (#5497203)
Even without being publically accessible, it's a DBA's nightmare scenario. There are plenty of corporate data warehousing environments in which many hundreds of employees have direct access to the database. This exploit would allow any of those employees to drop tables without exposing their credentials.
Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by selenamarie on Thursday April 04, 2013 @06:11PM (#5495605)
In one case, a large service provider is specifically providing that kind of database access to their customers.

And to be fair: http://www.shodanhq.com/search?q=mysql

Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by achillean on Thursday April 04, 2013 @07:31PM (#5495956)
You get a lot more results if you search for the service/ port directly! http://www.shodanhq.com/search?q=port%3A3306
Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by syncsynchalt on Thursday April 04, 2013 @04:49PM (#5495234)
Or you'll need such a weird design that user input is translated to database names.

I suspect that's why they weren't able to tell people that if your db port is secure you're safe.

Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by rosser on Thursday April 04, 2013 @03:37PM (#5494763)
Or have a Bad Guy in your network...
Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by jonknee on Thursday April 04, 2013 @04:53PM (#5495255)
I firewall all traffic so not only is psql not open remotely (the users are tied to hosts), but the traffic never even makes it there unless you are coming from an authorized machine. It would take a really bad guy on the network to cause trouble here and at that point the database is not my biggest concern.
Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by manojlds on Thursday April 04, 2013 @11:19AM (#5493140)
This bug wouldn't be such a big deal if such a name was a requirement for the exploit.
Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by danielweber on Thursday April 04, 2013 @12:31PM (#5493542)
Can someone follow up on this? Do you need the db name to already begin with "-" to exploit this?

EDIT: No, the problem is in parsing, not the existing names: https://news.ycombinator.com/item?id=5492508

Re:PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released by ashray on Thursday April 04, 2013 @12:56PM (#5493680)
Thanks for clearing that up. I read the commit notes but it wasn't 100% clear and I was quite sure there's more to it considering this was all so hush-hush!