Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Sep 2014 02:24:14 +0400
From: Solar Designer <>
Subject: Re: CVE-2014-6271: remote code execution through bash

On Wed, Sep 24, 2014 at 06:08:21PM -0400, Jason Cooper wrote:
> I wrote some code a while ago to automate git push via single-purpose
> ssh keys. [1]  By design, it wipes the environment, sets vars found in
> the config, and accepts only configured commands for
> SSH_ORIGINAL_COMMAND.  I've tested the latest HEAD against this attack,
> and it appears to mitigate it:
> [jason@...alhost] $ ssh -i .ssh/test_key -o 'rsaauthentication yes' 0 '() { ignored; }; /usr/bin/id'
> uid=1000(jason) gid=1000(jason) groups=1000(jason)
> [jason@...alhost] $ # add 'command=/path/to/secsh -f /path/to/test.rc' in .ssh/authorized_keys on server
> [jason@...alhost] $ ssh -i .ssh/test_key -o 'rsaauthentication yes' 0 '() { ignored; }; /usr/bin/id'
> secsh v0.8-rc1-2-ga86f09832fa2: access denied.

This is puzzling.  I tried:

command="/bin/env - date"


command="exec /bin/env - date"

and neither prevents exploitation of the issue as above (I get the
output of "id", not of "date"), which is not surprising given that the
command is run via the shell before it reaches "env".

Maybe your target user account's login shell is not bash?  That would
explain it, but it's also the easier case where the issue had been
exposed via a subshell only (does your test.rc explicitly use bash?)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.