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.'"
Make sure that users of your open source project are not even able to find out what attack vector exists on their systems. They should languish in the hopes that your team will fix it before malicious hackers figure out what it was. From the code they already checked out.
Obscurity will protect everyone.
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.
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.
How is this worse than announcing the vulnerability publicly? If they had done that, no one would even need to hunt for the vulnerability. They would just have to read the announcement.
Risk of being exploited versus risk of updating your software. If you decide the risk of updating is lower than the risk of exploitation, you update. OH WAIT, THERE'S NO UPDATE READY UNTIL NEXT WEEK.
Support my political activism on Patreon.
My thought is that their reaction is exactly the wrong move. All it does is announce to the bad guys that there's a vulnerability they can exploit (which they probably know about already) and that none of their targets will know what it is or how to spot an attempt to exploit it, while at the same time insuring that the admins responsible for PgSQL servers can't find out what they need to protect against. If the vulnerability is that critical and severe that it can't be discussed, then as an admin it's critical and severe enough that I need to do something to mitigate it RIGHT FRAKKIN' NOW! I can't wait until Monday, I need to do something today to keep my PgSQL servers from being exploited. But as it stands the only thing I can do is shut them down completely and migrate fast to some other database. I can't wait, if I could the PgSQL team wouldn't be this panicked about the problem.
The only train wreck is your mind.
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.
You're no longer a script kiddie when you can find an undisclosed vulnerability in a source code base as large as PostgreSQL. You've graduated to cyber criminal.
No. You become a cyber criminal when you abuse the vulnerability. When you can find one, you're a successful security auditor.
Upward mobility is a slippery slope - the higher you climb the more you show your ass.
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.
For the DBs I've worked with, using stored procedures basically eliminates the threat of SQL injection
Do these databases allow passing a list of values to a parameterized statement or stored procedure? For example, some features in some of the web applications I've developed require defining a procedure that takes an array and passes it to something like SELECT last_login_time FROM users WHERE username IN ?. The trouble is that a lot of database interfaces don't allow table-valued parameters, and I can't guess how many question mark placeholders I'll need in advance, so I have to make one well-tested function that does the escaping and make sure to always use it.
And someone forgot to take his meds today...Are you really that dense that you cant tell that the only reason the "impostor" exists because you have a hard time realizing that you are wrong and/or wont let it go. It would take a complete moron to not realize that the whole reason he continues to do it is because he knows he can get you to respond by simply posting. This isnt rocket science, this is internet 101...
Let me offer you some advice on how to get rid of this "impostor"...shutup.
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.
Sure, if you have infrastructure to run a hidden repo that only your devs can access. They likely don't have this, as is the case with most FOSS projects.
Since they use git ... I would say that would be what happened.
Linked from their downloads page is this:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=summary
And its still fully accessible.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
I don't think there's anything wrong with posting this to Slashdot. Everybody already knows that any complex software will have bugs in it. This doesn't gvie any clue as to what the bug is. And anybody serious about doing a malicious penetration will already have read the announcement.
Further, this gives people warning to not start any new installs of PostGreSQL right now, because you'll just need to re-install it in a week or so.
The "religious war" thing that's going on under this story is just loud-mouthed shallow thinkers, who aren't dangerous anyway. (Because they're shallow thinkers.)
Now if the actual bug were highlighted, I'd agree with you, but I'd also blame the project for highlighting it. As it is, it looks to me as if they took a reasonable path. It's true an optimal path might have been to work off a fork of the code, and not let anyone know until the fix had been applied and tested, but there's also much to be said for warning people as soon as possible, so that they could avoid making databases currently private, accessible. Or so that they could close down access to anything really sensitive, and make sure they have good backups NOW.
I think we've pushed this "anyone can grow up to be president" thing too far.
You are making a perhaps invalid presumption as to his reasoning. It could well be that he's just used to MySQL and doesn't want to think of changing. He could have a lot of code that's dependent on incompatible features, and doesn't want to believe that this was a bad choice. Money isn't the reason for everything.
That said, I'm not really convinced that PostGreSQL is superior in all use cases to the MySQL family of databases. I do tend to think that it's generally superior, but I'm not expert in either.
I think we've pushed this "anyone can grow up to be president" thing too far.
That's interesting, because the git.postgresql.org page you linked shows recent work desicribed as "Fix page title for JSON Functions and Operators." Couple that with the fact that the Slashdot summary has a link to a Parity News page that contains a link to the Postgresql announcement, and the Parity News link is loaded with javascript in the url.
I wonder if Parity News is trying to demonstrate the Postgresql flaw?
3 things about computers: they're alive, they're self-aware, and they hate your guts.
The git source is still available (http://git.postgresql.org/gitweb/?p=postgresql.git;a=summary); it is only the patches for the bug-in-question that are closed off. This seems entirely reasonable given the severity of this vulnerability.
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:
We certainly have that infrastructure(postgresql.org has around 50(!) servers for various purposes and a dedicated master repository is one of them), what are are doing here is simply delinking the "real" master repository from the anonymous repository and other downstream clones like github for a while. There is a pretty good post form magnus with actual fact available as well: http://blog.hagander.net/archives/212-About-security-updates-and-repository-lockdown.html in case you need more information.
Seems like the best way to handle it. Fixing security flaws that touch a lot of code and doing all your development in the open aren't always compatible.
Most linux distros secure security bugs for similar reasons. They don't usually have to block as much because they don't need extensive changes and integration work to deploy security patches. Well-contained software bugs also don't need as much of this since you don't need as much coordination.
I've always admired Postgres. I just wish the SQL world wasn't so fragmented and that Linux had better DB abstraction so that I wouldn't be stuck with whatever DB created the client libs linked by the application...
This seems like a really dumb move. What the team has done now is to raise the exposure level of this vulnerability by a HUGE margin. Now all any script kiddie needs to do is find a mirror of the code from 24 hours ago or any other recent period, which is likely quite trivial to do with an open source project as large as postgresql, and hunt for the vulnerability. They know it will be pretty bad since they did this action!
Raising exposure helps companies prepare for a database change. I know if we were using Postgres, we would be scheduling time for the upgrades an preparing for potential down time if needed. We would be going through all our database code to identify exactly what needs to be checked after the upgraded software and documenting as much as possible. Because if this is major, the changes could effect the way our code integrates with the database. For example, if its an authentication breach, then much of our own code would need to be changed to accomodate it.
In any case, I dont think companies are concerned about what "script kiddies" are going to do about it, and instead are happy to be alerted to security fixes of an urgent nature.
No, you just dynamically build a statement that has the correct number of placeholders (using no user-supplied data except to determine that number, and none in the statement itself) and then execute it.
Making sure that the placeholders remain in the same order as the values that will be substituted into the placeholders is almost as troublesome as substituting literal values. For example, a statement involving WHERE foo = ? AND bar IN ? will misbehave, possibly almost as catastrophically as in an injection, if another part of the code is modified to add the value for foo to the list after the values for bar have been added and the part that creates the query containing placeholders is not updated in perfect sync. And is it really substantially easier to make a function that produces a variable list of placeholders than it is to make a function that produces a variable list of correctly escaped values?
Furthermore, some database access layers make it difficult to pass a variable number of arguments to a query. One of these is MySQLi for PHP, which requires obscure gyrations involving call_user_func_array and references, whose exact details have been seen to change from PHP version to PHP version even within the PHP 5.x series. If your answer for this is "then ditch MySQLi", watch the number of concurrent connections between the application layer and database layer per concurrent user double as the application layer has to keep two connections open: one for those queries that have been ported from MySQLi to something else and one for those that have not. Doubling the connections per user halves the number of concurrent users needed to trigger "Failed to open a database connection: too many connections" errors.