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?
PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released
31–40 of 105 posts
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 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
#33I'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 ;)
Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released
#34Earlier 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.
Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released
#35Earlier 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…
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
#36Earlier 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/
Re: PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released
#37Earlier 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
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.
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
#39I'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?
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
#40Earlier 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?