MySQL has this as a (non-default) option. PostgreSQL (you are correct) is vulnerable in a way that cannot be turned off.
After the spate of MS SQL incidents using semicolons, all these database server developers really ought to look up the meaning of "defense in depth". Just require block syntax like Oracle, and the particularly severe "command line equivalent" form of this vulnerability goes away.
The problem is too many organizations have large code bases with some number of lazy / not quite competent programmers and insufficient review practices. No reason to make such vulnerabilities much worse than they already are.
And in fact most SQL injection is reported on badly written PHP applications - presumably since noone could be bothered writing something as gigantic as this SQL injection code
After an unseemly incident with some Joomla plugins, I try to avoid PHP applications as a matter of principle. That is not to say they can't be done well, but historically it seems to be more the exception than the rule.
As I mentioned elsewhere, MySQL can enable this dangerous behavior, but does not do it by default. You are correct that PostgreSQL is fully vulnerable to this problem. No option to turn it off either, apparently.
As I indicated earlier, MySQL has an option for this, but does not do it by default.
I stand corrected on PostgreSQL. Apparently, the developers showed the same lack of foresight as the Sybase / MS SQL developers did. Or perhaps bad ideas are contagious.
In any case, all the databases that support this behavior ought to deprecate and disable it, because in the real world, it is an invitation for severe problems. Sort of like opening root shell access to a random passersby by accident.
Good pull on MySQL. Now all you have to do is demonstrate any framework or driver that turns this potentially dangerous option on by default. The drivers for Python? Perl? PHP?
Your PostgreSQL link is inconclusive, however. A high level command line interface and a low level prepare / bind / execute interface are not the same thing. A command line interface is just another application, and the way it determines you are finished entering a command has no necessary relationship with the way the low level database interface works.
Oracle, for example, allows the use of semicolons as a top level statement terminator in SQL*Plus (the Oracle command line tool), but if you try to prepare an SQL statement with a semicolon it will throw a syntax error. "ORA-00911 invalid character", to be precise.
In fact if you enter multiple statements on a line separated by semicolons, SQL*Plus could easily prepare and execute them in series. However what really happens is this:
SQL> select sysdate from dual; select sysdate from dual; select sysdate from dual; select sysdate from dual
* ERROR at line 1: ORA-00911: invalid character
SQL*Plus takes off the second semicolon before sending the entire line to the database, but has no idea about the first, leading to the error. This error is the same error that would result if an attacker attempted to use a semicolon to inject an entirely new SQL statement.
There is no vulnerability that is being taken advantage of in MS SQL, it's a vulnerability in the app.
I said MS SQL "app" for a reason. MS SQL is not directly vulnerable, it is _indirectly_ vulnerable in spades.
If there is such a vulnerability, it exists in most major databases, including MySQL and Postgres.
Sorry. There are no databases other than MS SQL, Sybase, and derivatives that allow the injection of an entirely new SQL statement where a literal belongs. It is due to the way they support combining multiple statements separated by semicolons.
Other databases that allow you to do that (Oracle for example) use a block syntax (begin/end, etc) that makes it impossible to change a single SQL statement into multiple SQL statements by inline substitution.
All SQL databases are of course vulnerable to predicate expansion by inline substitution, it is just that predicate expansion: "SELECT * FROM table WHERE x = 5 OR 1 = 1" is not remotely as exploitable as trivial statement injection "SELECT * FROM table WHERE x = 5; {arbitrary statement/procedure here}".
Predicate expansion in a select statement at best leads to an information disclosure vulnerability. Statement injection, which is only possible on Sybase and MS SQL, converts every such vulnerability into the equivalent of a root exploit.
Well designed systems have a property known as "defense in depth". MS SQL does not, and they ought to fix it, before it becomes known as the database where every sophomoric programming mistake as potentially catastrophic consequences. Talk about an Achilles' heel. An entirely unnecessary one.
This particular type of SQL injection is something that only Sybase and MS SQL are vulnerable to. As in impossible to exploit on an application using the same sloppy programming practices on any other database.
Of course that is not to say those applications can't be exploited in other, more generic ways (predicate injection mostly), regardless of database. But only MS SQL and Sybase allow attacks on such poorly written applications carte blanche over the entire database.
It is not really their fault, but it is something they ought to fix. Given the literacy level in the ASP / PHP /... programming world, this type of vulnerability will probably be with us for decades, and the MS SQL multi-statement syntax makes an exploit far worse than it needs to be.
It is sort of like auto-upgrading a information disclosure vulnerability into a root exploit. It is that bad.
The severity refers to a type of vulnerability that *every* MS SQL app that does not properly bind variables is subject to, one that is much worse than applications that use other databases.
Of course you have to find an application that has a particular instance of the vulnerability in order to exploit it. MS SQL makes an attacker's life much easier in that regard too.
SQL injections don't target SQL servers or web servers.
This particularly severe type of attack only affects poorly written MS SQL and Sybase applications, due to the way those two database allow SQL statements to be combined.
Other databases are vulnerable in combination with poorly written applications too, just not nearly as badly.
It is not an IIS problem. This particularly severe type of attack only works with MS SQL and Sybase applications, and MS SQL only runs on Windows servers, which typically run IIS.
MS SQL in combination with Apache would be just as vulnerable, given the same sloppy programming practices. Other databases as well, just not to the same degree.
The SQL code may be MSSQL specific, but there's nothing stopping anyone from making a MySQL version of it.
Not even close. MSSQL and Sybase are the only databases that are vulnerable to this form of SQL injection (in combination with sloppy programming).
With most databases, an SQL injection attack may result in predicate modification leading to information disclosure, too many rows getting updated, or too many rows deleted. No other databases allow an SQL statement to be trivially injected in the middle of another one when the input isn't sanitized.
This particular form of SQL injection *is* an MS SQL vulnerability. You couldn't mount an attack a tiny fraction as severe as this on on any other database other than Sybase (which MS SQL was originally derived from).
More accurately, aspects of MS SQL didn't help. No other database (other than Sybase) is even remotely as vulnerable as MS SQL is (in the presence of bad programming) due to way it lets you combine multiple statements.
Other databases that let you combine multiple statements have a block syntax that makes it impossible to inject one statement in the middle of another one. That MS SQL "feature" is practically designed to make poorly written applications vulnerable to attacks in the worst possible way. If Microsoft has a clue, they will deprecate it, provide an option to turn it off, and require some sort of block syntax to do the same thing.
it is due to sql... if the databases and website frameworks forced a different query language that forced variable parametrization, there wouldn't be any injection risk.
A query language that doesn't allow literals? That is not very practical.
Or a website framework that doesn't allow you to construct queries at runtime? That is not very practical either.
This is not SQL's fault (although MS SQL is particularly susceptible) - it is the fault of programmers who do not have a clue.
Actually, it is. Or rather MS SQL Server is much more susceptible to these kind of attacks (in combination with poorly written code) than virtually any other database.
The reason why is because in SQL Server is perfectly legal to include more than one SQL statement at a time separated by semicolons. So if you have an incompetent programmer who doesn't bind variables or sanitize input properly, an attacker can trivially inject any SQL he wants.
Other databases are vulnerable to SQL injection attacks to a degree. but in a much more limited fashion because an attacker *cannot* start an entirely new SQL statement in the middle of another one.
Other databases (notably Oracle) that support multiple statement execution require you to wrap the whole thing in "begin"/"end" blocks so they are not vulnerable to the particularly severe form of this attack that SQL Server is vulnerable to. That is why if an SQL injection attack is in the news, it is inevitably an attack on a poorly written MS SQL application.
A website is public, and you can expect the public to use the publicly accessible parts of it. However, if you find a security hole, you have no right to access that.
I agree, assuming you know or have good reason to believe it is a security hole. The presumption for a page on a public website is the other way around.
Since when [slashdot.org] does the interface being public [slashdot.org] have anything to do with whether accessing it is legal?
It has everything to do with it. If an interface is is configured so that it "is readily accessible to the general public" as part of a system traditionally designed to provide such access, a person has an implied license to use that interface to do what it it is traditionally intended to do. Otherwise you couldn't legally call someone on the phone.
If an interface is obscure enough that it is obviously not configured to provide services readily accessible to the general public, it is not a "public" interface in the legal sense of the term at all, but rather a "private" one - there is no implied license to use it, and one who does is implicitly engaged in computer trespass.
If you know or have reason to believe that an ostensibly public interface is not public at all you have crossed the line. One would have extraordinary evidence to conclude that the interface under discussion was intended to be accessed by the general public, based on its very function.
So if you forget to lock your house door or window, or a car door, or accidentally leave a window open, etc, it's ok for anybody to enter your house and look around?
A house door or window is a perfect example of something that is "private" in the legal sense of the term.
HTTP, on the other hand, was developed primarily to allow people to publish documents for public consumption. If you place a web server on a network wide open to the public and do not protect access to your documents or indicate that you intended to do so with the equivalent of a "no trespassing" sign, you are giving the public an implicit license to view what you publish. HTTP is a publishing system after all. The similarity between "publish", "public", and "publication" is not coincidental. An implied license means authorization.
The law concerning electronic communications "interception" is relevant here:
"It shall not be unlawful under this chapter or chapter 121 of this title for any person -- (i) to intercept or access an electronic communication made through an electronic communication system that is configured so that such electronic communication is readily accessible to the general public;" (18 USC 2510 (g))
If you operate a web server that is "configured so that such communication is readily accessible to the general public" you have granted an implied license as strong as the one you have to listen to a run of the mill FM radio channel.
The real question is why Microsoft doesn't implement "IE6 Frame", so all those companies that require Internet Explorer 6 compatibility can upgrade their desktop operating systems and browsers to something more modern.
IE6 is dead! Long live IE6! Or something like that...
DOS isn't a operating system, it is a system that operates disks. Porting Firefox to DOS would pretty much require you to write a modern operating system first. The disk/file support that comes with DOS just scratches the surface.
Slashdot Mirror
You are correct. PostgreSQL does have this problem, and it apparently cannot be disabled. See here.
MySQL has this as a (non-default) option. PostgreSQL (you are correct) is vulnerable in a way that cannot be turned off.
After the spate of MS SQL incidents using semicolons, all these database server developers really ought to look up the meaning of "defense in depth". Just require block syntax like Oracle, and the particularly severe "command line equivalent" form of this vulnerability goes away.
The problem is too many organizations have large code bases with some number of lazy / not quite competent programmers and insufficient review practices. No reason to make such vulnerabilities much worse than they already are.
And in fact most SQL injection is reported on badly written PHP applications - presumably since noone could be bothered writing something as gigantic as this SQL injection code
After an unseemly incident with some Joomla plugins, I try to avoid PHP applications as a matter of principle. That is not to say they can't be done well, but historically it seems to be more the exception than the rule.
As I mentioned elsewhere, MySQL can enable this dangerous behavior, but does not do it by default. You are correct that PostgreSQL is fully vulnerable to this problem. No option to turn it off either, apparently.
As I indicated earlier, MySQL has an option for this, but does not do it by default.
I stand corrected on PostgreSQL. Apparently, the developers showed the same lack of foresight as the Sybase / MS SQL developers did. Or perhaps bad ideas are contagious.
In any case, all the databases that support this behavior ought to deprecate and disable it, because in the real world, it is an invitation for severe problems. Sort of like opening root shell access to a random passersby by accident.
You can do it, yes. But it an option you have to turn on. The MySQL developers are not yet so clueless as to enable it by default.
See http://dev.mysql.com/doc/refman/5.0/en/c-api-multiple-queries.html
Good pull on MySQL. Now all you have to do is demonstrate any framework or driver that turns this potentially dangerous option on by default. The drivers for Python? Perl? PHP?
Your PostgreSQL link is inconclusive, however. A high level command line interface and a low level prepare / bind / execute interface are not the same thing. A command line interface is just another application, and the way it determines you are finished entering a command has no necessary relationship with the way the low level database interface works.
Oracle, for example, allows the use of semicolons as a top level statement terminator in SQL*Plus (the Oracle command line tool), but if you try to prepare an SQL statement with a semicolon it will throw a syntax error. "ORA-00911 invalid character", to be precise.
In fact if you enter multiple statements on a line separated by semicolons, SQL*Plus could easily prepare and execute them in series. However what really happens is this:
SQL> select sysdate from dual; select sysdate from dual;
select sysdate from dual; select sysdate from dual
*
ERROR at line 1:
ORA-00911: invalid character
SQL*Plus takes off the second semicolon before sending the entire line to the database, but has no idea about the first, leading to the error. This error is the same error that would result if an attacker attempted to use a semicolon to inject an entirely new SQL statement.
There is no vulnerability that is being taken advantage of in MS SQL, it's a vulnerability in the app.
I said MS SQL "app" for a reason. MS SQL is not directly vulnerable, it is _indirectly_ vulnerable in spades.
If there is such a vulnerability, it exists in most major databases, including MySQL and Postgres.
Sorry. There are no databases other than MS SQL, Sybase, and derivatives that allow the injection of an entirely new SQL statement where a literal belongs. It is due to the way they support combining multiple statements separated by semicolons.
Other databases that allow you to do that (Oracle for example) use a block syntax (begin/end, etc) that makes it impossible to change a single SQL statement into multiple SQL statements by inline substitution.
All SQL databases are of course vulnerable to predicate expansion by inline substitution, it is just that predicate expansion: "SELECT * FROM table WHERE x = 5 OR 1 = 1" is not remotely as exploitable as trivial statement injection "SELECT * FROM table WHERE x = 5; {arbitrary statement/procedure here}".
Predicate expansion in a select statement at best leads to an information disclosure vulnerability. Statement injection, which is only possible on Sybase and MS SQL, converts every such vulnerability into the equivalent of a root exploit.
Well designed systems have a property known as "defense in depth". MS SQL does not, and they ought to fix it, before it becomes known as the database where every sophomoric programming mistake as potentially catastrophic consequences. Talk about an Achilles' heel. An entirely unnecessary one.
This particular type of SQL injection is something that only Sybase and MS SQL are vulnerable to. As in impossible to exploit on an application using the same sloppy programming practices on any other database.
Of course that is not to say those applications can't be exploited in other, more generic ways (predicate injection mostly), regardless of database. But only MS SQL and Sybase allow attacks on such poorly written applications carte blanche over the entire database.
It is not really their fault, but it is something they ought to fix. Given the literacy level in the ASP / PHP / ... programming world, this type of vulnerability will probably be with us for decades, and the MS SQL multi-statement syntax makes an exploit far worse than it needs to be.
It is sort of like auto-upgrading a information disclosure vulnerability into a root exploit. It is that bad.
Ever heard of defense in depth?
The severity refers to a type of vulnerability that *every* MS SQL app that does not properly bind variables is subject to, one that is much worse than applications that use other databases.
Of course you have to find an application that has a particular instance of the vulnerability in order to exploit it. MS SQL makes an attacker's life much easier in that regard too.
SQL injections don't target SQL servers or web servers.
This particularly severe type of attack only affects poorly written MS SQL and Sybase applications, due to the way those two database allow SQL statements to be combined.
Other databases are vulnerable in combination with poorly written applications too, just not nearly as badly.
why are only IIS sites affected?
It is not an IIS problem. This particularly severe type of attack only works with MS SQL and Sybase applications, and MS SQL only runs on Windows servers, which typically run IIS.
MS SQL in combination with Apache would be just as vulnerable, given the same sloppy programming practices. Other databases as well, just not to the same degree.
The SQL code may be MSSQL specific, but there's nothing stopping anyone from making a MySQL version of it.
Not even close. MSSQL and Sybase are the only databases that are vulnerable to this form of SQL injection (in combination with sloppy programming).
With most databases, an SQL injection attack may result in predicate modification leading to information disclosure, too many rows getting updated, or too many rows deleted. No other databases allow an SQL statement to be trivially injected in the middle of another one when the input isn't sanitized.
This particular form of SQL injection *is* an MS SQL vulnerability. You couldn't mount an attack a tiny fraction as severe as this on on any other database other than Sybase (which MS SQL was originally derived from).
Yes, aspects of SQL probably didn't help
More accurately, aspects of MS SQL didn't help. No other database (other than Sybase) is even remotely as vulnerable as MS SQL is (in the presence of bad programming) due to way it lets you combine multiple statements.
Other databases that let you combine multiple statements have a block syntax that makes it impossible to inject one statement in the middle of another one. That MS SQL "feature" is practically designed to make poorly written applications vulnerable to attacks in the worst possible way. If Microsoft has a clue, they will deprecate it, provide an option to turn it off, and require some sort of block syntax to do the same thing.
it is due to sql... if the databases and website frameworks forced a different query language that forced variable parametrization, there wouldn't be any injection risk.
A query language that doesn't allow literals? That is not very practical.
Or a website framework that doesn't allow you to construct queries at runtime? That is not very practical either.
This is not SQL's fault (although MS SQL is particularly susceptible) - it is the fault of programmers who do not have a clue.
it's not actually a fault or exploit in MSSQL
Actually, it is. Or rather MS SQL Server is much more susceptible to these kind of attacks (in combination with poorly written code) than virtually any other database.
The reason why is because in SQL Server is perfectly legal to include more than one SQL statement at a time separated by semicolons. So if you have an incompetent programmer who doesn't bind variables or sanitize input properly, an attacker can trivially inject any SQL he wants.
Other databases are vulnerable to SQL injection attacks to a degree. but in a much more limited fashion because an attacker *cannot* start an entirely new SQL statement in the middle of another one.
Other databases (notably Oracle) that support multiple statement execution require you to wrap the whole thing in "begin"/"end" blocks so they are not vulnerable to the particularly severe form of this attack that SQL Server is vulnerable to. That is why if an SQL injection attack is in the news, it is inevitably an attack on a poorly written MS SQL application.
A website is public, and you can expect the public to use the publicly accessible parts of it. However, if you find a security hole, you have no right to access that.
I agree, assuming you know or have good reason to believe it is a security hole. The presumption for a page on a public website is the other way around.
Don't forget about the settings for the network card, and the video card, and a DOS extender...
Since when [slashdot.org] does the interface being public [slashdot.org] have anything to do with whether accessing it is legal?
It has everything to do with it. If an interface is is configured so that it "is readily accessible to the general public" as part of a system traditionally designed to provide such access, a person has an implied license to use that interface to do what it it is traditionally intended to do. Otherwise you couldn't legally call someone on the phone.
If an interface is obscure enough that it is obviously not configured to provide services readily accessible to the general public, it is not a "public" interface in the legal sense of the term at all, but rather a "private" one - there is no implied license to use it, and one who does is implicitly engaged in computer trespass.
If you know or have reason to believe that an ostensibly public interface is not public at all you have crossed the line. One would have extraordinary evidence to conclude that the interface under discussion was intended to be accessed by the general public, based on its very function.
So if you forget to lock your house door or window, or a car door, or accidentally leave a window open, etc, it's ok for anybody to enter your house and look around?
A house door or window is a perfect example of something that is "private" in the legal sense of the term.
HTTP, on the other hand, was developed primarily to allow people to publish documents for public consumption. If you place a web server on a network wide open to the public and do not protect access to your documents or indicate that you intended to do so with the equivalent of a "no trespassing" sign, you are giving the public an implicit license to view what you publish. HTTP is a publishing system after all. The similarity between "publish", "public", and "publication" is not coincidental. An implied license means authorization.
The law concerning electronic communications "interception" is relevant here:
"It shall not be unlawful under this chapter or chapter 121 of this title for any person -- (i) to intercept or access an electronic communication made through an electronic communication system that is configured so that such electronic communication is readily accessible to the general public;" (18 USC 2510 (g))
If you operate a web server that is "configured so that such communication is readily accessible to the general public" you have granted an implied license as strong as the one you have to listen to a run of the mill FM radio channel.
The real question is why Microsoft doesn't implement "IE6 Frame", so all those companies that require Internet Explorer 6 compatibility can upgrade their desktop operating systems and browsers to something more modern.
IE6 is dead! Long live IE6! Or something like that...
What's next? a DOS version
DOS isn't a operating system, it is a system that operates disks. Porting Firefox to DOS would pretty much require you to write a modern operating system first. The disk/file support that comes with DOS just scratches the surface.
That's because they didn't tie the rope tight enough.