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.
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!
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.
Was this meant to be funny? Do yourself a favor and take a look in the historic of flaws in PostgreSQL.
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.
I am absolutely sure Oracle products including MySQL are much more insecure than almost anything else. There was a time you could crash Oracle 8 remotely without even bothering to write assembly language code, use a compiler or the like. telnet and some random typing was enough. MS had a similar shoddy state of database security on SQL server. Just recently a colleague of mine accidentally discovered a way of crashing the MySQL server by means of a range overflow when some sort of trigger was defined on that column.
But thanks for emitting your excrement - it just proves the nasty American tycoonism is alive and kicking.
Imagine you can do an SQL injection attack and inside the injection you have a nasty piece of binary code, which will subvert the database server and give the attacker access to ANYTHING on that database server, including entirely different schemas which happen to be located on the same server by coincidence.
I bet 10 dollars and 10 D-marks (to hell with euro) it is an artifact of C or C++, as most security issues are.
Here's a fix: http://sourceforge.net/p/sappeurcompiler/code-0/2/tree/trunk/doc/SAPPEUR.pdf
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:
THIS is why he's doing it & proof of it, here -> http://interviews.slashdot.org/comments.pl?sid=3585927&cid=43295193 when others pointed out Jeremiah Cornelius forgot to submit one of the "first post spams" masquerading as myself as AC, & mistakenly submitted one of the impersonations of myself as his registered 'luser' name here on /. forums.
Pretty pitiful actually, but like every up to no good idiot does? He screwed up & submitted it under his registered 'luser' name here.
* Jeremiah Cornelius: DO YOURSELF, and the rest of us, A GIANT FAVOR MAN: Seek professional psychiatric help!
(Since Jeremiah Cornelius obviously can't get over the fact he made a spelling error on what it is HE ALLEGEDLY DID FOR A LIVING? That's not MY fault... it's HIS!)
APK
P.S.=> I seriously must have dusted JC (in his mind @ least) for his BAD spelling error & it "got his goat"...
I.E.-> Catching what he claimed to do as a job, for YEARS he left "PENETRATION" (correct) spelled as "PENTRATION" (incorrect) on his resume on LinkedIn & I pointed it out as he & his friends trolled me as usual (webmistressrachel, gmhowell, & crew (probably ALL JC no doubt using alterate emails or TOR to do it as a possible - I've caught "them & theirs" doing it before, ala Barbara, not Barbie = TomHudson (same person))).
So THAT is what has gotten his goat in a technical debate & his "geek angst" could only come up with *trying* to "impersonate me" in every news thread on /. for the month of March 2013 so far!
(Just to attempt to 'discredit me' as a spammer here obviously)
Doing so, by posting that "$10,000 challenge" &/or reposts of my old posts on hosts file value to end users into EVERY SINGLE NEWS ARTICLE POSTED on /. ...
It's all I can think of that *might* cause such a mentally troubled 'reaction' like the Jeremiah Cornelius is doing & there's NO QUESTION he's the one doing this spamming of nearly every posted article masquerading as myself...!
... apk
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.