Hacker News Reader

Comment by chaosfactor | Hacker News Reader

Calling into sed when you use ssh increases your attack surface to include sed's attack surface. And likely more.

I don't believe you understand how sed is being used here. The sed process doesn't even survive until the beginning of the connection.

It doesn't survive to the beginning of the second connection, but do be aware that nc/echo/sed are all run on bastion. You'd have to rearrange the quoting a bit to get sed locally.

If you're being paranoid, you can also break this like: ssh -v 'foo;bar.bast'

Still, the only way I see this being any kind of "attack surface" is if an attacker could control the hostname you're connecting to, and I'll bet there are much naughtier thing possible in that case.

Does the ProxyCommand directive run the rc scripts of the bastion account? If so, control over the box isn't needed, just control over the bastion user account. Setting a custom $PATH and providing a custom sed, or a custom echo for that matter, would be easier then. Absolute paths are important for this reason. This is exactly why ./ isn't in $PATH (like in DOS/Windows), so someone can't drop a commonly named executable somewhere that accidentally gets run.

Depends on your shell, but you can try this yourself -- for instance:

    $ ssh localhost -o ProxyCommand="ssh localhost 'pstree -a \$PPID >&2 ; nc %h %p'"
    sshd 
      `-bash -c pstree -a $PPID >&2 ; nc localhost 22
          `-pstree -a 6703

Bash invoked this way will be non-interactive. Often bashrc will test "$PS1" to bail early in this case, but the point remains that it does run. I also tried my command with echos before and after that test in my bashrc to confirm what happens.

sed only sees data from the user, so the only person in a position to leverage that attack surface is the user himself.

It will never touch any part of the network, or handle any untrusted input. So this is not a concern.

Reply on news.ycombinator.com