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

71–80 of 105 posts

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#71

Post by fdr »

fulafel wrote: post #70
fdr wrote: post #61

Earlier quoted context omitted.

Well, I'll tell you why it is not implemented that way. I hope the restriction can be lifted some day. I am a member of the Heroku staff related to the matters at hand. The problem is the sheer number of Heroku Runtime machines which are located in a smattering of IP space, and rapidly and accurately propagating the firewall rules required for tight network access control as applications churn around in there...even…

you can do the IP space thing with IPv6.

I think you petered at at the end of my wall of text ;)

But seriously, I'm glad that I was not totally off base in letting my mind drift to IPv6. Thanks.

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#72

Post by mkopinsky »

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…

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.

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#73

Post by willlll »

thibaut_barrere wrote: post #53
mryan wrote: post #38

Earlier quoted context omitted.

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.

Simple ec2 security groups is not enough because we also run an arbitrary code execution service (dynos)

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#74

Post by fulafel »

rst wrote: post #54
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.

you don't need a firewall as long as you don't turn on remote connections. that's the listen_address option.

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#75

Post by danielweber »

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

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

#76

Post by sickpig »

weaksauce wrote: post #64
joevandyk wrote: post #57

Earlier quoted context omitted.

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

The author of the commit message I think is what the op was implying.

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

#77

Post by danielweber »

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…

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.

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#78

Post by danielweber »

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.

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.

Post reply on HN