Re: hard-coded windows exploits

From: Simple Nomad (thegnomeat_private)
Date: Wed Nov 17 1999 - 20:46:36 PST

  • Next message: Blake Frantz: "Re: Tektronix PhaserLink Webserver Reveals Admin Password"

    > > Just a general note concerning Windows overflows - most (if not all) of the
    > > publicly available exploits I have seen floating around are still using
    > > hard-coded addresses for system calls.
    > >
    > > Is this the only way to do this? Note that this method has been around for a
    > > while, but I haven't seen any public releases of it. If anyone knows of any
    > > other ways....
    >
    >         I don't think that this is the only way to do it, what about
    > using direct
    > system calls? you don't need addresses for that, just call INT 2e/2c/2b
    > with the
    > correct registers...
    >
    >         I can add to this, that it may be a little harder to do, but
    > anyway,
    > kernel32.dll calls INTs or calls ntdll.dll that uses INT 2e/2c/2b to
    > talk with NT's kernel, so everithing looks like possible with INTs.
    
    Ah but often it is the *timing* of the direct system call that counts.
    Invoking a call to adjust (or capture) needed register values followed by
    an INT is one aspect of this. Internal race conditions between system
    calls are another. I've worked long and hard trying to do remote buffer
    overflows in Netware for example, and while it can be done due to the
    nature of how memory is used and NLMs are "registered" with the OS during
    the load, it dictates direct addressing. But then you end up with an
    exploit that works with a specific configuration, such as 64MB ram with
    only these drivers and specific version of NLMs loaded in a certain
    order, etc.
    
    Actually I'd prefer the "viral" approach in these situations. Exploit code
    that does more than simply overwrite areas of memory and/or pokes in
    values to registers. Exploit code that becomes a part of the operating
    environment "legally", and then exploits conditions within that area.
    Dildog's KnownDLL hack from February of this year is a good example of
    this, as it is based upon how things actually work vs. how things are
    *supposed* or *should* work.
    
    Ideally your kernel has some smarts about it, and compartmentalizes itself
    to prevent processes from accessing various sections without permission.
    But since most OSes have monolithic operating environments....
    
        Simple Nomad    //
     thegnomeat_private  //  ....no rest for the Wicca'd....
        www.nmrc.org    //
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:13:13 PDT