Date: Sat, 28 Jun 2014 14:01:19 +0200
From: Cley Faye <cleyfaye@...il.com>
Cc: fulldisclosure@...lists.org
Subject: Re: [FD] Back To The Future: Unix Wildcards Gone Wild

It is even harder to exploit, as shell glob (at least in bash...) keep
filenames as a whole arguments, so the list of argv would be more like
['-rf .. a.c', 'someproc.c', 'otherprog.c', 'otherprog2.c']. And bash
doesn't match '*' with '.' and '..' either. In this case, rm would just get
'-rf .. a.c' as a single argument, and not parse it as an option followed
by paths.

So to exploit that, you would need filename that are meaningful args, and
that get in the right order, and don't rely on '.' and '..' (unless some
script does use '.*').

It's still a possible issue if you're not careful in your script, but not
as bad as usually described.

How bash glob args:
$ cat a.c; gcc -std=c99 a.c -o a; ls -l; ./a *
#include <stdio.h>

int main(int argc, char* argv[]) {
    printf("Args:\n");
    for (int i = 0; i < argc; ++i) {
        printf("arg %d: \"%s\"\n", i, argv[i]);
    }
    printf("Done\n");
    return 0;
}

total 12
-rwxr-xr-x 1 me me 5359 juin  28 13:49 a
-rw-r--r-- 1 me me 208 juin  28 13:47 a.c
-rw-r--r-- 1 me me    0 juin  28 13:45 a.txt
-rw-r--r-- 1 me me    0 juin  28 13:45 b.txt
-rw-r--r-- 1 me me    0 juin  28 13:45 -rf .. a.c
Args:
arg 0: "./a"
arg 1: "a"
arg 2: "a.c"
arg 3: "a.txt"
arg 4: "b.txt"
arg 5: "-rf .. a.c"
Done
$


2014-06-28 12:26 GMT+02:00 <steel-wing@....net>:

> Unfortunately, this analysis is just as flawed as defencecode's.
> Programs like 'rm' are even less "to blame" for this than the shell.
> As to the proposed solution:
> What you are suggesting is to have rm attempt to match every
> option passed to it against every file single before said file
> is to be removed. Correct?
> The problem with this approach is that the crafted filename
> itself will never be seen by /bin/rm in the first place.
> For example:
>
> # ls -l
> -rw-------  1 attacker attacker      0 Jan  1  1970 -rf .. a.c
> -rw-------  1 user     user       1000 Jan  1  1970 someprog.c
> -rw-------  1 user     user       1000 Jan  1  1970 otherprog.c
> -rw-------  1 user     user       1000 Jan  1  1970 otherprog2.c
> # rm *
> rm: a.c: No Such File or Directory
> # ls -l
> total 0
> #
>
> And rm simply sees an argv that looks like:
> ['/bin/rm', '-rf', '..', 'a.c', 'someprog.c', 'otherprog.c',
> 'otherprog2.c']
>
> Honestly, I don't know how it's supposed to know that anything's wrong.
> So while one *could* add code to rm to make it check every directory that
> it
> deals with for potentially abusive file names, one *should* not do so
> because it violates UNIX convention, and is unlikely to accomplish anything
> other than adding strange and vaguely nonfunctional behavior to rm.
>
> Rule of thumb:
>         If you are using 'rm' wildcards on the same command line,
>         first ask yourself: "Why?".
>
> On Fri, Jun 27, 2014 at 11:39:22AM +0100, Nick Lindridge wrote:
> > This is an interesting old trick but not any fault with the wildcard
> > mechanism (though a bit array indicating whether an argv item is the
> > result of an expansion would be nice). Taking the rm program as an
> > example, the vulnerability report should really be citing rm as
> > vulnerable for failing to factor knowledge of this behaviour into
> > some sanity checking. As a start, rm could test to see whether any
> > of the command line options match files to be removed, knowing that
> > the option could then have come from an unintended wildcard
> > expansion. The program could then require an option to force the
> > operation.
> >
> > If we accept therefore that the deficiency is with the utilities
> > themselves, perhaps you could research and contribute a
> > vulnerability report that lists all of the commonly used programs
> > that could be affected by this behaviour. Such a report could set
> > the basis for a road map of improvement in the listed utilities.
> >
> > Nick
> >
> > On 26/06/2014 09:40, defensecode wrote:
> > >Hi,
> > >
> > >We wanted to inform all major *nix distributions via our responsible
> > >disclosure policy about this problem before posting it, because it is
> > >highly likely that this problem could lead to local root access on many
> > >distributions. But, since part of this research contained in the
> document
> > >was mentioned on some blog entries, we are forced to release it in a
> > >full version.
> > >
> > >Download URL:
> > >
> http://www.defensecode.com/public/DefenseCode_Unix_WildCards_Gone_Wild.txt
> > >
> > >Regards,
> > >Leon Juranic
> > >
> > >
> > >_______________________________________________
> > >Sent through the Full Disclosure mailing list
> > >http://nmap.org/mailman/listinfo/fulldisclosure
> > >Web Archives & RSS: http://seclists.org/fulldisclosure/
> >
> > --
> > Best regards
> > Nick
> > --
> > ionCube Software LLP
> > @ioncube / uk.linkedin.com/in/nicklindridge
> > +44-208-099-3608
> >
> >
> > _______________________________________________
> > Sent through the Full Disclosure mailing list
> > http://nmap.org/mailman/listinfo/fulldisclosure
> > Web Archives & RSS: http://seclists.org/fulldisclosure/
>
>
> _______________________________________________
> Sent through the Full Disclosure mailing list
> http://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/
>

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists