Unix Wildcards Gone Wild
defensecode.com
Unix Wildcards Gone Wild
1–10 of 54 posts
Re: Unix Wildcards Gone Wild
#2Good summary of surprising behavior. You can work around a lot of these issues using "--" as an argument before you use any wildcards. This tells most commands to stop processing options and treat the rest of the arguments as files (or whatever other non-option arguments the command takes). That's getopt(3)'s behavior[0]. For example, "rm -- *" will not have the problem where directories are removed if there's an entry called "-rf" in the directory.
[0] http://pubs.opengroup.org/onlinepubs/9699919799/functions/ge...
Re: Unix Wildcards Gone Wild
#3I really wonder who this person asked, that was an "old-school Unix admin", that didn't know of this attack. This article also doesn't mention the countermeasure which is available in every utility I know of: the -- argument, which disables parsing of all further arguments and treats them just as filenames.
Re: Unix Wildcards Gone Wild
#4Good summary of surprising behavior. You can work around a lot of these issues using "--" as an argument before you use any wildcards. This tells most commands to stop processing options and treat the rest of the arguments as files (or whatever other non-option arguments the command takes). That's getopt(3)'s behavior[0]. For example, "rm -- *" will not have the problem where directories are removed if there's an ent…
A better workaround is to prefix your wildcarded arguments with ./ as this will work with all commands. For example, rm ./* will safely remove files regardless of how they're named.
Re: Unix Wildcards Gone Wild
#5David A. Wheeler, FOSS (and occasionally security) luminary, who also happens to be creator of the popular sloccount tool, has an excellent page that covers this topic and how to use paths safely and portably in shell scripts (spoiler: it's hard) :
http://www.dwheeler.com/essays/filenames-in-shell.html
I strongly recommend his many other essays to HN readers: http://www.dwheeler.com/
Edit: a simple way to avoid these problems is to prepend the wildcard with ./ (so globbed files won't start with - or -- but with the path ./) and on GNU systems put -- before the wildcard, telling the tool that following arguments are not options.
Re: Unix Wildcards Gone Wild
#6There's a reason this isn't talked about, it's not an actual legitimate/common vector to compromise a server.
Re: Unix Wildcards Gone Wild
#7"I'm not sure how to put it mildly, but I think you might have been scooped on this some 1-2 decades ago..."
Re: Unix Wildcards Gone Wild
#8I think if you have the ability to create new files on a remote host, you are already compromised. No need to wait for an Admin mistake.
Re: Unix Wildcards Gone Wild
#9I think if you have the ability to create new files on a remote host, you are already compromised. No need to wait for an Admin mistake.
There are hosts with multiple users on them, who have some level of write access to somewhere on the filesystem. After all, Unix is a multi-user system, so it is not heard of to have multiple users on it. That being said, this article is just stating to be careful of wildcards when you are sitting in a user-owned (or user-writable, such as /tmp) directory.
Re: Unix Wildcards Gone Wild
#10I think if you have the ability to create new files on a remote host, you are already compromised. No need to wait for an Admin mistake.
Not necessarily, you could make a .zip/.tar file with filenames like these that could trip up the end user trying to clean up after unpacking.