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

Question... -- ?

[beh]

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.
Would command line handling be a security risk, if someone would add a --superuser-rm option to his code and execute "rm -rf /" as root immediately afterwards?

Lets quote FD while we're at it

[Anonymous Coward]

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.
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. /mz

Re:Lets quote FD while we're at it

[gweihir]

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.

Question... -- ?

[Marneus68]

After years of using command line programs daily I never heard of -- before today. It was never brought up in school, nor did I see any specific thread / blog post on the subject. So to answer your question, I don't. I've never heard about that before. Where did you learn about that ?

Re:Question... -- ?

[drinkypoo]

Where did you learn about that ?

RTFM[anpages.] It's literally in the system documentation. Granted, not all commands have such an option. Knowing which do is your responsibility. Arguably, all commands should have such an option.

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

Re: Question... -- ?

[Anonymous Coward]

rm ./--

Re:Question... -- ?

[hawguy]

You've never had a stupid program crash and create a file named "--" or something similar in its working directory? Now try to remove the file without knowing about the "--" command line options.

rm ./--

Re:Question... -- ?

[TheCarp]

About as I would expect. A fellow admin and I were recently talking about the disown command and how after more than a decade on the job we are still finding out about commands that have existed since we were kids running around on the playground.

Most admins find out about -- after they run into a situation where they accidentally created a file with a name like "-f" go ahead, try and delete a file named "-f" any other way.

It works in many unix commands, actually "--" is a very common "end of options" signal. Really, any command that doesn't have a good syntax reason to not support it, really probably should. Many of the old ones do.

Most people I know who have learned shell learned it on the job in one way or another. There are often a lot of gaps. I did too, it took me a long time to get in the habbit of proper quoting, escaping etc, and this is definitely an easy one to miss.

Re:Question... -- ?

[Anonymous Coward]

I might start using ./ a lot more now.

So, you learned about ./ on /.?

Re:Question... -- ?

[beh]

Sorry, if that appears harsh - but sometimes it pays to read manuals and try and understand what you're doing and how the stuff works.

I don't exactly remember when I learnt it first - but I DID already know when I also got told about it during my CS BSc degree course (probably 1st or 2nd year - which would place it about 1998-2000).

If you need to code stuff "securely", you need to understand how stuff works -- I don't think of myself as a particularly apt security coder or hacker - I mainly specialise on internal systems integration, not so much web or other front-end stuff, so I have the luxury that I already know the data is "sane", before it gets to me - and I "only" need to figure out how to transform it and where to send it on to.

Here are a few pointers, where you might read about it:

http://pubs.opengroup.org/onli...
"Guideline 10:
The first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character."

Even wikipedia mentions it - even though not strictly a "developer" resource:

http://en.wikipedia.org/wiki/C...

"In Unix-like systems, the ASCII hyphen-minus is commonly used to specify options. The character is usually followed by one or more letters. Two hyphen-minus characters ( -- ) often indicate that the remaining arguments should not be treated as options, which is useful for example if a file name itself begins with a hyphen, or if further arguments are meant for an inner command. Double hyphen-minuses are also sometimes used to prefix "long options" where more descriptive option names are used. This is a common feature of GNU software. The getopt function and program, and the getopts command are usually used for parsing command-line options."

If that's too far to go - try "man getopt" on your linux machine:

"
The parameters getopt is called with can be divided into two parts:
options which modify the way getopt will parse (options and
-o|--options optstring in the SYNOPSIS), and the parameters which are
to be parsed (parameters in the SYNOPSIS). The second part will start
at the first non-option parameter that is not an option argument, or
after the first occurrence of `--'. If no `-o' or `--options' option
is found in the first part, the first parameter of the second part is
used as the short options string.
"

man rm - and even rm --help on linux show it:
"
To remove a file whose name starts with a '-', for example '-foo', use
one of these commands:

rm -- -foo
" ...though without explaining the "--" in general...

man chown doesn't mention it, but refers to the full documentation in texinfo and how to access it - that one says under "Common options"

"
`--'
Delimit the option list. Later arguments, if any, are treated as
operands even if they begin with `-'. For example, `sort -- -r'
reads from the file named `-r'.
"

The information is there - and in _lots_ of places - but it DOES requ

Re:Question... -- ?

[jones_supa]

Use "find" to delete the files. This way you avoid all the wildcard bombs. Look in /etc/init/mounted-tmp.conf in Debian/Ubuntu for an example:

# Remove all old files, then all empty directories
find . -depth -xdev $TEXPR $EXCEPT ! -type d -delete
find . -depth -xdev $DEXPR $EXCEPT -type d -empty -delete

Re:Question... -- ?

[fnj]

Most admins find out about -- after they run into a situation where they accidentally created a file with a name like "-f" go ahead, try and delete a file named "-f" any other way.

rm ./-f
Is the most dead-simple way of doing it and is portable to non-gnu-based systems, although even BSD has the double-dash option nowadays.

And there is always the old standby of insulating the operation from bash command line expansion:
perl -e 'unlink "-f";'

You could also, within a minute or so, write and compile a literally two-line C program to remove it. I don't understand the mystery.
#include <unistd.h>
int main() { unlink("-f"); }

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.

Re:Question... -- ?

[TangoMargarine]

after swearing at my terminal for a while before resorting to reading the rm man page.

I find that half the time the swearing comes after trying to read the man page. Then it's time to fire up the old Google...

Re:Question... -- ?

[Chris Mattern]

Can someone explain to me why all these program manpage references have e.g. "(1)" after them?

It's the manpage section. Section 1 is general commands, for example, while section 3 is library calls. Thus, if you want to see the man page for the printf command, you can say "man 1 printf", while if you want to see the man page for the printf system call, you can say "man 3 printf".

Re:Question... -- ?

[virx]

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]

Re:Question... -- ?

[beh]

I did not say purely that reading about -- should tell you about security alone. IIRC my original incident with -- was a colleague setting me a teaser on trying to find out how to delete a file called '-f'; and me first having to figure out, that 'rm ??' reads like delete all files with two character filenames (of which there was only the '-f' file), but not seeing that the ?? actually gets expanded to all the two character filenames by the shell; rm never sees the '??' but instead only sees the filenames - and obviously, it can't discern whether a parameter of '-f' was expanded from the filename -f or intentionally given as a parameter.

If you learn that - you'll get a better understanding of how the system works - and that _in turn_ will help you get a better grasp on what could or would go on and particularly, what could go WRONG, in a system.

Re:Question... -- ?

[the_B0fh]

No, it is not. Granted, GNU doesn't like man pages any more, but in general, reading documentation is the RIGHT THING TO DO.

Re:Question... -- ?

[Anonymous Coward]

So why would the expected method not be the default? This is exactly how security problems are born.

Incompetent people will always mess things up...

[gweihir]

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.

Re:If only this was a Microsoft issue.

[Anonymous Coward]

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.

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.

User data to control commands

[jones_supa]

Systems where user data can accidentally get mixed in control commands are dangerous. In addition to this shell trick, another example would be HTML, where you have to be careful to not let raw HTML data through your guestbook messages so that visitors can't inject HTML into the messages.

With competent and careful system administrators you can avoid problems, but it's still kind of a fragile design in my opinion.

Re:Sanitize crazyness

[itzly]

It's obvious what the intent of "tar cf archive.tar *" is suppose to be, it shouldn't be treating file names as additional arguments

The problem is that the * expansion is done by the shell, and the shell doesn't know the difference between file names and arguments.

Re: Incompetent people will always mess things up.

[Anonymous Coward]

Wake up. Not everyone is a developer. Not everyone has even 2 minutes of unix philosophy.

My Users are scientists, and they get to trash their home space here. These types of issues are most likely to happen when they are writing a script and it makes files for what should have been options.

My job isn't to teach them unix, it's to keep them happy and productive. They make mistakes, I clean them up and help them through the frustration of things going wrong.

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?

Re:in root? Am I missing something?

[jones_supa]

No, you don't need root access. Let's say that you are in a group called "students", which has R/W permission for /work/students and all its subdirectories. You are in directory /work/students, and you want to remove all the files from that directory. Now some wiseass has created a file called "-rf" and you unknowingly end up destroying all the subdirectories too. This happens because the shell expanded the asterisk, instead of the "rm" program. The "rm" program happily interprets the "-rf" as an argument, even though it was originally a file name.

Re:in root? Am I missing something?

[AC-x]

Since one is root, one can do anything anyway so why bother with all this misdirection?

Because you can trick a more privileged user into executing commands for you by writing files into your own folder. Most the examples given were of admin housekeeping tasks run against a user writeable folder.

Re:in root? Am I missing something?

[benjymouse]

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?

The point is that this can be used to trick a root user into issuing what he believes is a safe command. The combination of the text-reinterpreting shell and specially crafted file names combines into a seemingly innocent command ending up allowing the attacker (the creator of the specially crafted file) root access on the system.

It doesn't help that some (on the surface) idempotent commands like find packs a number of dangerous options that can be used to execute shell scripts, commands or remove files.

Re:Question... -- ?

[Anonymous Coward]

"the security risk is the developer that doesn't know what he's doing."

Not the hacker who does know what he is doing.

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:linux problem NOT unix problem!

[AC-x]

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

And what happens if the malicious filename is first in the list?

Re:Question... -- ?

[godrik]

Nop, you can not just use --. because many commands do not understand --

Here is an article by dwheeler (a frequent slashdotter; often cited for his technique countering the trusting trust problem) about filenames.
http://www.dwheeler.com/essays...

I believe he is mostly right. We should move to file systems that do not allow "stupid" names and be done with it.

Computers were conceived to execute user commands

[INT_QRK]

...so wouldn't it be more accurate to to say that computers, like bull-dozers, can be dangerous in the hands of malicious, ill-informed, inattentive, or incompetent users? If you know of any of these archetypes, try to make them smarter, but don't allow them root privileges to anything taller than an ankle-high weed. Give them some locked-down version of Windows, without admin privileges, lots of monitoring tools and features. Consider helmets, knee-pads and child safety locks.

Re:PowerShell

[jones_supa]

Well, yeah. The object-oriented approach is pretty clever for example. Do not have to sweat over spaces in file names breaking your scripts and things like that.

Re:what about?

[Penguinisto]

# rm -rf *.*

(I actually saw a Windows-centric guy do that once as root while he was learning Linux. The look of horror on his face as the entire box began to delete itself was hilarious...)

Re:what about?

[Bradmont]

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.

Re:If only this was a Microsoft issue.

[TheDarkMaster]

Humans beings use spaces in the names they give to things or to other human beings. So, why their computers would have to behave differently?

Re:what about?

[Anonymous Coward]

Depends on the version of Unix that you're using. There a lot of non GNU variants of rm that will happily resolve .. and traverse it. In effect it became a rm -rf /

Use of malicious filenames is at least 30 yrs old

[sconeu]

Back in '83, a friend challenged me to remove a file name "-rf *, without causing collateral damage.

Re:what about?

[Anonymous Coward]

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. :-(

Re:PowerShell

[benjymouse]

Is the wildcard expanded by the shell in PowerShell?

No. This class of attacks will not work against PowerShell (nor for plain old DOS for that matter). The problem is the combination of text-centric shell scripting and shell expanded wildcards.