New Attack Exploits "Safe" Oracle Inputs

Trailrunner7 writes "Database security super-genius David Litchfield has found a way to manipulate common Oracle data types, which were not thought to be exploitable, and inject arbitrary SQL commands. The new method shows that you can no longer assume any data types are safe from attacker input, regardless of their location or function. 'In conclusion, even those functions and procedures that don't take user input can be exploited if SYSDATE is used. The lesson here is always, always validate and prevent this type of vulnerability getting into your code. The second lesson is that no longer should DATE or NUMBER data types be considered as safe and not useful as injection vectors: as this paper (PDF) has proved, they are,' Litchfield writes."

heh

[stoolpigeon (454276)]

It's an interesting piece but when he points out that there really is little chance of it being used in the real world, that is an understatement. Using this method in the real world wouldn't even make sense.
 
In order to pull this off you need to have alter session priveleges. And you need to already have injected sql into the database- which means there is absolutely no point to taking the extra steps to modify some other data type to allow you to do what you have already done.
 
It's an interesting mental exercise but I don't think it really has an practical ramifications. If you've already handed out alter session to anyone using a form you've hosed yourself so many times over, playing with sysdate or number is the least of your worries.
 
Anything that reminds people to be careful about how they handle input is good, but I think a lot of people are going to think this is a bigger deal than it is.

Re:heh

[arth1 (260657)]

Lack of input validation is usually a bigger problem than what you think it is -- the context might make the instance safe, but code tends to be re-used, coding practices repeated, and projects getting additions that might introduce a vector that weren't there before.

The only time when lack of validation is good practice is at extreme low level where you control the input. Otherwise, it usually signifies a coder that lacks the ability to think outside his own procedures.

Regards,
--
*Art

Re:

[stoolpigeon (454276)]

I'm not arguing that. All I'm saying is that this depends upon a chain of failures prior to becoming possible and those failures are even greater than the exploit itself.
 
I don't know enough about sysadmin to make a good comparison, but my dba brain thinks this is like, saying 'hey you might think ls is pretty safe- but not if you give people root privileges before they use it.' But that might be a bad example.

Re:

[arth1 (260657)]

Not really a bad example, no. However, good sysadmins will try to do their best to limit the damage even if the unthinkable (like privilege escalation) should occur.
SELinux is a good example of this -- unless something is explicitly permitted and happens in a permissible context, it's forbidden. Even for root.
The downside is that the more draconian the measures, the more likely it is that laziness or lack of understanding will win. Instead of taking five steps to securely opening a window slot, someone w

Re:

[ShieldW0lf (601553)]

My DBA brain thought "What kind of idiot assembles SQL as a string and runs it inside a stored procedure like that?"

Re:

[morgan_greywolf (835522)]

Agreed. Handing out ALTER SESSION privs to anyone using a form is just plain dumb, dumb, dumb. You may as well put PLEASE HACK ME in flashing red letters at the top of the form.

Re:

[alan_dershowitz (586542)]

That's exactly what I was thinking, what retard grants the application's database user ALTER privileges on database objects?

Re:

[Shados (741919)]

I guess a web based database development tool... But then, when you can execute ANYTHING and have admin priviledge on the database, you don't really need exploits :)

Re:

[alan_dershowitz (586542)]

I know, but altering the session isn't the only part of the exploit. You also have to be able to create or modify PL/SQL in the database. Still not strictly ALTER, but the point is, application user should only be able to read and maybe write to tables. If I can help it, I don't even use PL/SQL. The database is the worst place to put application logic anyway. I use PL/SQL for ad-hoc stuff.

Re:

[1001011010110101 (305349)]

Correct me if I'm wrong, but even if someone has Alter session privileges, in order to execute "alter session", someone must be able to execute arbitrary stuff. In that case, trying to inject makes no sense, just plain insert/delete/whatever without using those date/number fields would do.

Re:

[DazzaL (1029774)]

It is not true to say that you need ALTER SESSION privilege granted to actually issue ALTER SESSION commands. Yes, that sounds counter-intuitive but it is true that you can issue SOME alter session commands if you can connect to a database regardless of what privs you have.

In this case setting NLS_DATE_FORMAT can be done by ANYONE regardless of whether they have ALTER SESSION granted.

some observations:

1. in most web apps you wont have access to the database, just the webserver...the database should be

Thats what they said about cross site scripting.

[by Anonymous Coward]

Your comment "he points out that there really is little chance of it being used in the real world, that is an understatement" is reminiscent of those who proclaimed no one would need more than one 360k floppy.

It best concluding non vulnerability without time and personal investment is naive and at best considering the large volume new security measurements in evidence prove that statements like these are foolish usually false and cause much more damage by breeding a false sense of security and complacency

Re:Thats what they said about cross site scripting

[stoolpigeon (454276)]

I don't think so. This is dependent upon circumstances where the horse is already out of the barn so to speak.

Re:heh

[Joe U (443617)]

Too many poor developers just make the web app run as dbo. They also tend to use 'select * from' all too often.

Drives me nuts, because I'm the exact opposite, you don't get any (yes including read) access except a few stored procedures you need to read/write data.

Re:

[martinmarv (920771)]

In the environments I've worked in (enterprise applications and large CMS-based websites), using stored procedures for everything can be a pain. For me, the best approach is a happy medium:-

• Don't restrict yourself to stored procedures, but do use them for updates, or database-side processing
• Do use a dedicated account for database access and make sure only appropriate permissions are granted
• Use parameterised queries (seems like most common frameworks support this)

Also

• Always validate user input
• Alway

Re:

[Kozz (7764)]

Reminds me of a webapp I worked on once. The programmer, in his infinite wisdom, would "SELECT * FROM TABLENAME", then stuff all 2500 records into a PHP array. Then he would promptly iterate over this array, selecting only two columns (of about thirty) he wanted from the desired rows matching his criteria.

I held my gag reflex long enough to perform only the requested change and make it functional. Then I declined all work after that.

Re:heh

[moderatorrater (1095745)]

he points out that there really is little chance of it being used in the real world, that is an understatement

I believe it was George Guninski who saw the possible exploit in buffer overflows several decades ago and said something along the lines of "this is possible, but the difficulty in crafting the message makes this seems unlikely". If there's the possibility of an attack vector, then someone will use it. Computers are fast enough to try hundreds of attacks per second; "unlikely" often means "only works 1/1000 times, therefore used every day".

Re:

[glwtta (532858)]

Computers are fast enough to try hundreds of attacks per second; "unlikely" often means "only works 1/1000 times, therefore used every day".

What does that have to do with anything? It's unlikely to be used not because it's unlikely to succeed, but because it's just a neat trick you can do with an already compromised system.

There's a big difference between "difficult to pull off" and "not worth bothering".

Re:

[Hoi Polloi (522990)]

Plus, anyone using this method of injection would probably cause widespread failures across the board in any app that depends on db procedures. The app would probably crash immediately. This isn't a very subtle way of hacking a db.

Re:

[blirp (147278)]

In order to pull this off you need to have alter session priveleges.

No, you don't. What you need is to somehow be able to modify NLS_NUMERIC_CHARACTERS or NLS_DATE_FORMAT. This is easily demonstrated with ALTER SESSION. But there might be a bug/exploit somewhere down the road that allows this in some other manner. Each of the two exploits are unusable, but combined ...

M.

Itsatrap!

[esocid (946821)]

Come on, do I have to tag this myself?

Use ORMs

[chrysalis (50680)]

Interesting flaw.

However, don't ORMs (and database-independant abstraction layers like AdoDB) protect against this?

Re:Use ORMs

[Shados (741919)]

Yup. Basically, the only real way this could be exploited would be something like a stored procedure which takes one of the "vulnerable" types as parameters, exposed directly to the clients, and concatenate the types with little to no casting.

Something like (pseudocode, the following wouldn't even pass syntax check, obviously, but its stupid hard to find a working case)

DECLARE @blah SOMEVULNERABLETYPE

Exec "select * from stuff where stuff.Blah =" + @blah;

If @blah was a string, everyone would realise its vulnerable...but in this case, numbers, dates, etc, would be assumed safe (how do you put code in a number??), when it supposingly was discovered its not safe.

However, if you went through a database driver (not even an ORM!), and made a prepared statement, passed a Java (for example) variable as parameter to a query, well, no invalid input will be able to get through. If you add an ORM layer on top of that which does extra validation, then even if all of the types (both java and database) were vulnerable, it wouldn't go through either...

This is really more of a theoritical vulnerabilty than a real one... it can't realistically be exploited in the wild, and its hard to even -imagine- a scenario in a well coded app.

Re:

[Shados (741919)]

In this case, it doesn't even affect poorly written code: it affects some theoritical near-impossible scenario. I only skimmned the description, but as far as I can understand, you almost need a researcher to be able to write code that can be exploited... a normal (or bad) dev wouldn't be able to pull it off (neither would I, as far as I can tell!).

I agree with the rest of your point, however.

nTier validation

[Joe U (443617)]

The 3 minimum levels of validation:

Validate at the client tier. (To save a return trip)
Validate at the application server tier. (to save a database trip)
Validate at the data tier. (to save your data)

Why is this so hard for developers to understand?

Re:

[EricWright (16803)]

Because too many database developers are restricted to working on one tier. They rely on the (incorrect) assumption that the guy working on the next lower tier has done their job properly.

Re:

[Joe U (443617)]

Then the project manager should be lectured on proper development techniques.

Re:nTier validation

[Kozz (7764)]

Preaching to the choir, I'm sure!

I was recently criticized for taking the time to do something "right" (i.e. verify and understand the problem and the technology needed to create a reliable solution). My boss indicated that his (crappy) code was meant as an "emergency fix". But come on, we all know that if his code had accomplished the job (however terribly), he'd have left it right there and never attempted to improve it.

Re:

[Kjella (173770)]

Developers? No. Try making a PHB understand that. Or a project manager, which either cuts that or some feature the client will notice right away. Or the guy that gets the ungrateful job of coordinating three teams of completely different teams in different subprojects with different managers, trying to keep a common model of "valid data". The real way it works is more like:

1. User validation = stupid "have you filled out these fields" validation
2. Application validation = application logic validation
3. Data

No no no

[FranTaylor (164577)]

You are missing the point of the attack. The validation IS done, but the attack subverts it.

Validating dates, especially international ones, is enormously complex, and the validation process itself is extremely prone to errors and undesired behavior. If you expect all database clients to do full validation of all input data before passing it on to the database, you are going to see some really miserably performing clients, and not a lot of extra security. Each validation step would also have its own poin

Does it look like this?

[by Anonymous Coward]

delete from comments where 1");--

First Post!!!!!!!!!!

From comic to reality

[GoNINzo (32266)]

This makes it clear it's only a matter of time before xkcd predictions become reality [xkcd.com].

Re:

[metamatic (202216)]

I posted the exact same joke to my own site before the xkcd comic [ath0.com]...

This is not merit a whitepaper

[by Anonymous Coward]

First off, this isn't a new class of attack. This type of attack is already known as second order SQL injection. Second, as several people have noted, you need to be able to execute the ALTER SESSION command. That means you're already issuing SQL commands directly. So, this attack is really only useful when can already inject, but need SQL to run in the context of a more privileged stored procedure. Finally, this attack relies on a very abnormal statement form. All said, that's a whole lot of dominoes that need to line up for a simple elevated SQL privilege.

This whole thing just sounds like an odd bug that someone at NGS found somewhere. It's certainly clever, but it's not a common pattern or new class of bug--and definitely not worthy of a white paper. What I find really odd is that Litchfield and the NGS guys used to do really impressive work. This is way below the bar of what they've produced in the past.

Zen Quote

[alexborges (313924)]

If an unbreakable server breaks, and everyone has their hands over their heads chanting the oracle "unbreakable" mantra whilst picking each other asses with their toes, did it actually break?

Re:

[Shados (741919)]

What will break is your company's check book when the Oracle guys are done billing you for support :)

Simpler prevention

[hanshotfirst (851936)]

Of course this is prevented by the simplest way to prevent SQL injection in Oracle - USE BIND VARIABLES. Each of his examples is thwarted by binding the parameters, instead of simple string concatenation.

Re:To all you type safe ninnies

[AKAImBatman (238306)]

Type safety and "safe" data types are two different things. One is a language construct intended to prevent errors in code through compile-time checking (though you pay in flexibility), the other is types of data that theoretically can be used in a database without doing validation checks.

I'll leave it as an exercise for you to figure out which one is which.

Re:

[ch-chuck (9622)]

Super-genius - that's when a super-villian switches to the light side of the force.

Re:

[Macthorpe (960048)]

Or, and here's a thought, you could just treat as it is, a little bit of exaggeration to add some spice to what would otherwise be a fairly boring news piece.

Just because it's not rigourously defined it doesn't mean you can't use it. You clearly know what they intended, and that's what is important here.

Re:

[sm62704 (957197)]

a little bit of exaggeration to add some spice

Exaggeration and spice belong in entertainment, not news. News should be factual and concise.

to what would otherwise be a fairly boring news piece.

If it's too boring to read it's too boring to post. However, the submitter (IINM) commented with a link.

Re:

[BigBlueOx (1201587)]

The term "super-genius" was coined in modern English in 1952 in "Operation: Rabbit". The fact that the supposedly encyclopedic Wikipedia refuses to index on this term, despite my frequent repeated submissions of well thought out and quite lengthy protest emails, just goes to show their blighted pig-ignorance.

http://en.wikipedia.org/wiki/Operation:_Rabbit [wikipedia.org]

MOD PARENT UP...

[Urban Garlic (447282)]

And to think I wasted my mod points on trivialities in the "Developer" section. If only I'd known something important was coming.

Wile E. Coyote, Sooper Jeenyus -- I like the sound of that.

Re:DB Programming 101?

[0racle (667029)]

People learn database programming now? I thought they just threw together whatever SQL and PHP they could find online and called themselves programmers.

Re:DB Programming 101?

[Shados (741919)]

DB Programming (even the science part, such as the relational model) is virtually never taught in colleges. When it is, its as an elective class most of the time, even in the big name tear-through-your-wallet colleges.

Still cracks me up how in every interview I pass, I always get asked "Ok, so can you explain to me the difference between an inner and an outer join?" or "What is the main benefit of an index on a database table?". Shows the state of the workforce...

Re:

[Chirs (87576)]

Heck, I couldn't answer the first question, so it's not universal knowledge.

But then I'm an embedded realtime systems guy, not a database guy.

Re:

[Shados (741919)]

It isn't universal knowledge because its not taught in schools =P But considering how pervasive databases are in the industry, and that, after all, people go to school to (at least, quite often) become productive and get a job, it definately should be taught.

Its (for databases) on the same level as "Whats the difference between a WHILE and a FOR loop". Since the basics aren't taught, well...you have 500000 servers getting hacked (see article a couple notch down in today's list).

I'm sure there's a lot of th

Re:

[VGPowerlord (621254)]

Since Shados didn't say what the difference is, I will.

Inner and outer joins always have a join condition.
An INNER JOIN only returns the records that satisfy the join condition.
An OUTER JOIN always returns all the results of one (LEFT or RIGHT) or both (FULL) tables, returning nulls for all the requested data in the other table when the join condition is not met.

Maybe that's not clear enough. I'll make a pair of contrived tables to demonstrate.

people
id | name
01 | Bill
02 | Tina

items
id | item
01 | ca

Re:

[rjstanford (69735)]

Seems pretty basic to me...

Re:Why validate when you can sanitize?

[Shados (741919)]

No no no. This has a tons of potential holes, such as an encoding based attack in UTF16 or similar encoding. Use -prepared statements-.

Escaping/sanitizing is just one step up from validating. Let the -driver- do it for you, not the language or the framework. The database itself is the only one who truly knows how to handle itself, and drivers tap into that in prepared statements. -THAT- will protect you. Parameterized query APIs do -not- simply escape stuff in the back. Things are done at the level of the connection, chatting with the database API to create a cached/compiled version of the query, then plug in parameters -after- the query was parsed (so at that point its impossible to modify it).

That is -much- safer than just cleaning up a string (because it cannot abuse encoding/string related features), and has the extra advantage in many DBMS to also allow you to reuse query plan cache, thus improving performance and making it easier to benchmark and profile queries.