Slashdot Mirror
Exploiting Wildcards On Linux/Unix
An anonymous reader writes: DefenseCode researcher Leon Juranic found security issues related to using wildcards in Unix commands. The topic has been talked about in the past on the Full Disclosure mailing list, where some people saw this more as a feature than as a bug. There are clearly a number of potential security issues surrounding this, so Mr. Juranic provided five actual exploitation examples that stress the risks accompanying the practice of using the * wildcard with Linux/Unix commands. The issue can be manifested by using specific options in chown, tar, rsync etc. By using specially crafted filenames, an attacker can inject arbitrary arguments to shell commands run by other users — root as well.
Who does NOT use -- in their scripts, if they're safety conscious?
rm -i -- *
Problem solved?
Normal programs should stop processing options after a (standalone) "--" and take everything following it as regular parameters. getopt and similar libraries handle this automatically.
I really wouldn't class the "use of wildcards" as a security risk - the security risk is the developer that doesn't know what he's doing. /" as root immediately afterwards?
Would command line handling be a security risk, if someone would add a --superuser-rm option to his code and execute "rm -rf
posting the answer to this useless story that was posted to FD
Date: Thu, 26 Jun 2014 12:55:42 -0700
From: Michal Zalewski
> We wanted to inform all major *nix distributions via our responsible
> disclosure policy about this problem before posting it
I'm not sure how to put it mildly, but I think you might have been
scooped on this some 1-2 decades ago...
Off the top of my head, there's a rant about this behavior in "The
Unix-Haters Handbook", and there are several highly detailed articles
by David Wheeler published over the years (e.g.,
http://www.dwheeler.com/essays/filenames-in-shell.html).
Yup, it's a counterintuitive behavior that leads to security problems. /mz
The odds of changing the semantics at this point are very slim. Other
operating systems have their own idiosyncrasies in this area - for
example, Windows it not a lot better with parameter splitting and
special filenames.
I remember reading about this in the 1991 release of "Practical Internet and Unix Security," from O'Reilly back in 1991. I'm pretty sure they even gave examples. They also laid out a number of suggestions to mitigate risk, including not specifying the current path, ".", in the root user's path so they must explicitly type the location of an executable script, and so on.
They also pointed out that some well-behaved shells eliminate certain ease-of-use-but-exploitable features when it detects that a privileged user is running it, and even on systems where that's not the standard, the default .bashrc or equivalent files often set up aliases for common commands that disable features like wildcard matching, or color codes (which could be used if you're very tricky, to match a filename color to the background color of the screen, among other things), the path restriction listed above, and many many others.
It's really hard to secure shell accounts on systems, no matter how you try. Is this article just proof that the current generation of unix admins is rediscovering this? Should I be shaking my fist and telling the kids to get off my lawn? This was old news 2 over decades ago.
Back in the (iirc) bsd 4.2 days, su was a suid shell script - at least on the machines I was using at the time.
Setup a symlink to su called -i
$ -i
# rm -- -i
#
There was a security bug handling suid shell scripts where the user was changed and then the #! interpreter was run, i.e. /bin/sh -i
and you got an interactive root shell :-)
Was very informative when the 'script kiddies' (although I don't recall that term existing in those days) had symlinks called -i in their home directory that they didn't know how to delete ;-)
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
I might start using ./ a lot more now.
So, you learned about ./ on /.?
man man
The table below shows the section numbers of the manual followed by the types of pages they contain.
1 Executable programs or shell commands
2 System calls (functions provided by the kernel)
3 Library calls (functions within program libraries)
4 Special files (usually found in /dev)
5 File formats and conventions eg /etc/passwd
6 Games
7 Miscellaneous (including macro packages and conventions), e.g. man(7), groff(7)
8 System administration commands (usually only for root)
9 Kernel routines [Non standard]
Unless you were, say, in /etc, this wouldn't really do much harm. The only file containing a . in my / is initrd.img, which even if it weren't a symlink, is easy to to regenerate.
-r is the recursive switch causing it to visit every sub directory.
So, rm -rf *.* would delete any file in the entire file system with a . in it....including, as you point out, /etc.
No, it wouldn't!
The shell expanse the wildcards before calling the command. All rm sees is "initrd.img" as argv[2].
rm will not see the *.* at all, unless the shell can't expand the wildcard to any valid file- or directory name and even if the shell had to forward the *.* as-is to rm (if *.* didn't match anything in /), rm still wouldn't find anything matching /etc/*.* as it doesn't do glob()'ering itself. Why would it? The shell already did that.
Furthermore -r means "visit any subdirs of the dirs given as arguments to rm ", not "all directories there ever was and ever will be".
TL;DR: You have no idea what the hell you're talking about.
Damn it, /. You used to be cool and know this stuff. :-(