New Attack Exploits "Safe" Oracle Inputs 118
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 (Score:5, Interesting)
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:nTier validation (Score:3, Interesting)
1. User validation = stupid "have you filled out these fields" validation
2. Application validation = application logic validation
3. Data logic = field validation and foreign keys etc. to not leave dangling data that's invalid or inconsistant
There's no point in making more client-side validation than that, because you can assume an attacker will send raw data at you anyway. The database layer is rather fucked if the commands are already injected - the best a database can do is to treat data types as expected and not fall for that kind of tricks.
This is not merit a whitepaper (Score:4, Interesting)
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.