Security Fix Leads To PostgreSQL Lock Down 100
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.'"
Re:Say what? Streisand effect on security perhaps? (Score:5, Insightful)
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.
Re:That's not a good approach (Score:5, Insightful)
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.
Re:Say what? Streisand effect on security perhaps? (Score:5, Insightful)
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.
Re:That's not a good approach (Score:5, Insightful)
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.
Re:Wrong move (Score:5, Insightful)
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.
Re:That's not a good approach (Score:5, Insightful)
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.
Re:That's not a good approach (Score:5, Insightful)
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.
Re:Say what? Streisand effect on security perhaps? (Score:5, Insightful)
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.)