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, Informative)
And from Postgres we have:
http://www.postgresql.org/about/news/1454/ [postgresql.org]
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...
Re:Say what? Streisand effect on security perhaps? (Score:5, Informative)
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.
How would an attack happen? (Score:4, Informative)
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.