[Linux-aus] What's the real story about Shellshock and Bash and vulnerabilities in Linux and OpenSource?

[James Polley]

On Fri, Sep 26, 2014 at 1:20 PM, Russell Coker <russell at coker.com.au> wrote:

> On Fri, 26 Sep 2014, Ian <ilox11 at gmail.com> wrote:
> > The journos are having a field day over the discovery of the
> > vulnerabilities in Bash, the vulnerability now called Shellshock. They
> talk
> > of 500million affected sites. Any Apache server is easily taken over.
> Some
> > reporting that the patches not fully safe yet.
>
> wget -U "() { test;};/usr/bin/touch /tmp/VULNERABLE" \
> http://www.example.com/cgi-bin/whatever
>
> Above is a test for a vulnerable cgi-bin script courtesy of
> https://twitter.com/hernano .
>
> ssh root at localhost "() { :;} ; touch /tmp/ohno"
>
> Above is a test I wrote for ssh where ~root/.ssh/authorized_keys allows
> access
> but with the "command=" option (which sets the original command to the
> SSH_ORIGINAL_COMMAND variable).  Note that this doesn't do anything useful
> in
> the case where unrestricted ssh access is granted.
>
> If you have bash cgi-bin scripts then an attacker can run arbitrary code as
> www-data.


*nit-pick* The CGI scripts don't have to be written in bash; anything that
invokes bash is vulnerable.

The RedHat blog post (
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/)
 lists a few routes to this: CGI scripts written in C which call system()
or popen(), os.system() or os.popen() in Python, system() or exec() in PHP,
and open() or system() in Perl (the PHP and Perl examples have other
caveats as those languages don't always call bash)

So it's quite possible that you have a CGI script written in C that uses
system() to call curl, or a Perl script that invokes ImageMagick

It's not just Apache and SSH that are potential vectors: anything that
listens on the network could be a vector, if it invokes bash and passes
data into the environment. SSH and Apache were obvious problems and found
quickly, but Robert Graham's post about this also warns that he's found
vulnerable DHCP clients (
https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/
shows one example of a DHCP client executing arbitrary code supplied by the
DHCP server)


  As long as you don't run such scripts as root that isn't
> necessarily a huge problem (depending on what your scripts do and how
> important the web server is to you).  For example if you have a web server
> that mostly serves static data and doesn't have write access to that data
> then
> the ability of an attacker to mess with you will be limited.
>
> If you use ssh as a sudo replacement for root access then you have a more
> serious problem.
>
> If you have a cgi-bin script written in bash that then runs a program as
> root
> via the ssh command= option then it's a remote root exploit.
>
> > Should there be a focus within the Linux world to track down all the
> little
> > bits that make up the foundation of the software and making sure they are
> > being maintained and secure and above all trusted? Perhaps LA or the next
> > LCA could/should pick this up as a theme and be a leader in the open
> source
> > world?
>
> Yes.  Also we should make all things be secure by default.  If we don't
> have
> daemons running scripts in a default configuration then as most users
> stick to
> the defaults for most things that will make most systems secure.
>
> Finally running things with minimum privileges is a good thing.  SE Linux
> is
> good for this.
>
> --
> My Main Blog         http://etbe.coker.com.au/
> My Documents Blog    http://doc.coker.com.au/
>
> _______________________________________________
> linux-aus mailing list
> linux-aus at lists.linux.org.au
> http://lists.linux.org.au/listinfo/linux-aus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux.org.au/pipermail/linux-aus/attachments/20140926/37595cb5/attachment.htm