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

A proof-of-concept of a vulnerability in custom shell prompt scripts

github.com

Post reply on HN
Print view View original

21–30 of 54 posts

Re: A proof-of-concept of a vulnerability in custom shell prompt scripts

#21

Post by mikeash »

eridius wrote: post #11
chadgeidel wrote: post #9

Forgive me if I'm misunderstanding the vulnerability, but isn't this one of Raymond Chen's "It rather involved being on the other side of this airtight hatchway" exploits? That is, any commands you run has the same permissions as you have. Now, I understand that you may not intimately understand 100% the code of the commands and shell extensions you use, but is that a "vulnerability"?

Cloning a repository and cd'ing into it should always be safe, no matter what that repository is. This vulnerability makes it not safe.

It wouldn't even require an explicit clone. An attacker could send you a zip file containing a malicious .git directory, and then you'd lose the moment you cd'd into the unzipped directory to check it out.

Re: A proof-of-concept of a vulnerability in custom shell prompt scripts

#22

Post by geofft »

chadgeidel wrote: post #9

Forgive me if I'm misunderstanding the vulnerability, but isn't this one of Raymond Chen's "It rather involved being on the other side of this airtight hatchway" exploits? That is, any commands you run has the same permissions as you have. Now, I understand that you may not intimately understand 100% the code of the commands and shell extensions you use, but is that a "vulnerability"?

The privilege escalation is from "can push code to a repository that you pull from" to "can run code as you". The idea is that you trust the shell extension you're using, but a particular git repo exploits a vulnerability in that shell extension.

git cloning code vs. running code is sometimes a security boundary and sometimes not. For instance, if you go cd into that directory and then run make or ./configure or ./setup.py install or docker run or something, then yeah, you've removed that boundary. But in general, it's reasonable to keep the boundary there. Perhaps you're doing code review of code by an untrusted author, either of someone else's project or of a pull request to your own project. Perhaps you're packaging up the software to run it as a less-privileged account. Perhaps you're a sysadmin helping a user figure something out. And so forth.

Re: A proof-of-concept of a vulnerability in custom shell prompt scripts

#23

Post by caf »

Ajedi32 wrote: post #12
chadgeidel wrote: post #9

Forgive me if I'm misunderstanding the vulnerability, but isn't this one of Raymond Chen's "It rather involved being on the other side of this airtight hatchway" exploits? That is, any commands you run has the same permissions as you have. Now, I understand that you may not intimately understand 100% the code of the commands and shell extensions you use, but is that a "vulnerability"?

If allows an attacker to execute arbitrary code in a situation where you wouldn't expect that (such as merely CDing to an attacker-controlled directory), then yeah of course it's a vulnerability.

Yes, this is more like the "a PDF that runs arbitrary commands when you open it" class.

Re: A proof-of-concept of a vulnerability in custom shell prompt scripts

#25

Post by Ajedi32 »

ejcx wrote: post #2

Dang. Unfortunately I am not vulnerable, and I use default ohmyzsh. This is a neat bug, though. Lots of package managers have similar problems, and I would not be surprised if there's a lot of git/shell/environment problems left to find.

Why is it unfortunate that you're not vulnerable? Isn't that a good thing?

Re: A proof-of-concept of a vulnerability in custom shell prompt scripts

#26

Post by abbeyj »

Tab autocompletion looks to be affected too, at least on my system. Create a branch called 'complete_$(./foo)'. Then type 'git checkout comp'. This gets autocompleted to

    git checkout complete_$(./foo)
If you hit Enter at this point without thinking you'll end up running './foo'. It should have expanded instead to something like

    git checkout 'complete_$(./foo)'
or

    git checkout complete_\$\(./foo\)

Re: A proof-of-concept of a vulnerability in custom shell prompt scripts

#29

Post by chadgeidel »

geofft wrote: post #22
chadgeidel wrote: post #9

Forgive me if I'm misunderstanding the vulnerability, but isn't this one of Raymond Chen's "It rather involved being on the other side of this airtight hatchway" exploits? That is, any commands you run has the same permissions as you have. Now, I understand that you may not intimately understand 100% the code of the commands and shell extensions you use, but is that a "vulnerability"?

The privilege escalation is from "can push code to a repository that you pull from" to "can run code as you". The idea is that you trust the shell extension you're using, but a particular git repo exploits a vulnerability in that shell extension. git cloning code vs. running code is sometimes a security boundary and sometimes not. For instance, if you go cd into that directory and then run make or ./configure or ./se…

Thanks for the explanation.

Re: A proof-of-concept of a vulnerability in custom shell prompt scripts

#30

Post by caust1c »

ejcx wrote: post #2

Dang. Unfortunately I am not vulnerable, and I use default ohmyzsh. This is a neat bug, though. Lots of package managers have similar problems, and I would not be surprised if there's a lot of git/shell/environment problems left to find.

Oh god why. Use https://github.com/sorin-ionescu/prezto
Post reply on HN