Re: Details on Directory Traversal bugs

From: J Edgar Hoover (zorchat_private)
Date: Wed May 30 2001 - 09:19:52 PDT

  • Next message: mcoleman: "PIX revealing Statics when hit with NMAP..."

    On Tue, 29 May 2001, Neuronix wrote:
    
    > Hello,
    >
    >   We've see every week some kind of directory traversal bug in a
    > multitude of softwares... but anyway, I'd like to know the roots of this
    > kind of bug. Where did it come from? What kind of strings can be used
    > to test for if a particular software is vulnerable? I intend to automate
    > the process of checking, in case there's a particular pattern to be
    > followed.
    
    The bug is at least 25 years old. It comes from trying to convert
    userdefined data into a filesytem path.
    
    I've seen it on early "time share" operating systems, in the context
    evading attempts to make files (e.g. passwords) unreadable to users. It
    existed on dialup BBSs, in the form of an archive that extracts to
    relative ..\.. paths.
    
    Microsoft has re-invented it for every version of windows so far.
    
    The fix is, not to directly use data supplied by the user to define which
    file to access.
    
    MS keeps the problem alive on their products by not addressing that
    underlying issue, and instead attempting to add successive layers of
    filters to prevent known exploit strings from passing to a filesystem path
    argument.
    
    The common practice of using the filesytem to structure html content is
    probably a bad idea in itself. If i were to design a web server from the
    ground up, I'd think about adding a level of abstraction, and perhaps a
    table that references pre-defined files to a specific URL request.
    
    In the context of a vulnerability scanner, I'd say that if you can
    determine that the URL structure is based on filesystem structure, there
    is a potential for a variant of ../.. bugs.
    
    Cheers,
    zorch
    



    This archive was generated by hypermail 2b30 : Wed May 30 2001 - 20:42:21 PDT