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

21–30 of 54 posts

Re: Unix Wildcards Gone Wild

#21

Post by _delirium »

AceJohnny2 wrote: post #13
teddyh wrote: post #12

Earlier quoted context omitted.

The double dash -- to stop option parsing is not a GNU thing – it comes from the POSIX standard.

Thanks! I had always figured that, along with long options, they were a GNU thing.

There's some digging here: http://unix.stackexchange.com/questions/147143/when-and-how-...

Looks like the convention was introduced as part of getopt in AT&T Unix System III (1980), though initially only in a handful of places. Then POSIX adopted it as standard for all utilities sometime later.

Re: Unix Wildcards Gone Wild

#22

Post by mschuster91 »

ZoF wrote: post #6

There's a reason this isn't talked about, it's not an actual legitimate/common vector to compromise a server.

Oh it is. Many people do e.g. backups of all userdirs by using tar * as root inside a cron, thus rendering themselves vulnerable.

Re: Unix Wildcards Gone Wild

#24

Post by jordigh »

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 me like basic functionality. We have never changed, have we?

Re: Unix Wildcards Gone Wild

#25

Post by Maken »

ZoF wrote: post #6

There's a reason this isn't talked about, it's not an actual legitimate/common vector to compromise a server.

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

Re: Unix Wildcards Gone Wild

#26

Post by emmelaich »

This is one of the reasons sudo should (by default) only allow a whitelist of built-in commands to be run with wildcards.

Somewhat like sudoedit.

This is of course for the corporate case of a less privileged user performing a certain task at elevated privileges. Not for the more common use of sudo (these days) of people managing their own personal machines.

Re: Unix Wildcards Gone Wild

#27

Post by emmelaich »

AceJohnny2 wrote: post #13
teddyh wrote: post #12

Earlier quoted context omitted.

The double dash -- to stop option parsing is not a GNU thing – it comes from the POSIX standard.

Thanks! I had always figured that, along with long options, they were a GNU thing.

They were quite distinct.

When --longopt was starting to get popular (in an ad-hoc way) for gnu and other utilities there was a poll (gnu.misc? late 90s?) whether to make it a gnu standard. The other choices were a +, or have commands not accept both bundled single letter options and longopts. There may have been other choices I've forgotten about.

The double-dash won. There were some people who were concerned that it might be confused with the end-of-args double dash.

Maybe that is true but they are certainly unambiguously parsed.

Re: Unix Wildcards Gone Wild

#28

Post by ninkendo »

Maken wrote: post #25
ZoF wrote: post #6

There's a reason this isn't talked about, it's not an actual legitimate/common vector to compromise a server.

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 at (maybe) universities. Hell, even at the university I last worked at 6 years ago we just gave everybody their own VM. And nowadays I wouldn't even need to give them that... students can download and run a vagrant environment on their personal machine in like 2 commands.

It's not to say there's no audience for articles like this... I'm sure there's plenty of environments out there that still follow the multi-user server model from the 1970's, and I certainly pity anyone who has to administer those types of systems. But it certainly should be no surprise to anyone that there's a lot of malicious things you can do if you have shell access to a system (or to your point, the ability to upload arbitrarily-named files with arbitrary content. shudder)

Re: Unix Wildcards Gone Wild

#29

Post by ninkendo »

LunaSea wrote: post #16
ZoF wrote: post #6

There's a reason this isn't talked about, it's not an actual legitimate/common vector to compromise a server.

Could you go into more details ?

In most environments it would be insane to allow anybody untrusted to put files on your server. That includes a trusted sysadmin extracting unknown tar files on your server. It's a case of "if they got this far, you're already fucked."

Re: Unix Wildcards Gone Wild

#30

Post by lobster_johnson »

dijit wrote: post #17
lobster_johnson wrote: post #14

Tangentially, anyone know how to make zsh less greedy about parsing wildcards? Something like this will fail with "no files matched", and the command won't run: rsync example.com:/foo/* . My workaround is to quote the argument, but it's annoying.

escape it, since you know the shell is going to be greedy about things. rsync accepts globbing it's not a shell expansion that makes it work. rsync example.com:/foo/\* .

Well, the problem is that "example.com:/foo/*" isn't actually a local path that can ever be globbed by zsh alone -- it's an rsync/ssh/scp-style remote path, yet zsh interprets it as such. Not sure why. I think the solution is make sure zsh ignores arguments containing colons, but I don't know what the config option is for that.

Edit: Just remembered that zsh's over-eager globbing also fails with git -- eg., "HEAD^" must be quoted.

Post reply on HN