(Sorry long post. :-)
Hmmm,
You're not wrong, but polluting the environment before the webserver
starts or after it's running is a different proposition from injecting
into the environment in a single pass with predictable results. What
makes the cgi vs shellshock exploit viable is that that cgi module sets
a chunk of the environment from the get/post request.
A quick reasoning:
php code, run on debian/apache/php, called from my desktop with chrome:
<? system("bash -c set"); ?>
gives the following:
-------------
APACHE_LOCK_DIR=/var/lock/apache2 APACHE_LOG_DIR=/var/log/apache2
APACHE_PID_FILE=/var/run/apache2.pid APACHE_RUN_DIR=/var/run/apache2
APACHE_RUN_GROUP=www-data APACHE_RUN_USER=www-data BASH=/bin/bash
BASHOPTS=cmdhist:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
BASH_ALIASES=() BASH_ARGC=() BASH_ARGV=() BASH_CMDS=()
BASH_EXECUTION_STRING=set BASH_LINENO=() BASH_SOURCE=()
BASH_VERSINFO=([0]="4" [1]="2" [2]="37" [3]="1" [4]="release"
[5]="i486-pc-linux-gnu") BASH_VERSION='4.2.37(1)-release' DIRSTACK=()
EUID=33 GROUPS=() HOSTNAME=localweb HOSTTYPE=i486 IFS=$' \t\n' LANG=C
MACHTYPE=i486-pc-linux-gnu OPTERR=1 OPTIND=1 OSTYPE=linux-gnu
PATH=/usr/local/bin:/usr/bin:/bin PPID=3179 PS4='+ ' PWD=/data/www
SHELL=/bin/sh SHELLOPTS=braceexpand:hashall:interactive-comments SHLVL=1
TERM=dumb UID=33 _=/bin/bash
-------------
But if we run:
#!/bin/bash
echo "Content-type: text/html"
echo
set
using the cgi module on the same box we get:
--------------
BASH=/bin/bash
BASHOPTS=cmdhist:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
BASH_ALIASES=() BASH_ARGC=() BASH_ARGV=() BASH_CMDS=()
BASH_LINENO=([0]="0") BASH_SOURCE=([0]="/usr/lib/cgi-bin/test.sh")
BASH_VERSINFO=([0]="4" [1]="2" [2]="37" [3]="1" [4]="release"
[5]="i486-pc-linux-gnu") BASH_VERSION='4.2.37(1)-release' DIRSTACK=()
DOCUMENT_ROOT=/data/www/abh.tips EUID=33 GATEWAY_INTERFACE=CGI/1.1
GROUPS=() HOSTNAME=localweb HOSTTYPE=i486
HTTP_ACCEPT='text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8'
HTTP_ACCEPT_ENCODING=gzip,deflate,sdch
HTTP_ACCEPT_LANGUAGE='en-GB,en;q=0.8,en-US;q=0.6,da;q=0.4,th;q=0.2,es;q=0.2'
HTTP_CONNECTION=keep-alive
HTTP_COOKIE=ci_session=a%3A5%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%22356aa658fa2fdd81040e78f71578c9a9%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A10%3A%2210.86.1.20%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A105%3A%22Mozilla%2F5.0+%28X11%3B+Linux+x86_64%29+AppleWebKit%2F537.36+%28KHTML%2C+like+Gecko%29+Chrome%2F37.0.2062.120+Safari%2F537.36%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1411707427%3Bs%3A9%3A%22user_data%22%3Bs%3A0%3A%22%22%3B%7D32a5dc82bfef3aa2e944df2d060e56e7
HTTP_HOST=10.86.1.114 HTTP_USER_AGENT='Mozilla/5.0 (X11; Linux x86_64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120
Safari/537.36' IFS=$' \t\n' MACHTYPE=i486-pc-linux-gnu OPTERR=1 OPTIND=1
OSTYPE=linux-gnu PATH=/usr/local/bin:/usr/bin:/bin PIPESTATUS=([0]="0")
PPID=2104 PS4='+ ' PWD=/usr/lib/cgi-bin QUERY_STRING=
REMOTE_ADDR=10.86.1.20 REMOTE_PORT=35052 REQUEST_METHOD=GET
REQUEST_URI=/cgi-bin/test.sh SCRIPT_FILENAME=/usr/lib/cgi-bin/test.sh
SCRIPT_NAME=/cgi-bin/test.sh SERVER_ADDR=10.86.1.114
SERVER_ADMIN=webmaster@localhost SERVER_NAME=10.86.1.114 SERVER_PORT=80
SERVER_PROTOCOL=HTTP/1.1 SERVER_SIGNATURE=$'
Apache/2.2.22 (Debian) Server at 10.86.1.114 Port 80
\n' SERVER_SOFTWARE='Apache/2.2.22 (Debian)' SHELL=/bin/sh
SHELLOPTS=braceexpand:hashall:interactive-comments SHLVL=1 TERM=dumb
UID=33 _=echo
------------
Now we have the inclusion of all the direct-from-web stuff... including
my agent string for chrome on Linux.
So you replace the agent string with a valid bash function and when the
CGI call passes to bash with that in the environment it executes.
Directly injected from the web.
While it's possible to do a proof of concept by creating the environment
prior to starting apache or before the system() call in PHP (Same goes
for perl etc) that would require exploited/malicious code on the server
to achieve the desired result. If you've already got access to the box
to put the malicious code there so there's no point in using a bash
environment exploit as a secondary vector. You'd be running a discovery
script/toolkit on the box and deciding if you'll harvest or farm, then
getting out of there.
Piddling about with secondary exploits is possible, but in 99.99% of
cases is not going to happen. It leaves artifacts that will reduce the
amount of time the attacker has have to play after a script/bot has
found the targets for them.
Me thinks you need to think like a hacker, of the nefarious kind, rather
than a hacker of the developer kind to see my point of view though. :-)
Cheers, Chris H.
On 26/09/14 16:06, Kent Fredric wrote:
On 26 September 2014 12:06, Chris Hellyar <[email protected]
<mailto:[email protected]>> wrote:
While I don't disagree with the statement that any execution
environment can be used to get the result from the flawed version
of bash, the remote exploit is via apache/cgi at this stage and
exploiting it via php/pearl/python would be of little value to
attacker as it would be a low value secondary vector.
As long as any of those calls 'system()' and system is implemented in
terms of 'sh -c' and 'sh' is a symlink to bash, ( a very common
arrangement ), env based exploits will still work here as soon as a
bash instance is fired.
Because ENV is implicitly inherited by those languages, and passed on
to their children during fork+exec , ENV becomes an open conduit for
malicious code and the intermediate languages of any kind simply work
as naive carriers unless they explicitly filter out ENV they inherit.
So all you need is a top level somewhere that stores user specified
values in any ENV field.
And that may not even require CGI binaries in some cases, but it is
the most likely way you'll see it.
( ie: Hypothetically, if Apache simply inflated arbitrary ENV keys
from HTTP requests within the Apache process itself, and then
subsequently called bash inside the same process for any reason in
such a way those ENV was inherited, your pooch is screwed )
And worse, this can all take place *prior* to authentication taking
place, as authentication may requires the authentication tokens to be
passed via ENV.
SSH is a harder target because the vulnerability doesn't trigger until
the channel is activated and authorised and then the ENV leaks over
the connection once established.
There may be some hype to this, but given we don't know a lot about
the reality of this problem, considering we just discovered it after
it being out there for well over 20 years, I think its better to err
on the side of caution and assume vulnerability until some kind of
confidence is offered to the contrary.
( You can never prove something invulnerable, and you cant ever make
anything completely invulnerable )
--
Kent*
*
*KENTNL* - https://metacpan.org/author/KENTNL
_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
