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.

Comments

He could have researched a bit harder.

[quietwalker]

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... -- ?

[locofungus]

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

in root? Am I missing something?

[gb7djk]

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?

linux problem NOT unix problem!

[Gunstick]

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
HP-UX
rm *
rm: DIR1 directory

Solaris
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:
x=a
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... -- ?

[Anonymous Coward]

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.