Live data from Hacker News

PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

postgresql.org

31–40 of 105 posts

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#31

Earlier quoted context omitted.

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

It doesn't specify whether pg_hba.conf is sufficient to protect against this, anybody have any word on that?

I'm wondering this as well.

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#32

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

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

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

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

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#34
post #12

Earlier quoted context omitted.

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

Then how would a user use the db? Not every use of a database is behind a web application.

Well, once could use something like spiped[1], which would add a very large roadblock to any attacker.

[1]: http://www.tarsnap.com/spiped.html

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#35

Earlier quoted context omitted.

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.

From the FAQ: Who is most at risk: "Any system that allows unrestricted access to the PostgreSQL network port, such as users running PostgreSQL on a public cloud, is especially vulnerable. Users whose servers are only accessible on protected internal networks, or who have effective firewalling or other network access restrictions, are less vulnerable." So looks like it's low risk but they're not willing to say no ris…

The reason they are not willing to say no risk is presumably that if you don't upgrade, then any other security vulnerability that allows an attacker to trigger a network connection with a suitable payload to port 5432 (or any other ports you may have Postgres on) on your hosts could still be harmful.

That means anything that gives local shell as any user that run normal tools, but potentially also a lot of other things.

E.g. any software that can be tricked to try to connect to a local address/port pair and send a suitable string.

That dramatically escalates any minor little hole that might otherwise not be a risk for you.

(That's a reminder to always verify before trusting any hostname/IP a user passes you that it's not a local address or address you have privileged access to, and to also consider internally firewalling connections between your various hosts down to just what you need)

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#36
post #30
post #21

Earlier quoted context omitted.

[deleted]

This is terrible advice. Installing another postgres binary from a different source is likely going to cause you headaches. And it's not necessary - vendors such as Red Hat and Debian are fast with security updates. Given that Red Hat helped them apply for the CVE the non-version-9 fixes should be out PDQ. You can keep an eye on it here: https://access.redhat.com/security/cve/

It worked just fine but seeing as I was wrong I have deleted the post.

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#37

Earlier quoted context omitted.

Then how would a user use the db? Not every use of a database is behind a web application.

Well, once could use something like spiped[1], which would add a very large roadblock to any attacker. [1]: http://www.tarsnap.com/spiped.html

This is perfectly compatible with Postgres.

However this does not prevent any of your employees or other users of systems with access to use spipped from committing this attack. You still need a client somewhere and the server is still vulnerable.

Allowing remote connections from any IP to your database, like heroku apparently does, sounds kind of crazy to me. I can't believe they do it. But limiting and encrypting that access just limits, and does not eliminate your vulnerability to this bug.

---

Just to be really clear: Say your corporate blog stores it’s data in your main Postgres instance. As blogging engines tend to, it has a bug, and hackers succeed in using that to get access to your blog’s server. Even if you are using spiped to connect the 2 boxes they still have the ability to mess with your main database, on some other, probably much better secured, box. This bug is ugly.

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#38

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

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.

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#39
post #33
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 ;)

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

[not gp post, but this is a normal situation]

Because some folks need to go through a long, drawn out process to upgrade internal software and might already have some place in the pipeline to put the upgrade so it will get tested with everything else.

If its a security issue for your current installation, you go now and hope, but if it can wait for a release then you do that.

Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released

#40

Earlier quoted context omitted.

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

It doesn't specify whether pg_hba.conf is sufficient to protect against this, anybody have any word on that?

No, pg_hba.conf is not sufficient. I'll work on adding that to the FAQ.
Post reply on HN