+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 <p...@redbarn.org>: > > > > Philip Cheong <mailto:philip.che...@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/
