I don't get it, it's not really unexpected if you pass the name of the executable (which just happens to be a script) via a flag... used explicitly for passing an executable to run.
I mean, is it unexpected if `./my_command --execute-this-right-now=somescript.sh` executes somescript.sh?
Perl has a special "taint" mode (Ruby does, too, I think, but I don't know about the differences or similarties), where any data coming from outside the program - environment variables, network connections, files, etc. - is considered "tainted", i.e. treated as bad, until you validate it using regular expressions (or something along those lines). I have to admit I never tried it, but it sounds like a good idea, assuming it works as advertised, when dealing with potentially malicious input or paranoia.
> but ruby doesn't track external strings as dirty like that.
Yes, it does. E.g:
x = STDIN.gets
puts x.tainted?
y = "hello "+x
puts y.tainted?
z = "foo"
puts z.tainted?
The two first will return "true", and the last will print "false". If you set the safe-level appropriately some methods will be disallowed for x and y above (e.g. eval()), though I would not trust that as comprehensive, but it's a lot better than nothing.
There's simple ways to "escape" user input (as in, ensure the whole input string is interpreted as a single argument to this program) in ways that ensure you can't do simple &&'s or ;'s and execute a totally different command. But the point of the article is even if it's properly escaped, users can still do malicious things when input is passed to lots of standard UNIX utilities.
What I wish, I wish there was a flag in unicode to declare characters as 'unsafe user input' so that system utilizes and databases can recognize unsafe user input and barf on it.
I don't think you even understand the concept of in-band and out-of-band, that's not a function of the encoding. And I've written protocols aplenty in the days when not everything ran on top of HTTP, high speed serial links, with and without virtual circuits (so mux-demux) and a whole slew of others.
Just to make sure you are on the same page as the rest of us here: in-band and out-of-band is a way to distinguish sending meta information about the data stream through the same channel as the original data. You need an escape mechanism for that, so control characters and such.
Out-of-band signalling indicates that all meta information about the data stream travels through a different (virtual) circuit, in which case there can never be confusion about whether a given chunk is data or meta info.
This is a point that should have been made in the author's article. As it is, it presents a poorly defined problem without offering solutions (other than "be afraid").
I think he wants to bring to peoples attention that if you give someone sudo rights for a specific program chances are that they will be able to elevate their privilegies.
There's been a bit of attention recently on these things. The big issue is people using " * " on the command line without prefixing with an "--" argument or simply "./*". If someone has managed to sneak in particularly evil filenames (that look like -options), then the unsuspecting user may be in for a surprise, for example tar'ing up a public upload directory.
Yes, it's unexpected and less commands should do that.
Did you read the manpage of every utility on your computers to know that they won't execute a user supplied program? If you didn't you are up to nasty surprises.
That $HOME trick alone would give privilege escalation to anybody that gets a user-level access to a server of mine. Gota change it.
How so? I might be missing something but as far as I can tell it's just executing the runme.sh as the user who ran the bash command. It would be virtually identical to ./runme.sh
This way around is perfectly obvious. But assume that you are writing a website that prints a man page, for example by piping the output of man $URLPARAMETER to the user. In that case it is only obvious to check if man can execute arbitrary commands if you already know that man is not just a cat for man pages.
> "If the archive file name includes a colon (`:'), then it is assumed to be a file on another machine. If the archive file is `user@host:file', then file is used on the host host. The remote host is accessed using [rsh]."
and
> "If you need to use a file whose name includes a colon, then the remote tape drive behavior can be inhibited by using the `--force-local' option."
On many systems, rsh is aliased to ssh, so if you don't properly sanitize your archive names, GNU tar will make network connections.
Wow... I'm starting to get really scared of the shell, and how much hidden complexity there is waiting to trap the unwary. Feels like best practice for shellscripts is to only ever use them for one-offs. And that tar and friends should never be used as "helpers" by other programs.
Complexities that are ready to bite the hand of the unwary at the slightest of chances.
Honesty i think the biggest lie in modern times is the MS/Apple lie that computing can be made so simple that even the proverbial aunt Tillie can do it without reading any sort of manual.
It's amazing how many programs that most people would consider "core unix utilities" totally eschew the (alleged) unix philosophy of "do one thing well."
If your ~/.bashrc is a SYMLINK to a bash or sh script, bash will AUTOMATICALLY EXECUTE that script on login.
If you give rsync command a source or destination with an unescaped colon, it will read an ENVIRONMENT VARIABLE to figure out a command to run to AUTOMATICALLY CONNECT TO ARBITRARY NETWORK RESOURCES. If you have keys, it will even SKIP PASSWORD ENTRY, and with default Kerberos, it will not only skip password, but make a network connections to a login server:port specified by a DNS ENTRY.
Seriously, who is this guy, and why is this trainwreck #1 on HN?
Not the point. Of course it's not surprising that these utilities will execute scripts if you tell them to. The unexpected fact is that you can tell them to -- and that this is documented behavior which probably isn't going away.
If your argument was that no programmer should be surprised that you can tell an archive utility to execute an arbitrary script, then you and the author of the post are in complete agreement. The remaining difference is that the article actually does something to fix the problem while you merely hurl an implicit insult at anyone who hasn't seen this type of privilege escalation yet. One of these actions is more constructive than the other.
I'm not a security researcher. Care to recommend a more appropriate term for the data -> execution stage as opposed to the user -> root stage which is more commonly associated with the term "privilege escalation"?
I don't disagree, but, as a relative novice with shell scripts, I definitely did not realize so many tools could execute arbitrary code.
The parent post's anger and disgust is misplaced, though. This article is informative at a novice level, and well-written to that level. Not a trainwreck.
Because it is treating all of these intended side-effects of using a shell as though they are security vulnerabilities.
The problem is that there is a way for untrusted user input to ever touch a shell in the first place.
Seriously, I challenge you to find a language reference that doesn't decry the use of their version of system(3)---because all that does is run the given command under the user's shell.
Sure, fine, but why the anger? Why the 'trainwreck'? that's not constructive at all. The article definitely didn't claim these were security vulnerabilities - only that they were surprising. Some of these were surprising to me too. Am I an idiot for not knowing these? (no, I'm not, I'm just a novice).
It's really aggravating to learn something from an article that is making someone more knowledgeable this angry without explanation.
I think anyone who follows that method has no idea how things work. I was actually personally offended when Ximian started handing that out as a way to install Mono a decade+ ago, because it is absolutely the worst practice you can imagine: go pull [expective] from a URL, and throw it directly from the network into system(). I will "strong no" candidates who think it's a good idea, and I reject any PRs that do [expletive] like it.
All that said, between Gmail's spam filter, my avoidance of all things bitcoin, and common sense with passwords (don't ever re-use them), most of the damage caused by this doesn't affect me.
I will note, however, that this are why "when you hit return in the URL bar, what actually happens," is a valid interview question, in the same unfortunate sense that FizzBuzz is a valid interview question.
I think the point is that this is an entire class of vulnerability that most people may never have thought about, but could very easily result in some nasty remote code execution and/or privilege escalation via setuid.
Yes, that thing that is designed to execute commands could possibly result in commands being executed. Similarly, the intended use of a setuid binary is to escalate your privileges.
I'm asking you why you thought the knife would stop cutting things when it hit your hand instead of the loaf of bread.
This might be related to another article about OLE execution, to cast a shadow of doubt that it is not an isolated habit. Having outside stuff executed when not meaning to is always bad. I for one would be badly disappointed, if tar xvf unexpectedly run some code. Luckily, that is not the case.
UNIX got battle-hardened during its college years, the cases of unexpected execution are few and far between. One of them is post-install, never run dpkg -i unless you trust the packager.
> UNIX got battle-hardened during its college years
Is that when it finally gave up making shar archives?
For the unitiated: A shar is a "shell archive", or a shell script which (typically) makes heavy use of 'here documents' to do what tarballs do, only they're shell scripts so you have to execute them and then they can potentially execute arbitrary code unless you read through them very closely and actually understand them.
Yes, people actually made these. Yes, people actually ran these. Yes, they still exist on some old archive FTP servers and so on.
It's amazing how clever you can be when you don't think you'll ever have to care about security or The Sufficiently Stupid User (because sufficiently advanced stupidity is indistinguishable from malice).
Yes, that is one of the things that turned out to be a bad idea. That's why it was dropped.
Look, it's all about trust management. If you trust everyone's good will, like in an academic community, it's fine. If not, you need to manage trust. There are three models for it AFAIK:
initial trust, as in SSH; trust to the authorities, as in X.509; and the web of trust, as in PGP/GPG.
They all have their use cases. I like the opportunity to choose.
You really don't need the "./configure" there. make alone can obviously run arbitrary commands - but then again, so can the program whose source code you probably downloaded in order to run it.
In general, all the hype about not executing stuff from the web has a point but is largely confused about where the risks are and aren't (e.g. the "don't pipe wget into the shell" meme).
And even without any other source of trust, anyone who is willing to go through the automake/config hell, already scored some initial trust points. I rest my case.
It's been a while but I thought the real reason shars existed was because they were 7 bit clean, meaning they could be traded on usenet (or ftp in ascii mode) without needing any external program like uudecode…
> …only they're shell scripts so you have to execute them and then they can potentially execute arbitrary code unless you read through them very closely and actually understand them.
> Yes, people actually made these. Yes, people actually ran these.
Running something you downloaded is how every installer works. Self extracting zips are still a thing, too. At least with shars you could read the source.
Oh yeah, even today people still do `curl http://example.com | bash` (If someone were truly evil they'd make the first download from an IP clean and inject bad code into the second. That would catch all the people who `curl | less` first and then run it again piped to bash). :-)
All you needed to undo a shar (shell archive) was a fairly common Bourne shell. We had uuencode to make things 7-bit clean. Some programs to make shar files uuencoded the archived files, but some didn't.
"shar" files existed because "tar" wasn't particularly standardized. As late as 1990, SGI Irix "tar" did bytes in reverse order from SunOS "tar". You had to convert bytes to untar a SunOS archive on Irix.
> That would catch all the people who `curl | less` first and then run it again piped to bash
Are many people security-conscious enough to do the former but security-unconscious enough to do the latter? I would assume that one would do `curl http://example.com > evilscript; vim evilscript` and then `bash evilscript` if necessary.
Command execution is overrated. How about having tar download an arbitrary tar file over the network, from a server you control? http://bugs.debian.org/290435
What I find interesting is the thread title being a pun from a 40 year old movie. Back in the 70s, there wasn't any interest in movies, music, etc. from the 30s. And there still isn't interest in 30s culture, but plenty in the 70s.
I think you're in a bubble. Lots of people have interest in the 30s given it was the golden age of Hollywood: Gone with the Wind references have entered the cultural lexicon, so have The Wizard of Oz references.
Yeah but even then, you have The Three Stooges, The Marx Brothers, and Charlie Chaplin. All 30s-era comedy groups similar in notoriety to Monty Python.
In high school and college in the 70s, people did not go around quoting the Marx Bros. They were generally regarded as belonging to their grandparents' generation. It's just not like Python quotes today, which seem to be just as pervasive as in the 70s.
Can you even think of a MB quote without looking one up? If I made a pun on one, would you recognize it?
Yeah, like I said, I think you're living in a bubble and/or this is confirmation bias. I grew up in the 00s and, from my perspective, I see Monty Python as belonging to my grandparent's generation. No one in my age group commonly quotes Monty Python.
If people still do quote Monty Python, I think it's a culty minority or people who study media. The same status as the Marx Brothers and other comedians of bygone eras.
> Back in the 70s, there wasn't any interest in movies, music, etc. from the 30s.
I don't know, Hawkeye Pierce did a pretty good impression of Groucho Marx.
I think it's down to numbers: There are a Hell of a lot more people born who know about the 1970s alive now compared to people who knew about the 1930s alive in the 1970s. It was a Baby Boom, after all.
spanish inquisition was flying circus, not holy grail
but my theory is that the vcr, and now the internet, has a lot to do with it, just like you'd expect references to books to increase with the printing press and general increase of literacy
In one case, I could have used tcpdump to elevate privileges on a customer's router.
They had an x86 box running RHEL as their firewall/router and I was hired to resolve an (IPSec) issue they were having. I asked for a capture of some specific traffic but their I.T. guys (small company w/ only two technical staff) weren't "fluent" with bpf filters, so they created a user account for me, provided me with access via SSH, and granted me the ability to run tcpdump via sudo.
From the example given, I could have used the "-z" flag to run arbitrary commands and escalate to root (although, in this case, I likely could have gained root simply by asking nicely).
Sure: any attempt to build a "sandboxed" command line interface with a shell, or any web app that shells out to one of these commands and passes user input as an argument.
Probably strictfp's example above of allowing someone to run specific commands with sudo.
In the past there were also various implementations of a "restricted shell"; it's conceivable that some of these could bypass a restricted shell's restrictions, depending on how they were implemented.
Seriously, MS doesn't do everything great, but Powershell has typed pipes (typed everything, actually, it's not just stringly like *sh) which are seriously awesome.
I've used a "shell" that had a type system. Just before Control Data Corporation (CDC) dried up and blew away, they put out a mainframe OS called "NOS/VE". Yes, "VE", not "BE" - "NOS/BE" was a somewhat unrelated OS for CDC mainframes.
The NOS/VE shell had string types and integer types at least. The experience was absolutely horrible. It's hard for me to remember much other than the difficulty of getting anything practical to work, and that may be a consequence of CDC's incredibly poor design choices for the "shell" rather than the types. But I personally have never said "Oh, for a type system in this darn shell!" since then.
Well geez, it's almost like the tools were designed with flexibility and pluggability in mind before the advent of the internet and the fear of remote shell exploits...
I mean, is it unexpected if `./my_command --execute-this-right-now=somescript.sh` executes somescript.sh?