Re: Back To The Future: Unix Wildcards Gone Wild

[steel-wing () att 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/

Attachment: _bin
Description: PGP Key 0x55D89FD9.

Attachment: signature.asc
Description: Digital signature

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