The level of magnetic storm that could disable the power grid is much lower than anything that will damage on a handheld device. As in a couple of orders of magnitude. It is simply a matter of size - the power grid is a much bigger "antenna". A handheld device may be useless for a while, but after that it should be just fine.
The government should probably require the utilities to keep a large number of transformers on hand. It would raise rates, but compared to losing power for three to six months...
This is a case study for closed primaries. People have no business sabotaging the vote of another party. It is immoral - what if the person you oppose actually wins, and you are responsible for putting him in office? etc.
Sounds like a great idea to me. Possible performance downside on a really busy system, of course.
In general there are a handful of queries that don't take parameters, so they would need to be whitelisted somehow, perhaps by table name. There are all sorts of other fun policies you could enforce, of course.
They entered into AT&T's network, uninvited (unless you can find somewhere where AT&T gave them procedures on how to send spoofed IMSI's to the script), and basically attacked their network
I suspect what these folks did is probably illegal. However, nowhere do they appear to have "entered" AT&Ts network, where "entering" means something like bypassing a firewall or logging onto a system. What they did was send requests to an unsecured interface, and AT&T's system happily sent back the answer.
What they did wasn't really an "attack" either, with the possible exception of a denial of service attack. AT&T doesn't seem to have noticed the extra accesses, however. It was not an "attack" in part because their actions did not cause any direct harm to the systems that they accessed, nor did they apparently need to disable, work around, or compromise any substantive security protocols.
However it appears that they have "intentionally accessed a computer without authorization" and obtained "information". That is probably a violation of 18 USC 1030 (a)(2) or a comparable state law.
I should add that the level of intent required to make something a crime may differ from crime to crime, of course. General intent may not be enough in some cases.
There is no real criminal intent, or in legalese, mens rea.
Assuming the type of access they performed is proscribed by law, the only thing required to establish "criminal intent" is that they intended to do what they did.
Whether they knew what they did was against the law, whether they intended to cause anyone any harm, or whether they thought what they were doing had some beneficial social purpose is completely irrelevant to the question of criminal intent. The question is did they intend to do something that happens to be against the law.
Not even close. He didn't discover any kind of error at all, just trumpeting a fact that has been well known to database designers for about four decades now.
Because of the way VCPUs are scheduled (at least in VMWare) that 8-vCPU VM won't get a time-slice until such time as there are 8 real cores available for the duration of that slice.
That is insane. I seriously doubt it applies to anything other than VMWare, however. No doubt the VMWare folks are working to remove whatever limitation possessed them to make such a ridiculous design as well.
There is a simple fix to buffer overflows too. Check all array indexes and pointer calculations.
After all, if you are so stupid as to install any actual third party software on your system, it is your fault, right? And that of the third party application developers, for being so careless in the first place.
Since legitimate applications never have any vulnerabilities, there is no reason why operating systems need to have memory protection, right? Surely they would run a lot faster without MMUs, TLBs, user/kernel transitions, and so on. Such protections are a complete waste of time, because responsible application programmers never make such silly mistakes.
Oracle and DB2 are immune to this type of attack against an ordinary SQL statement, poorly programmed or otherwise. Perhaps both take in umpteen billion dollars for a reason. Like foresight in syntax design, perhaps.
Oracle allows multiple statements, but only with block syntax, which means poorly programmed ordinary statements are immune. DB2 does not allow multiple statements to be prepared and executed in one go at all, as far as I can tell, anyway.
The fact that these other databases allow it without block syntax does not mean it is a good idea. On the contrary, an extraordinarily bad one, due to the prevalence of incompetent code monkeys out there.
I have explained why databases that allow executing multiple SQL statements in one go without using block syntax (like Oracle does, for example) are particularly vulnerable to complete SQL statement injection several times already.
When block syntax is required to prepare and execute multiple SQL statements in one go, an ordinary dynamic SQL statement is not susceptible to complete SQL statement injection when programmed incorrectly. Instead you get a syntax error.
This is not to say that people bind parameters, just that there are too many incompetent programmers out there and databases should practice defense in depth as a consequence. Not requiring block syntax for multiple statement execution is asking for trouble.
Good pull. Unfortunately, though, this is another reason for me to avoid third party developed MySQL applications, especially anything developed in (horror of horrors) PHP.
Linking to an older version of the documentation was not intentional, by the way.
If an operating system crashed every time an application attempted to dereference a NULL pointer, would that be a vulnerability or not?
It's called the batch syntax, and it's supported by every RDBMS in existence.
Not as part of a single client API prepare / bind / execute sequence.
Oracle doesn't support it without block syntax, which means that the vast majority of all poorly programmed dynamic SQL statements are invulnerable on Oracle. MySQL doesn't have this behavior unless a client enables it.
DB2 does not have this behavior. No support for preparing and executing multiple dynamic SQL statements in one go at all. You have to create and install a UDF or stored procedure instead.
This is a simple problem to fix. All the databases that support this by default should make it an option, and disable the option by default in the next major version of the database. It is not rocket science, and would add a valuable layer of defense to any number of database applications.
The MySQL client library is the interface that all (non-internal) SQL access to the MySQL server goes through. The defaults that it sets are the ones that will be picked up by all MySQL client applications by default. And the default is OFF. You can verify that by reading the documentation.
The MySQL client library is the only way for an external application to talk to the database. As a rule, it is the only way for most internal (MySQL developed) applications to talk to the database. Database wire protocols tend to be proprietary, database specific, and poorly documented. They are always changing as new features are added, because they must support every database specific feature. As a consequence the client libraries are almost invariably developed by the database server developers and maintainers. This is true of every proprietary database, and MySQL and PostgreSQL as well. It is not an accident that the documentation for these libraries is part of the database documentation on the primary website for each.
I don't write code, by the way, that is subject to SQL injection. But that doesn't mean I have time to review the coding practices of the developers of every application I install on systems I am responsible for. That is why every database should make this an option at best, and support block syntax so that application developers have no reason to turn it on.
Otherwise it is like saying, I don't need fire insurance, because I never start any fires.
Oracle has a similar vulnerability with poorly programmed PL/SQL calls to be sure. It is just that the preponderance of dynamic PL/SQL blocks to compared to ordinary Oracle SQL statements is minimal at best. There are very large Oracle applications that do not have any dynamic PL/SQL blocks - most Oracle applications use statically code PL/SQL exclusively - typically in triggers, database functions, and stored procedures.
I know that the MySQL interface does not have this option turned on by default. I am admittedly surprised to discover that PostgreSQL not only has it by default, but it cannot be disabled.
I am quite certain that DB2 does not have this problem. There is no indication in the documentation at any rate. So it would appear that the preponderance of the severe form of the problem (by default) is about 50/50:
Oracle is not trivially vulnerable to semicolon based statement injection. The reason is that it requires block syntax to execute multiple SQL statements in the same prepare / bind / execute sequence. So an attacker cannot convert a poorly programmed SELECT statement into something that does anything other than SELECT things (assuming the word "SELECT" is hard coded of course).
In common cases where the operation type and the table names are hard coded, predicate expansion attacks could lead to a carelessly programmed SQL statement selecting, updating, or deleting too many rows. Perhaps every row in the pertinent table. But at least the attacker cannot dump your entire schema and manipulate data in any table at will.
The fact that a command line interface executes multiple queries in series with nothing but semicolons is not evidence that the database executes the same syntax with one prepare / bind / execute sequence. Big difference.
I have nothing against MS SQL, I would like to see them (and the PostgreSQL people, and the Sybase people, and (partially) the MySQL people mitigate this problem. Due to the number of semi-competent developers out there, support for syntax like this at a low level is borderline unconscionable, especially because the fix is trivial. Just do what Oracle does - require block syntax to execute multiple statements.
Every database that supports stored procedures already supports some form of block syntax, perhaps the developers should consider requiring people to use it. It is not that hard. A few characters at the beginning, a few at the end. That is all there is to it. Vulnerability to complete SQL statement injection eliminated.
Slashdot Mirror
Very nice.
Sure, that is probably a better idea. But some extra transformers, just in case.
The level of magnetic storm that could disable the power grid is much lower than anything that will damage on a handheld device. As in a couple of orders of magnitude. It is simply a matter of size - the power grid is a much bigger "antenna". A handheld device may be useless for a while, but after that it should be just fine.
I seriously doubt you are going to need a metal box. But unplugging them from the power grid and any (large) antennas is good idea.
The government should probably require the utilities to keep a large number of transformers on hand. It would raise rates, but compared to losing power for three to six months...
This is a case study for closed primaries. People have no business sabotaging the vote of another party. It is immoral - what if the person you oppose actually wins, and you are responsible for putting him in office? etc.
That works to prevent SQL statement injection, but is not adequate to prevent predicate (WHERE clause) modification, etc., which can be very serious:
DELETE FROM table WHERE x = 5 OR 1 = 1
for example.
Sounds like a great idea to me. Possible performance downside on a really busy system, of course.
In general there are a handful of queries that don't take parameters, so they would need to be whitelisted somehow, perhaps by table name. There are all sorts of other fun policies you could enforce, of course.
They entered into AT&T's network, uninvited (unless you can find somewhere where AT&T gave them procedures on how to send spoofed IMSI's to the script), and basically attacked their network
I suspect what these folks did is probably illegal. However, nowhere do they appear to have "entered" AT&Ts network, where "entering" means something like bypassing a firewall or logging onto a system. What they did was send requests to an unsecured interface, and AT&T's system happily sent back the answer.
What they did wasn't really an "attack" either, with the possible exception of a denial of service attack. AT&T doesn't seem to have noticed the extra accesses, however. It was not an "attack" in part because their actions did not cause any direct harm to the systems that they accessed, nor did they apparently need to disable, work around, or compromise any substantive security protocols.
However it appears that they have "intentionally accessed a computer without authorization" and obtained "information". That is probably a violation of 18 USC 1030 (a)(2) or a comparable state law.
I should add that the level of intent required to make something a crime may differ from crime to crime, of course. General intent may not be enough in some cases.
There is no real criminal intent, or in legalese, mens rea.
Assuming the type of access they performed is proscribed by law, the only thing required to establish "criminal intent" is that they intended to do what they did.
Whether they knew what they did was against the law, whether they intended to cause anyone any harm, or whether they thought what they were doing had some beneficial social purpose is completely irrelevant to the question of criminal intent. The question is did they intend to do something that happens to be against the law.
Not even close. He didn't discover any kind of error at all, just trumpeting a fact that has been well known to database designers for about four decades now.
These are not SMP machines. Each has an internal cluster of up to 512 separate system images, each with 2 GB of RAM and one CPU.
Because of the way VCPUs are scheduled (at least in VMWare) that 8-vCPU VM won't get a time-slice until such time as there are 8 real cores available for the duration of that slice.
That is insane. I seriously doubt it applies to anything other than VMWare, however. No doubt the VMWare folks are working to remove whatever limitation possessed them to make such a ridiculous design as well.
There is a simple fix to buffer overflows too. Check all array indexes and pointer calculations.
After all, if you are so stupid as to install any actual third party software on your system, it is your fault, right? And that of the third party application developers, for being so careless in the first place.
Since legitimate applications never have any vulnerabilities, there is no reason why operating systems need to have memory protection, right? Surely they would run a lot faster without MMUs, TLBs, user/kernel transitions, and so on. Such protections are a complete waste of time, because responsible application programmers never make such silly mistakes.
Oracle and DB2 are immune to this type of attack against an ordinary SQL statement, poorly programmed or otherwise. Perhaps both take in umpteen billion dollars for a reason. Like foresight in syntax design, perhaps.
Oracle allows multiple statements, but only with block syntax, which means poorly programmed ordinary statements are immune. DB2 does not allow multiple statements to be prepared and executed in one go at all, as far as I can tell, anyway.
The fact that these other databases allow it without block syntax does not mean it is a good idea. On the contrary, an extraordinarily bad one, due to the prevalence of incompetent code monkeys out there.
I have explained why databases that allow executing multiple SQL statements in one go without using block syntax (like Oracle does, for example) are particularly vulnerable to complete SQL statement injection several times already.
When block syntax is required to prepare and execute multiple SQL statements in one go, an ordinary dynamic SQL statement is not susceptible to complete SQL statement injection when programmed incorrectly. Instead you get a syntax error.
This is not to say that people bind parameters, just that there are too many incompetent programmers out there and databases should practice defense in depth as a consequence. Not requiring block syntax for multiple statement execution is asking for trouble.
Good pull. Unfortunately, though, this is another reason for me to avoid third party developed MySQL applications, especially anything developed in (horror of horrors) PHP.
Linking to an older version of the documentation was not intentional, by the way.
"Invulnerable to complete SQL statement injection" on Oracle I should say. Such applications are clearly vulnerable to predicate injection regardless:
SELECT * FROM table WHERE x = 5 OR 1 = 1
for example.
Stop calling it a vulnerability
If an operating system crashed every time an application attempted to dereference a NULL pointer, would that be a vulnerability or not?
It's called the batch syntax, and it's supported by every RDBMS in existence.
Not as part of a single client API prepare / bind / execute sequence.
Oracle doesn't support it without block syntax, which means that the vast majority of all poorly programmed dynamic SQL statements are invulnerable on Oracle. MySQL doesn't have this behavior unless a client enables it.
DB2 does not have this behavior. No support for preparing and executing multiple dynamic SQL statements in one go at all. You have to create and install a UDF or stored procedure instead.
This is a simple problem to fix. All the databases that support this by default should make it an option, and disable the option by default in the next major version of the database. It is not rocket science, and would add a valuable layer of defense to any number of database applications.
The MySQL client library is the interface that all (non-internal) SQL access to the MySQL server goes through. The defaults that it sets are the ones that will be picked up by all MySQL client applications by default. And the default is OFF. You can verify that by reading the documentation.
The MySQL client library is the only way for an external application to talk to the database. As a rule, it is the only way for most internal (MySQL developed) applications to talk to the database. Database wire protocols tend to be proprietary, database specific, and poorly documented. They are always changing as new features are added, because they must support every database specific feature. As a consequence the client libraries are almost invariably developed by the database server developers and maintainers. This is true of every proprietary database, and MySQL and PostgreSQL as well. It is not an accident that the documentation for these libraries is part of the database documentation on the primary website for each.
I don't write code, by the way, that is subject to SQL injection. But that doesn't mean I have time to review the coding practices of the developers of every application I install on systems I am responsible for. That is why every database should make this an option at best, and support block syntax so that application developers have no reason to turn it on.
Otherwise it is like saying, I don't need fire insurance, because I never start any fires.
Oracle has a similar vulnerability with poorly programmed PL/SQL calls to be sure. It is just that the preponderance of dynamic PL/SQL blocks to compared to ordinary Oracle SQL statements is minimal at best. There are very large Oracle applications that do not have any dynamic PL/SQL blocks - most Oracle applications use statically code PL/SQL exclusively - typically in triggers, database functions, and stored procedures.
I know that the MySQL interface does not have this option turned on by default. I am admittedly surprised to discover that PostgreSQL not only has it by default, but it cannot be disabled.
I am quite certain that DB2 does not have this problem. There is no indication in the documentation at any rate. So it would appear that the preponderance of the severe form of the problem (by default) is about 50/50:
MSSQL: yes
Sybase: yes
PostgreSQL: yes
MySQL: no (by default)
Oracle: no
DB2: no
Oracle is not trivially vulnerable to semicolon based statement injection. The reason is that it requires block syntax to execute multiple SQL statements in the same prepare / bind / execute sequence. So an attacker cannot convert a poorly programmed SELECT statement into something that does anything other than SELECT things (assuming the word "SELECT" is hard coded of course).
In common cases where the operation type and the table names are hard coded, predicate expansion attacks could lead to a carelessly programmed SQL statement selecting, updating, or deleting too many rows. Perhaps every row in the pertinent table. But at least the attacker cannot dump your entire schema and manipulate data in any table at will.
The fact that a command line interface executes multiple queries in series with nothing but semicolons is not evidence that the database executes the same syntax with one prepare / bind / execute sequence. Big difference.
I have nothing against MS SQL, I would like to see them (and the PostgreSQL people, and the Sybase people, and (partially) the MySQL people mitigate this problem. Due to the number of semi-competent developers out there, support for syntax like this at a low level is borderline unconscionable, especially because the fix is trivial. Just do what Oracle does - require block syntax to execute multiple statements.
Every database that supports stored procedures already supports some form of block syntax, perhaps the developers should consider requiring people to use it. It is not that hard. A few characters at the beginning, a few at the end. That is all there is to it. Vulnerability to complete SQL statement injection eliminated.