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 your database users to be certain that all logins require proper credentials, and that the only logins which exist are legitimate and in current use.
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)
"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 risk.
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)
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.
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.
It seems to me that even large, overly bureaucratic corporations need a process in place that allows deploying critical security updates in a reasonably expedient manner. Is this uncommon?
Well, it's only a critical security update if it affects your installation. If there's a way to protect without a quick rush software upgrade, you may as well wait until the next scheduled software upgrade.
Exactly. We were prepared for a "quick rush" but when the details were released we did a combination of nmap to look for any accidentally exposed Postgres installs + adding explicit firewall rules to reject all traffic on the related ports (all of them should be rejected by default rules anyway, but we wanted to ensure none of the ports had been accidentally opened up) "just in case", and at that point we felt we could take a slower, more measured roll out of the upgrade. In 5 minutes we were "in the clear" and could breathe a sigh of relief.
It's still important to apply the udates, as I wrote elsewhere, because it's one more way someone can mess you up badly if they have managed to penetrate other parts of our systems, but upgrades no matter how seemingly safe can also cause problems (fore example I test upgraded one VM that refused to come back up again afterwards - not Postgres' fault, but a config change someone had clearly not tested properly).
But in this case, knowing we have blocked the main attack vector means we can take the time to take a copy of each database VM we run, test apply the upgrade and verify everything works correctly before applying it live, instead of rushing it out.
The reason I wanted to not upgrade directly is that access was hard at the moment of posting. Upgrading should never wait too long but this was (luckily) defcon 1 for us.