Re: [Discuss] Shellshock
Also... Repository of "Shellshock" Proof of Concept Code https://github.com/mubix/shellshocker-pocs -Tom -- Tom Metro The Perl Shop, Newton, MA, USA "Predictable On-demand Perl Consulting." http://www.theperlshop.com/ ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Shellshock
I take exception to the Lisp.org quote.
Yes, it's a fair point that Gnu project is older than either Apache or
Linux, but that doesn't exempt Bash from criticism. (And if this bug
is only 20 years old as claimed, being when ENV function overrides
were invented, it's maybe a year older than Apache.)
Alas there is both a mis-guided feature and at least one bug in the
feature (even assuming its intent ever made any sense) -- as well as
the environmental / combination problems.
[ The misbegotten feature is useful for Code Injection for callbacks /
genericization. It's great for a major programming language/framework
but not for security-critical components. Code Injection should cross
security boundaries only with the utmost care if at all. ]
Code fuzzed on the ENV value *after* the function definition should
not have been accepted at all. Executing it at function def time is a
bug.
Crucially, they never should have linked /bin/sh=>bash .
That was lazy, they didn't want to maintain legacy shell and the new bash.
It presumed it would always be sufficiently backward compatible.
Exposed as false.
Code injection in a critical gut component like /bin/sh ...
implemented with a link. Oops !
It was NEVER safe either. even without Apache. Any Setuid binary
that used system() might pass ENV to BASH even though it was coded
initially on pre-BASH POSIX UNIX. Whether env 'ls="(){exploit}'
rootprogram is considered a misfeature or bug, it's a capability that
has no place in critical infrastructure like /bin/sh. Never. Disaster
was lurking even then, probably was used.
(That SETUID binaries really never should have used system() with a
purged $PATH instead of using explicit trusted pathname and discrete
arg list on execX() is tangential. It's so convenient you can't keep
folks from doing it. :-( That means /bin/sh has to be simple enough
to be trusted -- as it once was. Not some feature rich bloat.)
Debian+Ubuntu since 2009 are mostly immune since /bin/sh was switched
to lighter weight /bin/dash then. Dash is like old SH but less ugly?
(They're still exposed via DHCP but AFAIK that's a LAN-or-Mouse attack
not something that can traverse firewalls like :80.)
Most of the embedded devices mentioned in Chicken-Little reports
*pretend* to have 'bash' but really link both /bin/sh and /bin/bash to
busybox, to which all the 'external' commands also link. Safe,
different code base.
Note that Multiple additional BASH security bugs have been found
and/or fixed since they started looking harder in the last week.
Keep patching.
( And check if you've got mystery back doors loaded in the intervening
week, if you have exposed ports. )
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Shellshock
Bill Ricker writes: > Code fuzzed on the ENV value *after* the function definition should > not have been accepted at all. Executing it at function def time is a > bug. What troubles me most about this is how the bit of code that reads in environment variables sends the function body string into the top of the general purpose parser. I.e. the start symbol is not function_body but the start symbol for the whole shell language. I don't know yacc/bison very well. Is there no easy way to call into the generated parser asking for a different start symbol, something lower down in the grammar? Or else to share code between two generated parsers? This seems the fundamental issue to me. That and the fact that what's called is "parse_and_execute" not "parse_and_collect_parse_tree" or whatever. The patches workaround this from outside, which is fine for fixing in a hurry, but what's the long term fix? How it is now looks really messy and hackish IMO. And the amount of C string manipulation in that latest function name prefix/suffix protection patch makes me nervous. But I'm not a regular C programmer, so maybe that's par for the course for such things. -- Mike Small sma...@panix.com ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Shellshock
On 9/30/2014 10:59 PM, Bill Ricker wrote: >Code injection in a critical gut component like /bin/sh ... > implemented with a link. Oops ! And Lennart wonders why some of us hate his code. > Note that Multiple additional BASH security bugs have been found > and/or fixed since they started looking harder in the last week. Which is not a bad thing as long as the people looking actually understand what they are looking at and what they are looking for. It's not so much the quantity of eyes as the quality of those eyes. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Shellshock
On Wed, Oct 1, 2014 at 11:07 AM, Richard Pieri wrote: >> Note that Multiple additional BASH security bugs have been found >> and/or fixed since they started looking harder in the last week. > Which is not a bad thing as long as the people looking actually > understand what they are looking at and what they are looking for. It's > not so much the quantity of eyes as the quality of those eyes. Yes indeed. Unskeptical eyes are useless for security review no matter how multiplied. Open source doesn't guarantee unskeptical eyes early/often, but it's possible, unlike commercial closed source where it's forbidden (except when actively required by Military contract). -- Bill Ricker bill.n1...@gmail.com https://www.linkedin.com/in/n1vux ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Shellshock
On 10/1/2014 12:34 PM, Bill Ricker wrote: > Yes indeed. Unskeptical eyes are useless for security review no matter > how multiplied. As an aside, this is why I trust self-encrypting disk firmware. Rather, it's better to say that I don't trust it any more or less than I trust software like TrueCrypt and Bitlocker that I don't understand either. > Open source doesn't guarantee unskeptical eyes early/often, but it's > possible, unlike commercial closed source where it's forbidden (except > when actively required by Military contract). That's not true. Having skeptical eyes is not forbidden. Whether or not those eyes can do anything about what they see is a different issue, one that can usually be traced back to whoever holds the purse. But then, money or lack thereof is one of the things that ails many high profile open source projects, too. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Shellshock
Bill Ricker wrote: > Yes, it's a fair point that Gnu project is older than either Apache or > Linux, but that doesn't exempt Bash from criticism. > > Alas there is both a mis-guided feature and at least one bug in the > feature (even assuming its intent ever made any sense) -- as well as > the environmental / combination problems. The age thing is a bit of a red herring, and that this came about due to a bug in Bash is almost irrelevant. The responsibility lies squarely with the application that provides the network interface. It should not be handing off unsanitized data supplied by a client to a child process. Of course it's not that simple. We have plenty of infrastructure that depends on doing exactly that. Take CGI for example, where form data is piped to a child process (in addition to setting a bunch of environment variables). But in the case of CGI you are just moving the network/local barrier a bit further down the stack. The CGI code is written with the expectation that the inputs are tainted. But still, there should have been a bit more deliberate effort put into creating a sandboxed environment for running child processes, with very controlled paths of communication between the network and the child process. > It was NEVER safe either. even without Apache. Any Setuid binary > that used system() might pass ENV to BASH... Yes, agreed, which is why I said "almost irrelevant" above, as Bash still had a problem that shouldn't have been there. -Tom -- Tom Metro The Perl Shop, Newton, MA, USA "Predictable On-demand Perl Consulting." http://www.theperlshop.com/ ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Shellshock
On Wed, Oct 1, 2014 at 4:59 PM, Tom Metro wrote: > But in the case of CGI you are just moving the network/local > barrier a bit further down the stack. and moved it right through system() => /bin/sh => /bin/bash by alias which last wasn't designed to be network secure. > The CGI code is written with the > expectation that the inputs are tainted. alas, that paranoia (even if correctly implemented, which even Perl Taint doesn't guarantee, only that something is tried) is only *after* system() gives unclean ENV to bash to pass to Perl. [ Efficient CGI implementations using pool processes and RPC for non-spawning CGI emulation avoid *this* problem, plenty of other room for trouble. ] -- Bill Ricker bill.n1...@gmail.com https://www.linkedin.com/in/n1vux ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Shellshock
On Wed, Oct 1, 2014 at 4:59 PM, Tom Metro wrote: > > The age thing is a bit of a red herring, and that this came about due to > a bug in Bash is almost irrelevant. The responsibility lies squarely > with the application that provides the network interface. It should not > be handing off unsanitized data supplied by a client to a child process. > It also that shellshock would not apply to scripts in one language that use a subprocess for some functionality like a script in python or ruby that uses results from a perl or even a bash script, as long as any data that is passed went thorough normal sanitation measures. But there are serious problems with mod_cgi This article by trend micro makes it clear that data sanitization is useless if mod_cgi is enabled for Apache. It uses bash and environment variables to execute your app in the first place so any sanitization code in the script is useless. http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-shellshock.pdf Question: who uses mod_cgi in production??? I'm a web developer and have yet to come across it. This definitely does not apply to nginx+uwsgi or mod_wsgi for example. I'm looking around to see if it's enabled by default. This might be distro specific but the other good news is that there are updates to bash listed in the trend article above that fix the problem. Cheers + + + + + + + John ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Shellshock
Seems to me that changing the /bin/sh symlink to point to dash instead of bash should ameliorate the problem, at least where scripts that invoke /bin/sh don't depend on bash features. Of course, finding all such sloppily-written scripts on an existing server could be a big chore. Once found, they can at least be normalized by adding "#! /bin/bash" so they continue to function the way they already were before changing the symlink to point to dash. On Wed, Oct 1, 2014 at 5:33 PM, Bill Ricker wrote: > On Wed, Oct 1, 2014 at 4:59 PM, Tom Metro wrote: > > But in the case of CGI you are just moving the network/local > > barrier a bit further down the stack. > > and moved it right through system() => /bin/sh => /bin/bash by alias > which last wasn't designed to be network secure. > > > The CGI code is written with the > > expectation that the inputs are tainted. > > alas, that paranoia (even if correctly implemented, which even Perl > Taint doesn't guarantee, only that something is tried) is only *after* > system() gives unclean ENV to bash to pass to Perl. > > [ Efficient CGI implementations using pool processes and RPC for > non-spawning CGI emulation avoid *this* problem, plenty of other room > for trouble. ] > > -- > Bill Ricker > bill.n1...@gmail.com > https://www.linkedin.com/in/n1vux > ___ > Discuss mailing list > Discuss@blu.org > http://lists.blu.org/mailman/listinfo/discuss > -- John Abreau / Executive Director, Boston Linux & Unix Email j...@blu.org / WWW http://www.abreau.net / PGP-Key-ID 0x920063C6 PGP-Key-Fingerprint A5AD 6BE1 FEFE 8E4F 5C23 C2D0 E885 E17C 9200 63C6 ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Shellshock
On Wed, Oct 1, 2014 at 5:34 PM, John Hall wrote:
> It also that shellshock would not apply to scripts in one language that
> use a subprocess for some functionality like a script in python or ruby
> that uses results from a perl or even a bash script, as long as any data
> that is passed went thorough normal sanitation measures.
That depends how the call to the second script is made. If as usual it
is by system() with single arg, or `` rather than by fork/exec(),
system(3) will still call /bin/sh to find program on $PATH and parse
ARGS. That gives /bin/bash first exposure to all ENV before the
child gets to sanitize, on those systems where the ongoing error of
linking simple legacy POSIX /bin/sh to huge Gnu /bin/bash is in force
(ash, actual classic sh, dash, busybox as sh are all fine *this
time*).
Only if the spawn uses the LIST form of exec() or system() with a
hard pathname for the subscript -- not the `backtick` form !! --
/bin/sh is avoided and this vulnerability avoided on interlanguage
subscripting.
HOWEVER, proper untainting doesn't make a BASH subscript safe from the
original ShellScript bug due to the
env funcname='(){body;}' script args
feature to override functions in ENV. This is designed for code
injection callbacks, but also serves as exploitable code injunction
via
env funcname='(){body;} erroneous syntax exploit code executed
early;' script args
The "erroneous syntax exploit code executed early" will execute
*before* your script, during parser time, unless you have the BASH
patches.
This affects dhcp-client on debian (where system(3) uses sh=>dash)
because dhcp-client is #! /bin/bash; but threat requires attacker can
has a dhcp-server on your lan via some other exploit, isn't coming in
the NAT/firewall into your public HTTPD like mod_cli.
> But there are serious problems with mod_cgi
YES, because it uses system(3) as above (and defers newtork data
sanitization to child).
But any program doing likewise ... there are many ... is equally at risk.
> This article by trend micro makes it clear that data sanitization is
> useless if mod_cgi is enabled for Apache. It uses bash and environment
> variables to execute your app in the first place so any sanitization code
> in the script is useless.
Exactly.
> Question: who uses mod_cgi in production???
Many websites *started* that way, even in public Beta.
Most switched when volume hit (if they didn't wither for lack of
volume), as spawning a process per request is not scalable ... and
it's the system(3) spawn that is both slow-non-scalable *and* unsafe
passing of network data through BASH !
I had one mod_cgi still in Production last i knew ... but not exposed
outside the NAT. Quick and dirty replacement for a defunct vendor
product until final replacement ready, which would be unlikely to ever
get 10 requests per minute. We still performance tested it and assured
folks that if it ever had a performance problem we could move it to
fastcgi.
but the real danger is little admin websites on the side of your
server. These may not have evolved beyond mod_cgi, since it would be a
problem if more than one sysadmin logged in anyway. The notorious
reported examples of surviving, widespread mod_cgi are CPanel and
CUPS. I hope your CUPS admin isn't exposed by your firewall. But
CPanel must be exposed to the wider internet if providing wordpress or
other multi-tenant sites using it to the public.
There was much hype that the toy websites in routers and NAS
appliances would be an incurable problem for Shell-Shock, but even if
they are mod_cgi, they're nearly all using (/bin/sh, /bin/bash) =>
busybox alias. They sometimes APPEAR to have a bash, but do not, as
it's too bloated for embedded use.
(Cheapness made a good security decision for once.)
--
Bill Ricker
bill.n1...@gmail.com
https://www.linkedin.com/in/n1vux
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Shellshock
On Wed, Oct 01, 2014 at 05:33:58PM -0400, Bill Ricker wrote: > On Wed, Oct 1, 2014 at 4:59 PM, Tom Metro wrote: > > But in the case of CGI you are just moving the network/local > > barrier a bit further down the stack. > > and moved it right through system() => /bin/sh => /bin/bash by alias > which last wasn't designed to be network secure. Of course, anyone who's writing CGI scripts and using system() should be fired. This has been well-known as a very serious security hole for oh, just about as long as the CGI interface has existed, so anyone still doing this now is either lazy to the point of malice or just not qualified to do the job. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
