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

41–50 of 54 posts

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

#41

Post by junkblocker »

oconnor663 wrote: post #38
abbeyj wrote: post #26

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\)

Zsh seems to do the escaping correctly there.

Confirming what GP said on version 5.3.1, not seeing any escaping

    git checkout 
    git checkout $(./pwd)

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

#43

Post by simlevesque »

lillesvin wrote: post #18

Cute idea. I'm willing to bet that the Bash script I wrote for some of my co-workers is vulnerable. I guess that's something I should find out ... by making their computers do stuff. However, I currently use Fish shell myself and it seems to be safe: http://imgur.com/a/rjocA

Maybe someone could craft a similar vulnerability for Fish.

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

#44

Post by caust1c »

vortico wrote: post #34
caust1c wrote: post #30

Earlier quoted context omitted.

Oh god why. Use https://github.com/sorin-ionescu/prezto

Are you not going to give a reason?

Yeah I guess it was presented without a reason.

Code quality is pretty much the reason though. The oh-my-zsh maintainer himself even wrote a post once upon a time about how not to run an OSS project.

Prezto forked the project and cleaned up everything quite nicely a long time ago.

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

#45

Post by gutnor »

eridius wrote: post #10

Confirmed that the official git prompt for Fish is not vulnerable.

edit: nevermind - pbkac, does not appear to be vulnerable !

Did you try creating a branch called "(./pw3n)" ?

I'm running fish with git-radar. I'm not vulnerable to that specific attack but to a similar one with the branch name (./pw3n)

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

#46

Post by junkblocker »

Since branch name parsing is done by a lot of scripts, and I can't control the default branch name, I've installed this global post-checkout hook for now until I can stop panicking and think clearly.

    #!/bin/sh
    prev_head=$1
    new_head=$2
    changing_branch=$3

    REPO_DIR="$(git rev-parse --show-toplevel 2>/dev/null)"

    if [ "$changing_branch" = 1 -a "$prev_head" = "0000000000000000000000000000000000000000" ]; then
        new_head_name="$(git name-rev --name-only "$new_head"|sed -e 's|`|_|g' -e 's|$(|_|g')"
        new_head_name_untaint="$(git name-rev --name-only "$new_head"|sed -e 's|`|x|g' -e 's|$(|x|g')"
        if [ "$new_head_name" != "$new_head_name_untaint" ]; then
            echo "
    DANGER! INSECURE BRANCH NAME.
    ">&2
            git name-rev --name-only "$new_head"

            echo "
    MOVING $REPO_DIR TO TRASH.
    ">&2
            mkdir -p ~/.Trash
            mv "$REPO_DIR" "$HOME/.Trash/${REPO_DIR##*/}.$(date +"%Y%m%d%H%M%S")"
        fi
    fi

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

#47

Post by gepoch »

caust1c wrote: post #44
vortico wrote: post #34

Earlier quoted context omitted.

Are you not going to give a reason?

Yeah I guess it was presented without a reason. Code quality is pretty much the reason though. The oh-my-zsh maintainer himself even wrote a post once upon a time about how not to run an OSS project. Prezto forked the project and cleaned up everything quite nicely a long time ago.

lol I'm using prezto, and I was pwn'd! Looks like OMZ is doing things nicely where prezto fails :)

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

#48

Post by [deleted] »

caust1c wrote: post #44
vortico wrote: post #34

Earlier quoted context omitted.

Are you not going to give a reason?

Yeah I guess it was presented without a reason. Code quality is pretty much the reason though. The oh-my-zsh maintainer himself even wrote a post once upon a time about how not to run an OSS project. Prezto forked the project and cleaned up everything quite nicely a long time ago.

[deleted]

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

#49

Post by goodplay »

koolba wrote: post #40

It's always cute to find new vectors for command injection. Really anytime you mix data and commands this type of crap is bound to happen (ex: sql injection). Still not as worrisome to me as the full scripts that get executed by package managers when you install dependencies. Effectively every time you run something like "npm install" you're putting your faith in the entire tree of ancestor dependencies as any of the…

More often than not, building and deploying is secondary for developers to writing the library itself, if that. Build scripts and installation don't get the same treatment and care the library does.

The is one of the primary reasons why I prefer distribution-packaged libraries to pulling a library and its dependencies directly from developers. Staleness is a small price to pay relative to having at least two sets of eyes glance over the source and not execute arbitrary build scripts on my system.

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

#50

Post by simplehuman »

junkblocker wrote: post #41
oconnor663 wrote: post #38

Earlier quoted context omitted.

Zsh seems to do the escaping correctly there.

Confirming what GP said on version 5.3.1, not seeing any escaping git checkout git checkout $(./pwd)

I can confirm as well
Post reply on HN