Re: DoS in Shells: was Re: DoS in debian (potato) proftpd: 1.2.0pre10-2.0potato1

From: Sean Davis (diveat_private)
Date: Thu Apr 04 2002 - 10:59:05 PST

  • Next message: Kurt Seifried: "Re: DoS in Shells: was Re: DoS in debian (potato) proftpd: 1.2.0pre10-2.0potato1"

    I tested this on NetBSD/current i386, and here are my results:
    
    in tcsh:
    <dive@eros(/home/dive)> % ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*
    Out of memory.
    
    in bash:
    <dive@eros(/home/dive)> % bash
    bash-2.05$ ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*
    Segmentation fault (core dumped)
    
    in sh:
    $ ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*
    Out of space
    $
    
    in csh:
    % ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*
    Out of memory.
    % 
    
    in ksh:
    $ ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*
    (at this point the shell just sat there, and ate cpu and eventually the ksh
    process was using 95M of memory (total of swap and physical), at which point I
    control-C'd it, as it didn't show any signs of stopping and had been sitting
    there far longer than any of the others without crashing.
    
    in zsh:
    
    
    It looks to me like an inherent way to shoot yourself in the foot with path
    traversal, not really a bug or really a flaw. It would also seem that csh, sh,
    and tcsh handle this correctly: staying true to their inherited rlimits, and
    barfing when they hit them. bash crashes and ksh spins forever (or at least as
    long as I was willing to wait), which are both irritating.
    
    I don't think that filtering paths is an appropriate workaround for this - at
    least not by default. This, in my opinion, is just one of those silly things
    that you shouldn't do, not a real vulnerability. For another example, try using
    ((((a{1,100}){1,100}){1,100}){1,100}){1,100} as a regular expression. It has the
    same effect, running the shell (or the machine, if poorly configured) out of
    memory. Perhaps an option to warn the user and maybe ask if they're sure they
    wanted to glob that? (that is, if it's happening in glob(), I haven't checked
    yet)
    
    Just my three cents :)
    -Sean
    
    On Wed, Apr 03, 2002 at 09:46:59PM -0800, reaktorat_private wrote:
    > 
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    > 
    > Hello All,
    > 
    > I can confirm that the ls strings dos' slackware 8.0. Causes shell process of that user (user or root) to chew up the cpu until the shell terminates on sig 11.
    > 
    > Works on any shell the user is using, csh, ksh, bash
    > 
    > Tested on:
    > Linux 2.2.19 #93 Thu Jun 21 01:09:03 PDT 2001 i586 unknown
    > SunOS 5.8 Generic_108528-12 sun4u sparc SUNW,Ultra-Enterprise
    > 
    > Not Vuln:
    > OpenBSD 3.0 GENERIC#94 i386
    > 
    > Needs more investigation.
    > 
    > Gilbert
    > 
    > 
    > At 03:40 PM 3/29/2002, martin f krafft wrote:
    > >   ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*
    > 
    > ...
    > 
    > >   DenyFilter \*.*/
    > 
    > Just as a quick question, why not deny the string "/../" (you may have to
    > deny the regex "/\.\./", depending how the filter in question works)?
    > 
    > As far as I can tell, it's the ability to embed "/../" into a path that is
    > at the root of this, far more than the ability to embed wildcards.  I can't
    > think of a situation in which "/../" should appear in a user-supplied path,
    > except after a string of repeated "../"s.
    > 
    > The workaround suggested by Mr Krafft would disable some useful
    > functionality - one large user of mine, for instance, was keen to have my
    > own software evaluate wildcards in the body of the path, which Mr Krafft's
    > workaround disables completely.  They even paid for the privilege (not
    > enough, but they paid ;-))
    > 
    > So, let's see, a regex that would deny "/../", except as part of a string
    > of such...
    > 
    > One bash would be "[^/.].*/\.\./" - matching "/../" if it's after any
    > character other than '/' or '.'.  Doubtless someone can come up with
    > something better.
    > 
    > Alun.
    > ~~~~
    > 
    > - --
    > Texas Imperial Software   | Try WFTPD, the Windows FTP Server. Find us at
    > 1602 Harvest Moon Place   | http://www.wftpd.com or email alunat_private
    > Cedar Park TX 78613-1419  | VISA/MC accepted.  NT-based sites, be sure to
    > Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT.
    > 
    > 
    > Hush provide the worlds most secure, easy to use online applications - which solution is right for you?
    > HushMail Secure Email http://www.hushmail.com/
    > HushDrive Secure Online Storage http://www.hushmail.com/hushdrive/
    > Hush Business - security for your Business http://www.hush.com/
    > Hush Enterprise - Secure Solutions for your Enterprise http://www.hush.com/
    > 
    > Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople
    > 
    > -----BEGIN PGP SIGNATURE-----
    > Version: Hush 2.1
    > Note: This signature can be verified at https://www.hushtools.com
    > 
    > wlwEARECABwFAjyr6acVHHJlYWt0b3JAaHVzaG1haWwuY29tAAoJEJajR/iRqwen8mkA
    > oKWAhCudyOHNoO0TfIeYih8gNz+LAJwNhnWkwhJz0GVeZ4sAuxTE9JP5PA==
    > =Sgqo
    > -----END PGP SIGNATURE-----
    > 
    
    -- 
    /~\ The ASCII                         Sean Davis
    \ / Ribbon Campaign                    aka dive
     X  Against HTML
    / \ Email!               http://eros.endersgame.net:8000/~dive
    



    This archive was generated by hypermail 2b30 : Thu Apr 04 2002 - 15:54:03 PST