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."

Re:heh

[arth1]

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

nTier validation

[Joe U]

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?

Thats what they said about cross site scripting.

[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 and ignorance.

Re:heh

[Joe U]

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:heh

[moderatorrater]

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:DB Programming 101?

[0racle]

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]

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:nTier validation

[Kozz]

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:Why validate when you can sanitize?

[Shados]

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.

Re:heh

[Anonymous Coward]

The kind of idiot who wouldn't have a paper to publish on their website if they actually weren't creating their own security holes.

This is IT security equivalent of a strawman argument.