Slashdot Mirror
Security Fix Leads To PostgreSQL Lock Down
hypnosec writes "The developers of the PostgreSQL have announced that they are locking down access to the PostgreSQL repositories to only committers while a fix for a "sufficiently bad" security issue applied. The lock down is temporary and will be lifted once the next release is available. The core committee has announced that they 'apologize in advance for any disruption' adding that 'It seems necessary in this instance, however.'"
You are assuming it is a new problem, the approach they selected tells me they have found a *MAJOR* issue in several versions of PostgreSQL; that means it's old code.
They even say, keep an eye on this next release, because you (users) need to apply it at once - this isn't something that only affect latest build.
That's exactly the point. They've locked out and shrouded the changes that are being made as they're happening, because of wide-spread collaboration causing changes, tests, etc to occur. It's going to be a week before the fix is ready, but as soon as the first bits of test code go in you can quickly target that body of code and figure out the problem, then exploit it. As-is, you now have to rummage through the whole body of vulnerable code and try to guess what's actually broke.
When the repos are opened back up, the fix will be ready. It might (probably) even be shared with the major distros, who will simultaneously have an updated package published. This greatly reduces the likelihood and window of a zero-day exploit with no fix.
Support my political activism on Patreon.
They'll have to hunt through all the code. Since a viable, production-ready fix won't be available for a week, but a new piece of code in the vulnerable body is available now, leaving the repo public would result in a week of free exploitation--they've gone and highlighted the exact bit of code the problem is in. The repos are closed, so only contributors and any downstream distribution providers that are working with them to build and test the fixed code are privy to this.
This temporary closure greatly reduces the risk of an attacker tearing down the code and finding the precise vulnerability they're trying to mitigate.
Support my political activism on Patreon.
And from Postgres we have:
http://www.postgresql.org/about/news/1454/
This is a major security issue and it affects *ALL* versions of postgres. Locking it down while updates are being created seems the right way to do it to me...
From the article:
The reason for the lockdown is to ensure that malicious users don’t work out an exploit by monitoring the changes to the source code while it is being implemented to fix the flaw.
So a mirror of the code from 24 hours ago wouldn't have any work-in-progress commits. These commits would give clues as to where the vulnerability is.
It sounds like a really good use case for distributed version control. When this sort of thing happens, developers should be able to temporarily fork the repo and work on security issues in private, while everyone else is still able to access the main repo.
My explanation accounts exactly for that and that was the point. The changes between [VULNERABLE] and [FIXED] are not public yet because the [FIXED] state is not ready for production deployment (it may be wrong, and need more work). That means you can't pop open your source tree, do a `git diff`, and go, "oh, in this code path?" and 20 minutes later have your exploit.
Now, a week from now, this stuff will all be public and fixes will be released. Then you can target exactly what's changed, while everyone else is running updates. This is different from targeting exactly what's changed and then running around buttfucking everyone while they have to wait a week to get production-ready code OR chance it with alpha-grade software in production.
Support my political activism on Patreon.
At least you have the option. And people who are exploiting shit are using Metasploit and playing around on Milw0rm anyway, seriously.
Support my political activism on Patreon.
They sent out a warning to everyone on the mailing list. I know, I got it.
You should not have your PgSQL servers exposed to the world, no any db server. You should apply the fix when it comes out. The reality as an admin is that I know odds are damn near everything we use has as yet undiscovered vulnerabilities.
Migrating anything major to another DB is pretty much a nonstarter. Nor will another DB give you even this much visibility. Oracle would never admit something like this with mysql.
Migrate to what? Postgres admitted that there is a problem. It is not known to be exploited in the wild. Do you really think Oracle, DB2, SQL Server, and MySQL have no critical security bugs in them? Or even bugs already known to the vendor in the case of the closed source ones?
Your system is no worse today than it was yesterday. You know PostgreSQL has at least 1 bug. So unless you think another system has no bugs, do not switch.
Go green: turn off your refrigerator.
I see lots of comments about needing to know the vulnerability right now, and even panic about taking servers down until it's fixed. I can't help feeling that if that's your reaction you're doing it wrong.
In any internet facing production environment, the front end web servers will be the only place that can be attacked. They should be in a DMZ and only be accessing application servers via a firewall, which in turn access the database. Access to the database would only be allowed from the application servers, and the application servers shouldn't be able to run any random SQL. All inputs should be verified before passing to the database. It's kind of hard to see how, in a well designed system, the database is at risk. Nothing uncontrolled should be reaching it.
Of course it's important to have security at every layer, but if an attack can get as far as exploiting code vulnerability in the database I'd say there's a bigger problem somewhere further up the chain.
Internal attacks are another matter, but again, access controls should be ensuring that only those who really need access to the database have access to the database. Those people will be able to do enough damage without needing exploits, so again, code vulnerability at that level should be something of a non-issue.
Sigs are so 1990s. No way would I be seen dead with one.
People looking to exploit vulnerabilities on widely-installed software (databases, programming languages, frameworks, etc.) keep an eye on commit logs to do precisely this. Those patches and commits call attention to themselves; postgres is right to ensure that a patch is available at the same time it indicates the attack vector. In fact, they'd probably be wise to make sure major binary repos have a patched copy even before making the changed source available so that sysadmins have a week to do an update from yum/apt-get/$pkgmgr
The only difference between this and patch tuesday is that you know what goes into this fix after the fact. If you see 'critical security update' in your mailing lists, it becomes a race between you updating your system and attackers figuring out how to exploit the old version; them doing so is orders of magnitude more difficult if they don't actually know what's changed.
Is it the FOSS way? No. But I'd happily take a project going closed-source for two weeks if it means my database doesn't get hacked (but then again, I'm dealing with PCI-DSS Level 1 so I kinda have to). Now hopefully people have their databases completely inside the firewall as to minimize the attack vector - assuming it has something to do with an authentication flaw, at least (and not, say, remote code execution due to a bug in parameterized queries). See - I don't know what they're changing, so I don't even know where to start probing.
How are sites slashdotted when nobody reads TFAs?
Are you positive that all the application servers you permit through the firewall are uncompromised? And that they'll remain uncompromised? Are there errors in the firewall that are allowing traffic through you don't expect? Are your servers in a data center where a mistake in the internal network could allow traffic to get to your machine from other (compromised) customers bypassing the firewall?
And does this vulnerability even require direct access to the database server, or is it one that can be triggered by data? If so, what do I need to filter in my applications to remove the kinds of bad data that could trigger the vulnerability? If normal firewalls and SQL-injection filtering would blunt the attack, I'd expect the PgSQL team to be less worried about revealing the problem because it wouldn't be very exploitable. So given their panic I have to assume that a normal installation with access to the database strictly limited by firewalls is still highly vulnerable to attacks against this bug. I'm remembering exotic bugs like ones involving non-standard UTF-8 sequences that could completely bypass SQL-injection filtering or trigger bugs in low-level libraries via ordinary data, vulnerabilities that required no special access to exploit and would work straight through the tightest of firewalls, but could be stopped dead by appropriate filtering if you knew what the problem was that you had to check against (eg. UTF-8 sequences that weren't the shortest valid sequence for that character).
Open-source doesn't magically decrease the severity or number of bugs, but it does allow more people to eventually discover them. There's an obvious trade-off here: non-malicious people can find and then report and/or fix the bugs, or malicious people can find and then exploit them. The hope is that there are more contributors than attackers finding bugs and that it ends up being a net positive for stability and security. Neither open nor closed source is the right model 100% of the time for 100% of projects.
There's no hypocrisy here - the source of the patches will be released and all future commits will be made public again. This was a short-term decision weighing practicality and security against the "religion" of OSS. It's the difference between responsible disclosure and letting the software maintainers find out about the same exploit because you blogged about it, so attackers find out at the same time. They could have one or two people developing the patch in a local branch and simply not push anything upstream until it's done and tested and have the same effect, this is just an easier approach.
How are sites slashdotted when nobody reads TFAs?
Let me get this straight, so I know we're on the same page.
There is a major vulnerability in basically ALL Postgres installations in the world. That means it has not been introduced by any recent commits. The patch(es) are not yet public, and the repositories have been made non-public while the fix is in the works.
The fix is likely delayed somewhat by the occurrence of Easter holidays. Lots of people have taken extended weekends - probably a good number of Postgres devs included. There is probably no sane way to deploy the fixed versions until after the holidays. Not everyone can afford 24/7 admins.
And you want to complain about the developers being irresponsible when dealing with this?
(For the record: I'm pretty much a full-disclosure guy, but a slightly delayed disclosure with NO IN-THE-WILD EXPLOITS for a vulnerability that is discovered just ahead of a major holiday weekend... I can live with that.)
There is no such thing as good luck. There is only misfortune and its occasional absence.
So, go to http://git.postgresql.org/gitweb/?p=postgresql.git;a=summary and look at the source.
What they've taken private is their patches for the problem until they can make it production ready.
You are still fully able to access everything you've always had access to, they've just decided not to share their newest patches for a few days/weeks until people have at least a chance to protect their systems.
Regression tests have to be run, repos need a chance to update their binary packages, all sorts of things can be done in private and made ready so that when the changes are made public ... and it becomes trivial to exploit the bug in unpatched versions since the changes show you the exploit ... users are already able to update to a fixed version.
They just aren't telling the world where the bug is until the patch has been properly distributed. You can still go look for it yourself if you want, unless you want the bad guys to know where its at and you STILL won't have a patch available. Remember, these are the guys who are making the patch so you're waiting on them for the fix regardless.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Do please check out this informative post from Magnus Hagander, one of the PostgreSQL core team members, which clarifies most of the points raised here: