Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Security Unix Linux

Exploiting Wildcards On Linux/Unix 215

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.
This discussion has been archived. No new comments can be posted.

Exploiting Wildcards On Linux/Unix

Comments Filter:
  • by gweihir ( 88907 ) on Friday June 27, 2014 @10:33AM (#47332581)

    Really, this is well-known, non-surprising and will not happen to anybody with a security mind-set. Of course it will happen in practice. But there are quite a few other variants of code injection (which this basically is) that the same people will get wrong. Complete input sanitisation is mandatory if you need security. I mean, even very early Perl-based CGI mechanisms added taint-checking specifically for things like this. If people cannot be bothered to find out how to pass parameters from an untrusted source securely, then they cannot be bothered to write secure software.

    The fix is not to change the commands. The fix is to exchange people that mess things this elementary up against people that actually understand security. Sorry, you cannot have developers that are cheap and competent at the same time and even less so when security is important.

  • by Anonymous Coward on Friday June 27, 2014 @10:35AM (#47332597)

    There is one great evil that Unix let into its filesystems long ago, one which Apple (which loves generate or perpetuate evil) put into its filesystem and that later Microsoft allowed because it was expedient to align with earlier Apple practice: spaces in file names. If we forbade spaces as well as control characters, things would be much better.

  • by quietwalker ( 969769 ) <pdughi@gmail.com> on Friday June 27, 2014 @10:37AM (#47332613)

    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.

  • Re:Question... -- ? (Score:5, Interesting)

    by locofungus ( 179280 ) on Friday June 27, 2014 @10:38AM (#47332621)

    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 ;-)

  • by gweihir ( 88907 ) on Friday June 27, 2014 @10:41AM (#47332657)

    It may be counter-intuitive for people that have very little experience with a UNIX commandline. All others did run in the issue at some time that they could create, but not easily delete a filename "-v" or the like. But people with very little UNIX commandline experience have zero business writing security critical software that uses the commandline tools!

    This is a complete non-issue. Incompetent people will usually screw security up and this is just one of the countless ways to do it.

  • by gb7djk ( 857694 ) * on Friday June 27, 2014 @11:11AM (#47332943) Homepage

    Er.. most of the exploits are only possible if one is root and/or the directory is writable for some other user (e.g. leon in this case).

    Since one is root, one can do anything anyway so why bother with all this misdirection? If someone leaves world writable directories lying around (especially without the sticky bit set), then they deserve everything they get. Or is this some kind of "trap the (completely) unwary sysadmin" wake up call? If I see some strange named file (especially if I know I didn't put it there) I would investigate very, very carefully what is going on. I can't be alone in this - surely?

  • by Gunstick ( 312804 ) on Friday June 27, 2014 @11:17AM (#47332993) Homepage

    This is because the linux commands do not respect what the manual says:
    man rm...

    rm [OPTION]... FILE...

    but in realitiy it's rather:

    rm [OTION|FILE]...

    whereas on other unix systems it works as expected, first the options, then the arguments
    rm *
    rm: DIR1 directory

    rm *
    rm: DIR1 directory

    So screw the GNU tools, they mess things up for the "old unix sysadmins"

    Here is a nice linux/unix trap:
    y="rm z"
    f=$x $y

    So you expect f to contain: a rm z
    not really...
    z: No such file or directory
    so the rm actually was executed

    a=$x is an environment variable attribution, so $y becomes an executed command...
    And that one works on any unix/linux
    Recently patched in chkrootkit (CVE-2014-0476)

  • Re:Question... -- ? (Score:3, Interesting)

    by Anonymous Coward on Friday June 27, 2014 @11:48AM (#47333321)

    That is B.S.

    If someone reads that, they do not think security. They think it is an escape to deal with files that start with - and that is where they file it in their head. You also have to understand about '*' and think about how the two would work together.

    This is exactly why computer code is insecure.

A CONS is an object which cares. -- Bernie Greenberg.