Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unix Wildcards Gone Wild

defensecode.com

Post reply on HN
Print view View original

31–40 of 54 posts

Re: Unix Wildcards Gone Wild

#31

Post by jingo »

jordigh wrote: post #24
jingo wrote: post #19

echo rm * echo chown -R nobody:nobody *.php echo chmod 000 * echo tar cvvf archive.tar * echo tar cf archive.tar * echo rsync -t *.c foo:src This article starts with the premise that the person executing the command has no idea what files are in the current working directory. That is itself a more serious problem than the behaviour of wildcards. Later in the article we learn that it also assumes GNU utilities. That i…

> GNU userland and unneeded complexity (e.g. more features than any user will ever use) are practically synonymous. Ahhhh, the memories. These accusations bring me back to the early 1990's. Remember? Remember how it was? Oh, boy, how did we all get so old? To be young and running System V again... And still today, whenever I'm faced on a system without GNU utilities, I find myself installing them to get what seems to…

To be young and running VMS again...

Re: Unix Wildcards Gone Wild

#32

Post by eru »

jingo wrote: post #19

echo rm * echo chown -R nobody:nobody *.php echo chmod 000 * echo tar cvvf archive.tar * echo tar cf archive.tar * echo rsync -t *.c foo:src This article starts with the premise that the person executing the command has no idea what files are in the current working directory. That is itself a more serious problem than the behaviour of wildcards. Later in the article we learn that it also assumes GNU utilities. That i…

> This article starts with the premise that the person executing the command has no idea what files are in the current working directory. That is itself a more serious problem than the behaviour of wildcards.

Substitute `person executing the command' with `simple script', and you've got a better justification. I don't want my simple scripts to break down in the face of silly filenames.

Re: Unix Wildcards Gone Wild

#33

Post by vacri »

ninkendo wrote: post #28
Maken wrote: post #25

Earlier quoted context omitted.

Yes, because no user-uploaded filename will ever be parsed by a maintenance script in a server.

Not by any sane person, no. Why are you letting people upload and name their own files on your server? Should we be posting articles about the vulnerabilities in the finger daemon or Solaris 8's NIS implementation, while we're at it? It seems like this article is aiming towards shared servers where you actually allow shell login to "untrusted" users, which IMO is a relic of days long past, that only really persists a…

This kind of article is good to keep bubbling up over time, to educate new users in best practices. Not everyone is a 20-year unix admin that's seen a bit of everything.

Re: Unix Wildcards Gone Wild

#34

Post by pdkl95 »

This is why I not only use "--" everywhere, I also religiously use full quoting of "${vars[@]}" and options like mv(1)'s --no-clobber when appropriate. Even without the security concerns, this kind of "least privilege" approach can help prevent a lot of really-annoying bugs.

That said, I going to have to check a few scripts for that chmod attack (or similar) - I think I've seen that type of attack before, but I must have forgotten about it... sigh

Re: Unix Wildcards Gone Wild

#35

Post by pmahoney »

AceJohnny2 wrote: post #5

David 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 thes…

> portably in shell scripts (spoiler: it's hard)

At what point do you give up and, if you must have portability, bootstrap a saner environment?

Are there many options in this area? Assume perl is available? Use autoconf-like shell script compiler? Starting with Lua (which I hope/assume can build anywhere, though I know it's missing lots of functionality out of the box)?

Re: Unix Wildcards Gone Wild

#37

Post by jingo »

jingo wrote: post #19

echo rm * echo chown -R nobody:nobody *.php echo chmod 000 * echo tar cvvf archive.tar * echo tar cf archive.tar * echo rsync -t *.c foo:src This article starts with the premise that the person executing the command has no idea what files are in the current working directory. That is itself a more serious problem than the behaviour of wildcards. Later in the article we learn that it also assumes GNU utilities. That i…

I keep forgetting that GNU echo has an -e option, which, if I'm not mistaken, makes it behave like printf. (Why does it need this feature when there also exists a builtin printf? Nevermind.)

Anyway, I didn't think about what happens if you create one file called "-e" and then do

    echo *
Anyway, as someone else pointed out, using ./* instead of * will defeat the "exploits" in the article.

Re: Unix Wildcards Gone Wild

#38

Post by evacchi »

Many of these gotchas have been known for quite a while. I suggest, for people who still don't know it, to read the UNIX-HATERS handbook

- homepage http://homes.cs.washington.edu/~weise/unix-haters.html

- working download link http://richard.esplins.org/static/downloads/unix-haters-hand...

A lot of it is outdated, and yet many things are still incredibly relevant

Re: Unix Wildcards Gone Wild

#40

Post by claudius »

JadeNB wrote: post #11

Many people are recommending the '--' option-terminating option. Note David Wheeler's caution (in the essay already linked by AceJohnny2 at https://news.ycombinator.com/item?id=8190208 ) about why this is not an all-purpose solution: http://www.dwheeler.com/essays/filenames-in-shell.html#dashd... .

The reasons given there aren’t really any good:

  1. For “--” to work, all maintainers would have to faithfully use “--” in
     practically every command invocation. That just doesn’t happen in real
     life,  even after decades  of people trying.  People forget it all the
     time;  no one is that consistent,  especially since code seems to work
     without it. Very few commands require it, after all.
So because other people may or may not forget it, I shouldn’t use it in my scripts/day-to-day usage? That’s about as silly as saying that, because other people will write unreadable code anyway I shouldn’t bother with comments, short functions or sensible variable names.

  2. You can’t do  it anyway,  even if you  were perfectly consistent; many
     programs and commands do not support “--”.  POSIX even explicitly for-
     bids echo from  supporting “--”,  and echo must support “-n”  (and GNU
     coreutils echo supports other options too).
This is a problem, but iff you have to use echo for some reason. printf works nearly equally well and supports -- just fine. I may have read somewhere that using printf is actually advocated nowadays, but I’m not sure where and why.
Post reply on HN