Re: Critical bash vulnerability CVE-2014-6271

[Yvan Janssens <ik () yvanj me>]

+1 to Paul.

Bash is a popular CGI scripting environment on embedded platforms which are
around for quite a while already now. There's a lot of CPE out there
running bash internally for it's management UI, since using more high-level
languages wasn't always space/memory-efficient, and the busybox shell was
too limited to perform most slightly more complex operations. Fast-forward
to the present, and the devices are fast enough and have a large enough
memory footprint, but those older systems are still in use, and the newer
models will most likely run a new iteration of the software, but still
created using the same tools - no project manager would throw away and
rewrite an entire code base unless it's really not avoidable. And even
then, workarounds are usually preferred.

A lot of instances will technically be field-upgrade-able, the possibility
is available most of the time, but just as the issues back in 2011 with
that compromised Certificate Authority, it's not always easy to take a
piece of infrastructure down and upgrade/reflash it, and then bring it back
up. Especially if there are millions of them, and budgets don't allow
downtime or enough work force to clear it out.

2014-09-25 16:58 GMT+01:00 Paul Vixie <paul () redbarn org>:

> > Philip Cheong <mailto:philip.cheong () elastx se>
> > Thursday, September 25, 2014 5:39 AM
> > Worse that heartbleed?
>
> i think so. more below.
> > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
> http://arstechnica.com/security/2014/09/bug-in-bash-shell-creates-big-security-hole-on-anything-with-nix-in-it/
>
> heartbleed was a read-only privilege escalation, and i normally consider
> privilege escalation vulns "worse than" remote code execution vulns. as
> an example, the private key used by the SSL-enabled server was exposed
> to read access, making heartbleed also a credential compromise vuln.
> that's a high score because of all the second-order effects reachable
> once you have a credential compromise.
>
> however, i'd score this bash bug higher, because many online systems
> have multiple privilege escalation vulns which are reachable once you
> have remote code execution capability, and preventing remote code
> execution is the "crunchy exterior" to the privilege escalation's "soft
> gooey interior". (borrowing those quoted terms from cheswick et al,
> "firewalls", first edition.)
>
> the other reason to score the bash bug higher than heartbleed is the
> several-orders-of-magnitude greater attack surface. systems that use
> bash and put it in a data path (web CGI and dhcp client-side hooks being
> examples) are far more numerous than systems which used openssl, and so
> i expect the long term impact of this bash bug to be far greater than
> from heartbleed.
>
> the long tail problem, wherein many instances of this bash bug are not
> inventoried, and of those inventoried, most are not field upgradeable,
> and of those field upgradeable, most are operated without auditing. that
> means: this bash bug will still be globally available to miscreants even
> after all humans now living are dead and the world contains only our
> descendants.
>
> fixing apple and redhat and other systems we actually know about is the
> easy, and insigificant, part of this puzzle.
>
> --
> Paul Vixie
>
> _______________________________________________
> Sent through the Full Disclosure mailing list
> http://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/



-- 

Kind regards,

Yvan Janssens

Sent using CompuServe 1.22

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/