back to article New attack technique threatens databases

Database security expert David Litchfield has published details of a new type of database attack technique. Lateral SQL injection creates a means for hackers to access database data or inject hostile code onto vulnerable systems. Exploitation is difficult and only possible in limited circumstances, Litchfield notes. …

COMMENTS

This topic is closed for new posts.
  1. Robert Grant

    Ah, external developers

    What a short-sighted money saver they are.

  2. Chris Miller

    External or internal developers

    It won't make any difference if you don't build security into your requirements and QA processes.

  3. Aodhhan

    Of course...

    How shocking, yet ANOTHER Oracle vulnerability; which will take them 24-32 months to fix.

    If you are crazy enough to use this POS on your enterprise, plan on increasing your auditing for all associated file systems.

    Good luck.

  4. Dominic
    Dead Vulture

    Or you could...

    Sack the 'tard for not using bind variables in his sql code and get someone who knows what they are doing to do the work. It's not as if Tom Kyte hasn't been banging on about this since the beginning of the millenium.

    Sick vulture because it could swallow a program spec and puke better code than that.

  5. kain preacher

    Wait

    I thought only MSSQL was crappy

  6. daniel
    Boffin

    Was Oracle not the one selling UNBREAKABKE databases?

    WTF? Marketing people LIE!!!!

    OMFG. Pwned. Wallhack. My world will never be the same again.

  7. Billy Verreynne
    Thumb Down

    Or you could..

    .. simply break the idiot's kneecaps with a well wielded lead pipe.

    Not using bind variables is beyond idiotic.

    Using DBMS_SQL, the most complex cursor interface in PL/SQL, is just plain stupid - the only time that DBMS_SQL is needed is when requiring a describe interface for a cursor.

    And guess what - needing a describe interface means you have no fricken clue what the SQL projection is, thus dynamic SQL. And dynamic SQL is *ALWAYS* risky - and if you code that without a healthy dose of logic (and bind variables!), and then get hack.. your poor dumb bastard you, you deserved that.

    What is sad though that these "lateral" SQL injections will likely work on many a system. Not because Oracle is that flawed. But because these code monkeys (not to be confused with real programmers) that write PL/SQL are just that damn stupid.

    Seems like many is confusing the "unbreakable" slogan of Oracle to extend to their code monkeys. Sadly, that is not the case.

  8. Anonymous Coward
    Happy

    there's some code missing

    surely an exception section :

    EXCEPTION WHEN OTHERS THEN

    BEGIN

    DBMS_SQL.CLOSE_CURSOR(CURSOR_NAME);

    EXCEPTION WHEN OTHERS THEN RAISE;

    END;

    RAISE;

    Error handling should always exist, regardless of whether you expect it to happen or not. I'm sure there's an easier, more elegant solution, but off the top of my head that should work. Cursors should always be closed in the event of an error!

  9. Gareth Stephens

    Bind, bind, bind!

    As Dominic says this is VERY easy to avoid - simply binding the variable would prevent the attack - in addition it would likely save you resources as well as it would only soft parse the query instead of the hard parse everytime it has a new date plugged into the code.

    @Aodhhan - is it a vulnerability though? Poor coding practice yes, but a vuln that needs fixing? I'm not convinced - IMHO it's a bit like saying that because you can shoot yourself in the foot with pointers in C, C needs fixing...

  10. Matt

    Not a great fan of Oracle but....

    I agree with Gareth. Lazy/incompetent programmers do not a bug make :-)

  11. Anonymous Coward
    Anonymous Coward

    slightly OT, but amusing.

    Hummm data-sanity attack....

    http://xkcd.com/327/

  12. daniel
    Joke

    @matt

    I agrie. Us Prophesionals do not maek erors in our sauce cod.

    And wot F In Prophesionals?

This topic is closed for new posts.