Full Disclosure mailing list archives
Re: Critical bash vulnerability CVE-2014-6271
From: Yvan Janssens <ik () yvanj me>
Date: Thu, 25 Sep 2014 17:27:25 +0100
+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-6271http://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/
Current thread:
- Critical bash vulnerability CVE-2014-6271 Philip Cheong (Sep 25)
- Re: Critical bash vulnerability CVE-2014-6271 Michal Zalewski (Sep 25)
- Re: Critical bash vulnerability CVE-2014-6271 Tony Arcieri (Sep 25)
- Re: Critical bash vulnerability CVE-2014-6271 (slightly OT logo discussion) Ben Lincoln (F7EFC8C9 - FD) (Sep 26)
- Re: Critical bash vulnerability CVE-2014-6271 Matt Hazinski (Sep 26)
- Re: Critical bash vulnerability CVE-2014-6271 Tony Arcieri (Sep 25)
- Re: Critical bash vulnerability CVE-2014-6271 Michal Zalewski (Sep 25)
- Re: Critical bash vulnerability CVE-2014-6271 Paul Vixie (Sep 25)
- Re: Critical bash vulnerability CVE-2014-6271 Yvan Janssens (Sep 25)
- Re: Critical bash vulnerability CVE-2014-6271 g () 1337 io (Sep 25)
- Re: Critical bash vulnerability CVE-2014-6271 Evan Teitelman (Sep 25)
- Re: Critical bash vulnerability CVE-2014-6271 Godin, Erik (Sep 25)
- Re: Critical bash vulnerability CVE-2014-6271 Tim (Sep 25)
- Re: Critical bash vulnerability CVE-2014-6271 Paul Vixie (Sep 25)
- Re: Critical bash vulnerability CVE-2014-6271 Seth Arnold (Sep 25)
- Re: Critical bash vulnerability CVE-2014-6271 Paul Vixie (Sep 25)
- Message not available
- Re: Critical bash vulnerability CVE-2014-6271 Paul Vixie (Sep 25)