So... you're saying that Vista runs great if you throw top-of-the-line hardware at it? The OP may not be saying that, but I am. Thats how it works in the windows world historically. When new OS major versions come out, they only run well on high-end equipment. But by 2-3 years into the release, normal, affordable, mainstream equipment runs fine on it.
This should not come as a surprise, its how its worked in the MS world for 10 years.
Just because Vista is fast on new hardware does NOT mean that it's an efficiently designed OS. No one is talking about whether its an 'efficiently designed' OS. Thats not even in the conversation. The conversation is whether its a usable OS.
If the users built their own box, or installed Vista on a box not specifically checked for compatibility, then the user takes responsibility. It'd be nice if every POS consumer level device will have re-written drivers for Vista and Vista 64, but thats just not going to happen.
Most IHVs want you to buy the new versions of their products, with vista drivers of some level of quality.
Taking 5-10 seconds is not normal on any Vista box I've seen.
What I have seen is that the quality of the drivers has an incredibly massive impact on the stability and speed of the machine. All the stuff I've dealt with has been engineering-class laptops from HP and similar (compaq 8710w and similar).
Running Vista 64 business is like a breath of fresh air. It's blazingly fast, and rock-solid stable. I'm not sure how much of this is due to the 64-bit part, but I've been quite amazed.
There are a few quirks that Vista has that are irritating, but they fixed sooooooooo many irritations from XP and previous that I'll take the trade off.
There's also alot of special case problems with vista. For example, these network issues, or file copy issues or such that only affect a minority of users, but its a sizable minority. Supposedly, a bunch of these specific issues are due to be fixed in sp1.
Every Vista box I've seen from an OEM (mostly HP) gives you the option to install the 32-bit or 64-bit when you install from media.
I realize thats not the case for every setup, but its common where I live.
So just like Linux or any other system, you need to be careful to buy the correct hardware/system/software for your needs. If you need 64-bit, buy a machine that comes with 64-bit vista.
32-bit versions of windows (just like 32-bit versions of Linux) use PAE to allow individual processes use up to 16GB of memory each.
I've had 32-bit win2003 servers (in the past) with 12GB of memory, where MS SQL Server was using ~8GB of memory, with a whole bunch of large critical tables pinned into memory.
From the description you provide, it sounds like you have configuration problems with the servers, due to inexperienced/inadequate sa's. Just like how you wouldnt put me in charge of managing large Solaris installations (since I dont have any experience there), you've got to be careful who you have managing your mid or large windows installations.
No, indexing is what you're talking about. At most prefetch would cause some occasional bursts of drive activity that wouldnt last more than 30 seconds.
And even indexing becomes a non-issue once its caught up and indexed all of your drive. Then the only thing it indexes are changed files.
The big question is how are people feeling about having to upgrade their operating system every two years, their file server every two years, the work station licence every two years, exchange server every two years, their exchange client every two years and finally their three resource kits and manuals every two years. That is a pretty massive cost, including retraining, installation, updating, and lost productivity as a result of being, M$'s crash test, permanent beta release, dummy. I'm confused, where's the guy with the gun forcing anyone to do any of this?
It sure doesnt reflect the reality I see every day. Businesses tend to run servers on a 5 year lifespan, and desktops on a 3-4 year lifespan for typical users. Granted, your IT staff, or power users will often hold closer to the bleeding edge.
But the bulk of my customers have servers that are all older than 2 years old, and the bulk of their desktops havent changed in more than 2 years.
"Most of the utilities 'needlessly' use lower level drivers, and by them being re-written for user mode" If they can get the level of access that they need to in user-mode, then great:) It'd be good for them to do so. On a side note though... ntune... bleh. You should also consider encouraging such projects to just get a code signing cert as an alternative to re-writing the drivers (though re-writing them may be the better choice from a correctness perspective).
A code signing cert costs ~$200 per year from one of a number of vendors, and never requires you to talk to or be involved with Microsoft in any way. It's pretty trivial. When you consider that hosting costs for a year of hosting a project's website probably costs more than that.
Heck, make it an opportunity for some related vendor to pay for it, in exchange for a 'sponsored by' placement.
Signed drivers are only required for kernel level drivers. Most of the stuff you encounter is not a kernel mode driver, so this doesnt come up as an issue for the vast majority of people.
IMO The biggest challenge/danger regarding e-mailing when driving is limited visual capacity. Your macula (the part of the retina that does detailed vision) can only be pointed towards one place at once. As a result, when you are looking at your computer, you are not looking at the road. The other problem is that most of us either hunt and peck or type with two hands. If you type with two hands, you are going to need to look at the keyboard to type so you can keep the other hand on the road. If you hunt and peck, you still need to look to see what key you are about to hit. I see what you're getting at, but I would argue that its a bad example in this specific case.
Driving is one of those activitie where its very often useful and advantageous to NOT focus on any one thing in your vision. Often, like when entering a roundabout or a 4-way stop, I'll completely defocus my eyes. The end result is that I'm not focusing on anything, and dont see much in the way of detail (like street signs or license plates), but I have a very wide field of vision.
In other words, I can see both edges of the sides of the intersection without having to turn my head. I dont know why this works, but its almost like when I unfocus my eyesight becomes a computer screen that I can move my (mental, not physical) focus around on. It's not high detail, but is more than enough for routine driving.
For avoiding other cars, you really need almost no eyesight. You can do nearly all of it via symbolic wire frames or equivalent. You just need to know that there is or isnt a large car-blob moving at such and such trajectory. Details of the car dont matter, so you never really have to look at them.
Now I realize this only applies in familiar areas, or areas where you dont need to focus on details of the road, or signs, or landscape, but it comes in handy very often for me. On routine paths, I could go just about the whole drive and never visually focus on anything.
Holy freaking crap is that a case of the cure being worse than the disease.
The explicit reason and purpose for the existence of the 'Local Service' account to exist is to be used as a service account for local services that dont require network access or admin privileges.
In other words, its only purpose for existence is to NOT be a local admin.
Adding it to the local Admins group is just insane.
Basically you have a whole ton of software getting smart and moving over to use the 'Network Service' and 'Local Service' accounts, rather than SYSTEM, as a security precaution. That way, if the service/app gets pwned, the box isnt also owned.
That's just insane that the OSU IT folks would recommend that.
Mind you, I have a similar (though not exactly the same) problem, in that periodically my lan ethernet will just go into the 'Not Connected' state. This despite the fact that link lights are lit, and I can ping, use the web, use CIFS, RDP, etc. But VPNs wont start in this state. My solution is just to unplug the ethernet cable and re-plug it.
Very irritating, not sure if its a driver issue, or a vista issue.
Any application that won't run in a Firefox window is unneeded and merely distracts from the company's core mission. Not sure if you're serious or being sarcastic, but I'm assuming serious so...
Are you kidding me? What about little things like:
1. Financials/Accounting/Inventory/PoS 2. Email 3. Calendar 4. Software Development 5. Web Development 6. Graphics Creation & Manipulation 7. Line of Business Apps (Timberline, ADP, whatever) 8. Instant Messaging 9. Database Management 10. Systems Administration & Management Tools 11. CRM
Heck, even online office tools are only good for simple stuff when you've got an internet connection.
And yes, I know some of these have online versions, but they're all crap for most typical business use. Maybe for the 1 person home office, or certain kinds of shops that have very little administration to be done.
This kind of thinking drives me crazy. Very few shops can get away with little to no infrastructure like this.
Imagine a database with its main column being VARCHAR(255) and using about full length of it, then search using a lot of LIKE and AND, picking various short pieces out of that column, and the database being terabytes big. Try to invent a way to index it. Turn on full-text indexing?
This is also an old problem, with well understood solutions. Nearly all modern RDMS systems ship with a solution to this built in and well documented.
A giant step backward in the programming paradigm for large-scale data intensive applications they don't offer any proof, merely their view... Actually they do. Their proof is that this sort of approach was tried several decades ago, and has been found to be a fundamentally lacking approach for general purpose data processing. They provide several examples.
Not novel at all -- it represents a specific implementation of well known techniques developed nearly 25 years ago
Again, not sure why something "old" represents something "bad". The most reliable rockets for getting our space satellites into orbit are the oldest ones. It's not bad because its 'old'. It's bad because it was rejected by the community consensus a long time ago as a general purpose solution. Their argument isnt that bad = old. Their argument is that ignoring the lessons of the past is bad.
Missing most of the features that are routinely included in current DBMS
They're mistakenly assuming this is for database programming They never state that MapReduce is for database programming. They are evaluating it for applicability in 'large-scale data intensive applications', which is also what modern RDMS's are used for.
I think the valid criticism is that anyone is suggesting that MapReduce is a useful general purpose framework. It's clearly not. It's only useful in a highly specific (and fairly niche) set of situations. Further, it is really only successful now because of the specific economics around very large scale data processing. It, combined with Google's business model, allows them to have an economic advantage (above a certain scale size).
In other words, the excitement around Google's use of MapReduce is as much around their economic structuring of their business around some concepts as it is about the technology itself. MapReduce in and of itself isnt terribly novel and interesting. MapReduce as implemented and used by Google as a business is interesting.
The exploit goes after a feature that is only found in SQL Server. I would qualify that to say this:
The exploit is against sql injection at the app layer. Once the exploit has occurred and the app compromised, that script then uses features available in all modern databases (ANSI INFORMATION_SCHEMA views), but the syntax used in this specific implementation (sysobjects tables) will only work on MS SQL Server.
In other words, they could have written platform-neutral code for the db section, but they chose not to.
I hope I'm not starting to sound pedantic here. The misinformation I'm trying to correct (in general, not hugely specific to you) is that this whole thing was using any inherent weakness, or patched/unpatched hole in the ms stack targeted here. It does not.
In fact, its likely that this is just one component being tested of a larger, cross platform attack. The nature of this attack is such that it wouldnt be too much evolution to make this work across a large portion of webapps/db-server combinations out there. Just add a little platform detection and some dialect changes for the different platforms, and you're there.
Nearly every one of those links on the google search is to a known and published sql injection attack against phpbb. Thats pretty 'mass'. Try to administer a phpBB install of any popularity sometime, its a pretty miserable experience because of things like this.
If you mean a sql injection attack on the underlying technology (IIS, mssql, etc), then I think you're misunderstanding what a sql injection is.
It's not a problem with a technology, its a problem with applications, or implementations of technology to serve a purpose.
So the MS stack doesnt have a problem with sql injections, but a specific app built on that stack might. Same for PHP. PHP doesnt have sql injection problems (though it sure used to make it easy to do so, but its getting better a bit), but many, many, many apps built on PHP do have sql injection problems.
So yes, for real world mass sql injection attacks, just look at any number of popular php apps. They're pretty much the king for these at the moment. phpBB, Drupal, etc etc.
And again, focusing back on the original article and topic: this attack has nothing to do with ms sql server, or any perceived weaknesses in sql server. The developers of the attack script just happened to write non portable code for that stage of the attack, if they would have used ansi standard info schema views rather than ms-specific sysobjects tables, it would have worked on most any database.
So to recap, this whole thing is NOT a database attack vector, in any way. It is a SQL Injection attack vector (which is an app level problem), which just happens to use ms sql server in this incarnation.
I think when you're talking about 'mass sql exploit' you're thinking this is an exploitable vulnerability in the database server used. That would be incorrect. The db portion of this attack is entirely incidental.
Well, the db part of the attack script is written such that it only works on sql server. This is because they send queries to sysobjects to find tables that have clob/text columns.
If they would have written more platform-neutral code (used INFORMATION_SCHEMA views rather than sysobjects), then there's no reason this wouldnt have worked on just about any platform that had available sql injection exposures.
My take on it is that they just wrote the attack script for a single targeted platform. It's probably just a prototype of the attack script (testing one platform), or just some lame skiddy who did minimal work to repackage an existing script available online.
Another option... which many folks here would see as a faustian bargain... would be to become an MS certified partner.
Costs nothing except about 30 minutes answering questions.
Then you can buy the Power Pack (or ISV Empower if you're an ISV type partner), for $400.
This gives you all of the MS server products with 10 cals, plus 10 desktop OSs, 10 copies of the top version of office 2007, sharepoint, sql server, etc etc etc.
All game for internal use, but not licensed for external. Not for a publicly available sharepoint, for example.
Anyway, just wanted to toss it out.... most folks on slashdot would not go for it, but it is a relatively low cost option with few obligations, and some nice bennies. Especially if you make products for the MS platform, or service that platform for clients.
Fair enough, there still may be some sql 2000 servers out there, but there shouldnt be many left. SQL 2000 goes out of mainstream support from MS in 3 months.
In addition, many of the defaults and published guidelines on this stuff changed after slammer went around, in 2003. So thats been 5 years people have had to clean up their messes and adopt best practices.
In my world, we moved over to a 'best-practices' installations of IIS and SQL Server when we migrated to sql server 2000, which was the best part of 7 years ago.
Yea, you can probably set enough permissions to not require local admin rights, but seriously, the places we're talking about already are too lazy to sanitize database inputs, do you really thing all of their practices are top-notch security wise? You dont have to do any work for this. Just tell the installer what service account you're using, and it grants all the privs and ntfs/registry acls you need.
Years before, with SQL 2000 (And pretty much every bit of what I said applied to SQL 2000), Microsoft said you had to have setup the SQL service account as a local administrator on the machine. There are still some remnants of this policy: http://support.microsoft.com/kb/239885 Where it's explicitly said to make sure the user is a local administrator (NT4, SQL 2000 and SQL 7). Note that in that link, it says that the ms sql 2000 service account has to be a local admin ONLY on NT4.
Considering how long its been (years) since the current version of sql server released, and considering how much longer (even more years) the best practices were published for the previous version, I think its reasonable to focus on the current version.
If you look at 5 years old versions of products in any space right now, the products look alot crappier. Especially in the MS world, everything has changed since then.
It's funny because of your statement that your database is the only one that supports parameterized queries.
Every db on the planet supports parameterized queries, I cant think of one that doesnt.
To be more specific, nearly every db access technology (ado, jdo, jdbc, pdo, etc) supports such things.
If you've got a good product, there's nothing wrong with advertising it, but to make such obviously false statements as that its the only one that supports parameterized queries is a bit silly.
This requires absolutely no vulnerability or exploit in IIS, MSSQL, or Windows Server.
It just requires the app to allow sql injection. Everything past there is plain vanilla, no special perms needed.
As I posted to someone else, this works even if the webserver, sqlserver, and windows server are all fully patched, and everything is put together in best-practices scenario. Even if IIS and MSSQL are running with service accounts that are non-admin, with maximally locked down configurations.
This would have worked on ANY database if they would have chosen to write code using ANSI standard INFORMATION_SCHEMA rather than sysobjects to reflect on the db tables.
Once the SQL Injection through, about the only thing that would have stopped this is:
1. Restricting all data-writes to the db tables to stored procedures.
2. XSS and script filtering on the web app writing the corrupted CLOB to a webpage.
And on the SQL Injection side, there doesnt need to be any common framework. they could just be scanning for injectable forms. It's not hard to write a script that will look for those in the general case.
there was no unpatched vulnerability used to own the webserver.
Standard plain-vanilla, no-unpatched-vuln-needed was used to run commands on the db, which was used to inject script to CLOB fields that were output to dynamic web pages.
IE browsers that then browsed those websites hit that script, which exploited the MDAC vuln on desktop machines, to steal stuff on desktops.
This entire attack works unchanged if the sqlserver and iis are running (as is the standard nowadays) as non-admin. It even works if the db account the webserver uses isnt sa on the sql server.
In short, this is a very creative attack. Stopping the sql injection would eliminate it. Without that, you're limited to doing everyting in sprocs and using heavy xss protection on db writing of content to the webpages.
This entire attack, from beginning to end, at no point requires privileged access to anything.
So far only one database supports this feature: the H2 Database Engine. ROFL
I think what you mean to say is that there may still nowadays be one database server out there that does NOT support this feature. I cant think of it though.
Nearly every item in your post is wrong.
Amusingly, with the set of services used in this exploit, it's possible to gain "root" access if the user the webapp is connecting to the database with has the SA role on the SQL server. At most, this would give you sa on the db server, which is not the same thing as root on the OS.
On a Microsoft SQL server, there's a system stored procedure called xp_cmdshell, this allows you to run arbitrary commands under the permissions of the account the database is running under. xp_cmdshell is disabled by default.
And because Microsoft requires the user running SQL server to be a local administrator for the service to start, you have gained "root" access. I have no idea where you get this from. There has never been a version of SQL Server that requires the db service account to be a local admin for the db server to run.
The account that SQL Server runs as defaults to 'Local Service' nowadays. And the only special priv it needs is the privilege of 'start as service'.
In fact, its common practice to have your mssql server run as a local (non-domain) account, that has no privs, and is named 'SQLServer'.
In addition, MS SQL server by default doesnt even have an SA account, it runs in windows security mode, rather than mixed mode. And standard practice is to use a non-priv'd account for the webapp that only has data-read and data-write rights to one db for the webapp.
Slashdot Mirror
This should not come as a surprise, its how its worked in the MS world for 10 years. Just because Vista is fast on new hardware does NOT mean that it's an efficiently designed OS. No one is talking about whether its an 'efficiently designed' OS. Thats not even in the conversation. The conversation is whether its a usable OS.
It's the OEM's fault.
If the users built their own box, or installed Vista on a box not specifically checked for compatibility, then the user takes responsibility. It'd be nice if every POS consumer level device will have re-written drivers for Vista and Vista 64, but thats just not going to happen.
Most IHVs want you to buy the new versions of their products, with vista drivers of some level of quality.
Taking 5-10 seconds is not normal on any Vista box I've seen.
What I have seen is that the quality of the drivers has an incredibly massive impact on the stability and speed of the machine. All the stuff I've dealt with has been engineering-class laptops from HP and similar (compaq 8710w and similar).
Running Vista 64 business is like a breath of fresh air. It's blazingly fast, and rock-solid stable. I'm not sure how much of this is due to the 64-bit part, but I've been quite amazed.
There are a few quirks that Vista has that are irritating, but they fixed sooooooooo many irritations from XP and previous that I'll take the trade off.
There's also alot of special case problems with vista. For example, these network issues, or file copy issues or such that only affect a minority of users, but its a sizable minority. Supposedly, a bunch of these specific issues are due to be fixed in sp1.
Every Vista box I've seen from an OEM (mostly HP) gives you the option to install the 32-bit or 64-bit when you install from media.
I realize thats not the case for every setup, but its common where I live.
So just like Linux or any other system, you need to be careful to buy the correct hardware/system/software for your needs. If you need 64-bit, buy a machine that comes with 64-bit vista.
This is patently, grossly incorrect information.
32-bit versions of windows (just like 32-bit versions of Linux) use PAE to allow individual processes use up to 16GB of memory each.
I've had 32-bit win2003 servers (in the past) with 12GB of memory, where MS SQL Server was using ~8GB of memory, with a whole bunch of large critical tables pinned into memory.
From the description you provide, it sounds like you have configuration problems with the servers, due to inexperienced/inadequate sa's. Just like how you wouldnt put me in charge of managing large Solaris installations (since I dont have any experience there), you've got to be careful who you have managing your mid or large windows installations.
No, indexing is what you're talking about. At most prefetch would cause some occasional bursts of drive activity that wouldnt last more than 30 seconds.
And even indexing becomes a non-issue once its caught up and indexed all of your drive. Then the only thing it indexes are changed files.
It sure doesnt reflect the reality I see every day. Businesses tend to run servers on a 5 year lifespan, and desktops on a 3-4 year lifespan for typical users. Granted, your IT staff, or power users will often hold closer to the bleeding edge.
But the bulk of my customers have servers that are all older than 2 years old, and the bulk of their desktops havent changed in more than 2 years.
If they can get the level of access that they need to in user-mode, then great
A code signing cert costs ~$200 per year from one of a number of vendors, and never requires you to talk to or be involved with Microsoft in any way. It's pretty trivial. When you consider that hosting costs for a year of hosting a project's website probably costs more than that.
Heck, make it an opportunity for some related vendor to pay for it, in exchange for a 'sponsored by' placement.
Signed drivers are only required for kernel level drivers. Most of the stuff you encounter is not a kernel mode driver, so this doesnt come up as an issue for the vast majority of people.
Driving is one of those activitie where its very often useful and advantageous to NOT focus on any one thing in your vision. Often, like when entering a roundabout or a 4-way stop, I'll completely defocus my eyes. The end result is that I'm not focusing on anything, and dont see much in the way of detail (like street signs or license plates), but I have a very wide field of vision.
In other words, I can see both edges of the sides of the intersection without having to turn my head. I dont know why this works, but its almost like when I unfocus my eyesight becomes a computer screen that I can move my (mental, not physical) focus around on. It's not high detail, but is more than enough for routine driving.
For avoiding other cars, you really need almost no eyesight. You can do nearly all of it via symbolic wire frames or equivalent. You just need to know that there is or isnt a large car-blob moving at such and such trajectory. Details of the car dont matter, so you never really have to look at them.
Now I realize this only applies in familiar areas, or areas where you dont need to focus on details of the road, or signs, or landscape, but it comes in handy very often for me. On routine paths, I could go just about the whole drive and never visually focus on anything.
Holy freaking crap is that a case of the cure being worse than the disease.
The explicit reason and purpose for the existence of the 'Local Service' account to exist is to be used as a service account for local services that dont require network access or admin privileges.
In other words, its only purpose for existence is to NOT be a local admin.
Adding it to the local Admins group is just insane.
Basically you have a whole ton of software getting smart and moving over to use the 'Network Service' and 'Local Service' accounts, rather than SYSTEM, as a security precaution. That way, if the service/app gets pwned, the box isnt also owned.
That's just insane that the OSU IT folks would recommend that.
Mind you, I have a similar (though not exactly the same) problem, in that periodically my lan ethernet will just go into the 'Not Connected' state. This despite the fact that link lights are lit, and I can ping, use the web, use CIFS, RDP, etc. But VPNs wont start in this state. My solution is just to unplug the ethernet cable and re-plug it.
Very irritating, not sure if its a driver issue, or a vista issue.
Are you kidding me? What about little things like:
1. Financials/Accounting/Inventory/PoS
2. Email
3. Calendar
4. Software Development
5. Web Development
6. Graphics Creation & Manipulation
7. Line of Business Apps (Timberline, ADP, whatever)
8. Instant Messaging
9. Database Management
10. Systems Administration & Management Tools
11. CRM
Heck, even online office tools are only good for simple stuff when you've got an internet connection.
And yes, I know some of these have online versions, but they're all crap for most typical business use. Maybe for the 1 person home office, or certain kinds of shops that have very little administration to be done.
This kind of thinking drives me crazy. Very few shops can get away with little to no infrastructure like this.
This is also an old problem, with well understood solutions. Nearly all modern RDMS systems ship with a solution to this built in and well documented.
they don't offer any proof, merely their view... Actually they do. Their proof is that this sort of approach was tried several decades ago, and has been found to be a fundamentally lacking approach for general purpose data processing. They provide several examples. Not novel at all -- it represents a specific implementation of well known techniques developed nearly 25 years ago
Again, not sure why something "old" represents something "bad". The most reliable rockets for getting our space satellites into orbit are the oldest ones. It's not bad because its 'old'. It's bad because it was rejected by the community consensus a long time ago as a general purpose solution. Their argument isnt that bad = old. Their argument is that ignoring the lessons of the past is bad. Missing most of the features that are routinely included in current DBMS
They're mistakenly assuming this is for database programming They never state that MapReduce is for database programming. They are evaluating it for applicability in 'large-scale data intensive applications', which is also what modern RDMS's are used for.
I think the valid criticism is that anyone is suggesting that MapReduce is a useful general purpose framework. It's clearly not. It's only useful in a highly specific (and fairly niche) set of situations. Further, it is really only successful now because of the specific economics around very large scale data processing. It, combined with Google's business model, allows them to have an economic advantage (above a certain scale size).
In other words, the excitement around Google's use of MapReduce is as much around their economic structuring of their business around some concepts as it is about the technology itself. MapReduce in and of itself isnt terribly novel and interesting. MapReduce as implemented and used by Google as a business is interesting.
The exploit is against sql injection at the app layer. Once the exploit has occurred and the app compromised, that script then uses features available in all modern databases (ANSI INFORMATION_SCHEMA views), but the syntax used in this specific implementation (sysobjects tables) will only work on MS SQL Server.
In other words, they could have written platform-neutral code for the db section, but they chose not to.
I hope I'm not starting to sound pedantic here. The misinformation I'm trying to correct (in general, not hugely specific to you) is that this whole thing was using any inherent weakness, or patched/unpatched hole in the ms stack targeted here. It does not.
In fact, its likely that this is just one component being tested of a larger, cross platform attack. The nature of this attack is such that it wouldnt be too much evolution to make this work across a large portion of webapps/db-server combinations out there. Just add a little platform detection and some dialect changes for the different platforms, and you're there.
Nearly every one of those links on the google search is to a known and published sql injection attack against phpbb. Thats pretty 'mass'. Try to administer a phpBB install of any popularity sometime, its a pretty miserable experience because of things like this.
If you mean a sql injection attack on the underlying technology (IIS, mssql, etc), then I think you're misunderstanding what a sql injection is.
It's not a problem with a technology, its a problem with applications, or implementations of technology to serve a purpose.
So the MS stack doesnt have a problem with sql injections, but a specific app built on that stack might. Same for PHP. PHP doesnt have sql injection problems (though it sure used to make it easy to do so, but its getting better a bit), but many, many, many apps built on PHP do have sql injection problems.
So yes, for real world mass sql injection attacks, just look at any number of popular php apps. They're pretty much the king for these at the moment. phpBB, Drupal, etc etc.
And again, focusing back on the original article and topic: this attack has nothing to do with ms sql server, or any perceived weaknesses in sql server. The developers of the attack script just happened to write non portable code for that stage of the attack, if they would have used ansi standard info schema views rather than ms-specific sysobjects tables, it would have worked on most any database.
So to recap, this whole thing is NOT a database attack vector, in any way. It is a SQL Injection attack vector (which is an app level problem), which just happens to use ms sql server in this incarnation.
I think when you're talking about 'mass sql exploit' you're thinking this is an exploitable vulnerability in the database server used. That would be incorrect. The db portion of this attack is entirely incidental.
Well, the db part of the attack script is written such that it only works on sql server. This is because they send queries to sysobjects to find tables that have clob/text columns.
If they would have written more platform-neutral code (used INFORMATION_SCHEMA views rather than sysobjects), then there's no reason this wouldnt have worked on just about any platform that had available sql injection exposures.
My take on it is that they just wrote the attack script for a single targeted platform. It's probably just a prototype of the attack script (testing one platform), or just some lame skiddy who did minimal work to repackage an existing script available online.
Makes sense.
... which many folks here would see as a faustian bargain ... would be to become an MS certified partner.
.... most folks on slashdot would not go for it, but it is a relatively low cost option with few obligations, and some nice bennies. Especially if you make products for the MS platform, or service that platform for clients.
Another option
Costs nothing except about 30 minutes answering questions.
Then you can buy the Power Pack (or ISV Empower if you're an ISV type partner), for $400.
This gives you all of the MS server products with 10 cals, plus 10 desktop OSs, 10 copies of the top version of office 2007, sharepoint, sql server, etc etc etc.
All game for internal use, but not licensed for external. Not for a publicly available sharepoint, for example.
Anyway, just wanted to toss it out
In addition, many of the defaults and published guidelines on this stuff changed after slammer went around, in 2003. So thats been 5 years people have had to clean up their messes and adopt best practices.
In my world, we moved over to a 'best-practices' installations of IIS and SQL Server when we migrated to sql server 2000, which was the best part of 7 years ago. Yea, you can probably set enough permissions to not require local admin rights, but seriously, the places we're talking about already are too lazy to sanitize database inputs, do you really thing all of their practices are top-notch security wise? You dont have to do any work for this. Just tell the installer what service account you're using, and it grants all the privs and ntfs/registry acls you need. Years before, with SQL 2000 (And pretty much every bit of what I said applied to SQL 2000), Microsoft said you had to have setup the SQL service account as a local administrator on the machine. There are still some remnants of this policy: http://support.microsoft.com/kb/239885 Where it's explicitly said to make sure the user is a local administrator (NT4, SQL 2000 and SQL 7). Note that in that link, it says that the ms sql 2000 service account has to be a local admin ONLY on NT4.
Considering how long its been (years) since the current version of sql server released, and considering how much longer (even more years) the best practices were published for the previous version, I think its reasonable to focus on the current version.
If you look at 5 years old versions of products in any space right now, the products look alot crappier. Especially in the MS world, everything has changed since then.
It's funny because of your statement that your database is the only one that supports parameterized queries.
Every db on the planet supports parameterized queries, I cant think of one that doesnt.
To be more specific, nearly every db access technology (ado, jdo, jdbc, pdo, etc) supports such things.
If you've got a good product, there's nothing wrong with advertising it, but to make such obviously false statements as that its the only one that supports parameterized queries is a bit silly.
This has been covered.
This requires absolutely no vulnerability or exploit in IIS, MSSQL, or Windows Server.
It just requires the app to allow sql injection. Everything past there is plain vanilla, no special perms needed.
As I posted to someone else, this works even if the webserver, sqlserver, and windows server are all fully patched, and everything is put together in best-practices scenario. Even if IIS and MSSQL are running with service accounts that are non-admin, with maximally locked down configurations.
This would have worked on ANY database if they would have chosen to write code using ANSI standard INFORMATION_SCHEMA rather than sysobjects to reflect on the db tables.
Once the SQL Injection through, about the only thing that would have stopped this is:
1. Restricting all data-writes to the db tables to stored procedures.
2. XSS and script filtering on the web app writing the corrupted CLOB to a webpage.
And on the SQL Injection side, there doesnt need to be any common framework. they could just be scanning for injectable forms. It's not hard to write a script that will look for those in the general case.
there was no unpatched vulnerability used to own the webserver.
Standard plain-vanilla, no-unpatched-vuln-needed was used to run commands on the db, which was used to inject script to CLOB fields that were output to dynamic web pages.
IE browsers that then browsed those websites hit that script, which exploited the MDAC vuln on desktop machines, to steal stuff on desktops.
This entire attack works unchanged if the sqlserver and iis are running (as is the standard nowadays) as non-admin. It even works if the db account the webserver uses isnt sa on the sql server.
In short, this is a very creative attack. Stopping the sql injection would eliminate it. Without that, you're limited to doing everyting in sprocs and using heavy xss protection on db writing of content to the webpages.
This entire attack, from beginning to end, at no point requires privileged access to anything.
I think what you mean to say is that there may still nowadays be one database server out there that does NOT support this feature. I cant think of it though.
The account that SQL Server runs as defaults to 'Local Service' nowadays. And the only special priv it needs is the privilege of 'start as service'.
In fact, its common practice to have your mssql server run as a local (non-domain) account, that has no privs, and is named 'SQLServer'.
In addition, MS SQL server by default doesnt even have an SA account, it runs in windows security mode, rather than mixed mode. And standard practice is to use a non-priv'd account for the webapp that only has data-read and data-write rights to one db for the webapp.