full-disclosure - Re: [FD] Critical bash vulnerability CVE-2014-6271

Open Source and information security mailing list archives

Date: Thu, 25 Sep 2014 10:30:51 -0700
From: "g@...7.io" <g@...7.io>
To: fulldisclosure@...lists.org
Subject: Re: [FD] Critical bash vulnerability CVE-2014-6271

A quick test that was posted somewhere this morning..

Vulnerable or Not?
You can check if you're vulnerable by running the following commands
(code provided by the CSA). Open a terminal window and enter the
following command at the $ prompt:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If you're vulnerable it'll print:

vulnerable
this is a test

If you've updated Bash you'll only see:

this is a test

On 9/25/14 8:58 AM, Paul Vixie wrote:
> 
> 
>> Philip Cheong <mailto:philip.cheong@...stx.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.
> 

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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives