[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140925165922.GX23926@titan.lakedaemon.net>
Date: Thu, 25 Sep 2014 12:59:22 -0400
From: Jason Cooper <osssecurity@...edaemon.net>
To: oss-security@...ts.openwall.com
Cc: chet.ramey@...e.edu
Subject: Re: CVE-2014-6271: remote code execution through
bash
On Thu, Sep 25, 2014 at 02:24:14AM +0400, Solar Designer wrote:
> 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"
>
> and:
>
> 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?)
Nope, login shell is /bin/bash. Please look at the code in
http://git.infradead.org/users/jcooper/secsh.git/blob/HEAD:/match.c
line 70. match_cmd() compares the contents of $SSH_ORIGINAL_COMMAND to
the configured list of acceptable commands. It returns the array index
only if there is an exact match. Then, in secsh.c, we execute the
command from the array of allowed commands. The buffer holding
$SSH_ORIGINAL_COMMAND is never trusted, nor executed.
There is no shell, bash or otherwise, called ever.
While tinkering with this, I discovered that if you force ssh to provide
a pty (ssh -t ...), even with secsh locked down, the hack works. You
*must* set 'no-pty' after 'command=' in your authorized_keys file to
prevent ssh from launching a shell. :-/
thx,
Jason.
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.
