SQL stands for "Structured Query Language", not "Standard Query Language".

[Actually, it stands for both. I have a little purple and blue book on my bookshelf which reads "SQL - Standard Query Language," admittedly written in the early 1990s. Still... -Rick]

have you ever work in software support before?
you have to be able to reproduce it and test it out and find out what else could be broke before you can acknowledge it's a bug.
it's not a 10 sec thing.
This thing was just reported in dec 4 and it had to go thorugh the channels to the right person and then prioritised and then act on it.....
it's not the only bug out there you know that need to be fixed...
plus it's holiday season...people are off on vaccations..
it's not like this is one year ago...
it's just 18 days ago.

[SEC Consulting worked with Microsoft for months pointing out the flaw and how to reproduce it. Microsoft would not acknowledge it. SEC was forced to publish their findings to the public, and now Microsoft has taken noticed. -Rick]

SQL -> Structured Query Language

Also that last line of your query doesn't look very T-SQL like.

John B. (SQL Server DBA since v. 6.0)

If I write poor code that allows "SQL injection"... wouldn't it *ALWAYS* allow it?

If I write code that is TOTALLY blocking all "SQL injection"... will this still be a problem? How?

[I have not seen details of the exploit, though typically injection attacks involve code with extra characters at the end. Above the "INTO CURSOR ActiveList" code above there might be another command or additional bytes which, due to the known flaw in SQL Server, are parsed in some way which allows injected data to pass into the system. -Rick]

Seriously, SQL injection has been a threat for longer then the past year, but it relies more on a poorly developed interface then the database server itself. And I agree with John B- I don't think that query would parse.

Server: Msg 156, Level 15, State 1, Line 4
Incorrect syntax near the keyword 'INTO'.

[It wasn't designed to be a T-SQL command, only to represent a type of SQL expression for our readers. I've updated it for all the stricters. -Rick]

It looks like SQL injection isn't the main issue being addressed. The issue is an exploitation of sp_replwritetovarbin, sometimes using SQL injection to fake authentication.

The example scripts is here, and it just killed one of my test servers :)

http://www.sec-consult.com/files/20081209_mssql-2000-sp_replwritetovarbin_memwrite.txt

@ yo:

You must be the pissed off guy at Microsoft who got the job to fix it and didn't know how to do it for months.
Hehe!

Open Source would have acknowledged AND fixed the bug in the matter of a day.

Microsoft gives Hackers way too much time to exploit the vulnerabilities of its software even after they are known to everybody.

Yes, SQL Server is vulnerable to SQL Injection attacks. Every DBMS is vulnerable to SQL Injection attacks. By the very definition of a SQL Injection attack, there is nothing the DBMS can due to prevent this. SQL Injection means that a hacker is running valid SQL on the database that the application developer did not want them to run. It is the applications that must fix the bugs, not the DBMS.
A bug was recently reported by Microsoft that is a critical vulnerability; but it is not "SQL Injection". Microsoft confirmed a bug, but not that their software is vulnerable to SQL Injection because all DBMS products have always been, and will always be, vulnerable to SQL Injection.

"Open Source would have acknowledged AND fixed the bug in the matter of a day. "

Sounds like really crappy change control. That's the problem with open source - the change control sucks. Not to mention everybody is working for free so that means nobody has resposiblity.

18 days to get it documented and it was already fixed in later patches so I doubt it's really an issue.

"SEC Consulting reports having seen instances of this bug in the wild."

Sounds like some bad network topologies. If you have to expose your SQL instance for your application - you're doing it wrong. The server serving the application should be exposed to the 'wild'(which i'm guessing means the internet).

Rick - Do some research before drawing conclusions that SEC has been working with Microsoft for months. Did you ask Microsoft for comment? Who from SEC did you get this information from? What was SEC's comment? This story has more holes than a prairie dog hill.

how about writing some drivers before talking about fixing bugs. open source supports about 3 devices and does a bad job at those.

Why do the IT posters here seem so snotty? Good find Rick. I personally found the information interesting. The business I work for runs Microsoft SQL server on pretty much every system we use.

This article did a shoddy job of reporting the issue, due mainly to the author's obvious ignorance of the topic combined with what might be seen as a certain amount of bias and arrogance.

First and foremost, ALL relational database systems BY ALL VENDORS are vulnerable to SQL injection attack. There are NO DBMS inately immune to it. Not from Microsoft, Oracle, IBM, MySQL, or anyone else. The reason for this is that vulnerabilities to SQL injection exploits are created by the architects and developers of code running on these systems, not by the DBMS per se. In fact, to completely harden a given DB engine against SQL injection would basically render the engine useless as all kinds of SQL functionality that database administrators and developers rely on everyday (correlated sub-queries for instance) would simply no longer be possible.

The author's interaction with "Debby" was illustrative of his ignorance:

"Debby: If I write poor code that allows "SQL injection"... wouldn't it *ALWAYS* allow it? If I write code that is TOTALLY blocking all "SQL injection"... will this still be a problem? How?

The Author: [I have not seen details of the exploit, though typically injection attacks involve code with extra characters at the end... ...there might be another command or additional bytes which, due to the known flaw in SQL Server, are parsed in some way which allows injected data to pass into the system]..."

In other words, the author doesn't know what he's really reporting about, doesn't know the difference between a SQL statement and a line of C# code, and does not understand that SQL injection is first and foremost a means of manipulating a system with the goal of gaining direct access to it, not merely "passing data" in. Yet he seems quite sure its Microsoft's inherent incompetence is causing the problem.

To set things straight, while it is possible to write a "bad" or poorly constructed SELECT statment, for example, the badness or goodness of a given statement is not relevent to the matter. SQL injection is an exploit created by *poor architecture* in that the SQL statements issued to the DBMS are available for manipulation by a would-be attacker - say via a text box on a web page. In fact it would be far more accurate to say the vulnerability is caused by a known flaw in the SQL language itself.

The author should have come to at least a passing understanding of the basics of the topic before attempting hang someone (Microsoft in this case) out to dry. Furthermore, when an issue is "discovered" by some no name consulting outfit deep inside an enterprise class database system that millions of people rely upon to house exabytes of mission-critical information the last thing I want to see a vendor do is start doing that Open-Source Dance and start issuing patches and service packs helter-skelter that wind up breaking perfectly functioning systems all over the world.

Thank God someone here knows what they are talking about.
The whole issue really stems from the fact that you are, for all intents and purposes, allowing end users to pass source code directly to your application.
One good way to help avoid this is to filter out all special characters ("*" for instance) from the input before running the query.

I was first introduced to SQL injectors back in 2004(2005?) When breaking into a GM account for Rose Online... and they are just now admitting to it being a threat?