Hacker News new | ask | show | jobs
by jcape 4003 days ago
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?

3 comments

Did this article make you angry? Why do you call it a trainwreck?
The article is literally "If you tell these utilities to execute this script, they'll execute this script". NONE of these should be "unexpected".
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.

> you merely hurl an implicit insult at anyone who hasn't seen this type of privilege escalation yet

You and I have vastly different opinions on what constitutes privilege escalation.

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.

So what is your opinion of this method of install? http://brew.sh/
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.