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

41–50 of 105 posts

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#41

Post by sfjailbird »

thibaut_barrere wrote: post #32
gingerlime wrote: post #13

"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…

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.

I would love to have Heroku add this web interface to the default PostgreSQL package: http://teampostgresql.herokuapp.com

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#42

Post by 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

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#43

Post by mryan »

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…

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.

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#44

Post by ashray »

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…

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

#45

Post by themckman »

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.

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#46

Post by ceejayoz »

ashray wrote: post #44
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…

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 "-".

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

#47

Post by Intermernet »

mark_l_watson wrote: post #14
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 ;)

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.

Do it, it involves about 3 seconds of downtime per server to run sudo aptitide update and sudo aptitude upgrade . Other package management tools should be equally speedy. If you've rolled your own postgresql binary, get the new sources, re-build, stop services, replace binaries, start services (the old drill...)

The upgrade (on Debian based systems at least) is for libpq5, postgresql-9.1 and postgresql-client-9.1 . You shouldn't need to do anything else unless, for some strange reason, you actually do have a database starting with "-".

Also, I wish you a fine hike!

(probably commented too late, but I hope you had a nice hike, nonetheless)

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#48

Post by sophacles »

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…

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.

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#49

Post by gingerlime »

thibaut_barrere wrote: post #32
gingerlime wrote: post #13

"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…

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 the heroku web/cli interface. This would be a seriously nice feature if something like that was available...

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#50

Post by manojlds »

ashray wrote: post #44
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…

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 "-".

This bug wouldn't be such a big deal if such a name was a requirement for the exploit.
Post reply on HN