From: Steven Baltakatei Sandoval Date: Fri, 16 Jul 2021 22:26:25 +0000 (+0000) Subject: draft(en:Shellshock_bug):fix {{clarify}} issue, remove orig research X-Git-Tag: 2022-07-18~19 X-Git-Url: https://zdv2.bktei.com/gitweb/BK-2020-09.git/commitdiff_plain/1d625e107b718ac59e4fed7e1ef1d59d37a2bce9 draft(en:Shellshock_bug):fix {{clarify}} issue, remove orig research --- diff --git a/en.wikipedia.org/Shellshock_(software_bug)/article.txt b/en.wikipedia.org/Shellshock_(software_bug)/article.txt index b353749..71a7dc2 100644 --- a/en.wikipedia.org/Shellshock_(software_bug)/article.txt +++ b/en.wikipedia.org/Shellshock_(software_bug)/article.txt @@ -17,7 +17,7 @@ '''Shellshock''', also known as '''Bashdoor''',{{cite news |last=Perlroth |first=Nicole |title=Security Experts Expect 'Shellshock' Software Bug in Bash to Be Significant |url=https://www.nytimes.com/2014/09/26/technology/security-experts-expect-shellshock-software-bug-to-be-significant.html |date=25 September 2014 |work=[[New York Times]] |access-date=25 September 2014 }} is a family of [[security bug]]sAlthough described in some sources as a "virus," Shellshock is instead a design flaw in a program that comes with some operating systems. See => {{cite web |author=Staff |title=What does the "Shellshock" bug affect? |url= http://www.thesafemac.com/what-does-the-shellshock-bug-affect/|date=25 September 2014 |work=The Safe Mac |access-date=27 September 2014 }} in the [[Unix]] [[Bash (Unix shell)|Bash]] [[shell (computing)|shell]], the first of which was disclosed on 24 September 2014. Shellshock could enable an attacker to cause Bash to [[arbitrary code execution|execute arbitrary command]]s and gain unauthorized access{{cite web |last=Seltzer |first=Larry |title=Shellshock makes Heartbleed look insignificant |url=http://www.zdnet.com/shellshock-makes-heartbleed-look-insignificant-7000034143/ |date=29 September 2014 |work=[[ZDNet]] |access-date=29 September 2014 }} to many Internet-facing services, such as web servers, that use Bash to process requests. -On 12 September 2014, Stéphane Chazelas informed Bash's maintainer Chet Ramey of his discovery of the original bug, which he called "Bashdoor". Working with security experts, {{clarify-span|he|date=July 2021}} developed a [[Patch (computing)|patch]] (fix) for the issue, which by then had been assigned the vulnerability identifier ''{{CVE|2014-6271}}''.{{cite web|url=http://seclists.org/oss-sec/2014/q3/650|title=oss-sec: Re: CVE-2014-6271: remote code execution through bash|author=Florian Weimer|work=[[Seclists.org]]|date=24 September 2014|access-date=1 November 2014}} The existence of the bug was announced to the public on 2014-09-24, when Bash updates with the fix were ready for distribution.{{cite web|url=http://seclists.org/oss-sec/2014/q3/666|title=oss-sec: Re: CVE-2014-6271: remote code execution through bash|author=Florian Weimer|work=[[Seclists.org]]|date=24 September 2014|access-date=1 November 2014}} +On 12 September 2014, Stéphane Chazelas informed Bash's maintainer Chet Ramey of his discovery of the original bug, which he called "Bashdoor". Working with security experts, Mr. Chazelas developed a [[Patch (computing)|patch]] (fix) for the issue, which by then had been assigned the vulnerability identifier ''{{CVE|2014-6271}}''.{{cite web|url=http://seclists.org/oss-sec/2014/q3/650|title=oss-sec: Re: CVE-2014-6271: remote code execution through bash|author=Florian Weimer|work=[[Seclists.org]]|date=24 September 2014|access-date=1 November 2014}} The existence of the bug was announced to the public on 2014-09-24, when Bash updates with the fix were ready for distribution.{{cite web|url=http://seclists.org/oss-sec/2014/q3/666|title=oss-sec: Re: CVE-2014-6271: remote code execution through bash|author=Florian Weimer|work=[[Seclists.org]]|date=24 September 2014|access-date=1 November 2014}} The bug Chazelas discovered caused Bash to unintentionally execute commands when the commands are concatenated to the end of [[subroutine|function definitions]] stored in the values of [[environment variable]]s.{{cite web |last=Leyden |first=John |title=Patch Bash NOW: 'Shell Shock' bug blasts OS X, Linux systems wide open |url=https://www.theregister.co.uk/2014/09/24/bash_shell_vuln/ |work=[[The Register]] |date=24 September 2014 |access-date=25 September 2014}} Within days of its publication, a variety of related vulnerabilities were discovered (''{{CVE|2014-6277|2014-6278|2014-7169|2014-7186|2014-7187|leadout=and}}''). Ramey addressed these with a series of further patches. @@ -57,7 +57,7 @@ Yet the next day, it was denied that it had been ''Shellshock'' that specificall ===Overview=== The maintainer of Bash was warned about the first discovery of the bug on 2014-09-12; a fix followed soon. A few companies and distributors were informed before the matter was publicly disclosed on 2014-09-24 with CVE identifier {{CVE|2014-6271}}. However, after the release of the patch there were subsequent reports of different, yet related vulnerabilities.{{cite web | url=http://www.dwheeler.com/essays/shellshock.html | title=Shellshock | date=13 February 2015 | access-date=17 September 2016}} -On 26 September 2014, two open-source contributors, David A. Wheeler and Norihiro Tanaka, noted that there were additional issues, even after patching systems using the most recently available patches. In an email addressed to the oss-sec list and the bash bug list, Wheeler wrote: "This patch just continues the 'whack-a-mole' job of fixing parsing errors that began with the first patch. Bash's parser is certain [to] have many many many other vulnerabilities".{{cite web |last=Gallagher |first=Sean |title=Still more vulnerabilities in bash? Shellshock becomes whack-a-mole |url=https://arstechnica.com/security/2014/09/still-more-vulnerabilities-in-bash-shellshock-becomes-whack-a-mole/|date=26 September 2014 |publisher=[[Arstechnica]] |access-date=26 September 2014}} However, this rather was some general reasoning without actually presenting exploitation examples and implied restricting Bash functionality with the effect that some Bash scripts won't work any more, even if ''not'' intended to harm other users. +On 26 September 2014, two open-source contributors, David A. Wheeler and Norihiro Tanaka, noted that there were additional issues, even after patching systems using the most recently available patches. In an email addressed to the oss-sec and bash-bug mailing lists, Wheeler wrote: "This patch just continues the 'whack-a-mole' job of fixing parsing errors that began with the first patch. Bash's parser is certain [to] have many many many other vulnerabilities".{{cite web |last=Gallagher |first=Sean |title=Still more vulnerabilities in bash? Shellshock becomes whack-a-mole |url=https://arstechnica.com/security/2014/09/still-more-vulnerabilities-in-bash-shellshock-becomes-whack-a-mole/|date=26 September 2014 |publisher=[[Arstechnica]] |access-date=26 September 2014}} On 27 September 2014, [[Michał Zalewski]] from [[Google Inc.]] announced his discovery of other Bash vulnerabilities,{{cite web |last=Saarinen |first=Juha |title=Further flaws render Shellshock patch ineffective |url=http://www.itnews.com.au/News/396256,further-flaws-render-shellshock-patch-ineffective.aspx |date=29 September 2014 |work=iTnews |access-date=29 September 2014 }} one based upon the fact that Bash is typically compiled without [[address space layout randomization]].{{cite web |author=Staff |title=Shellshock, Part 3: Three more security problems in Bash (in german) |url=http://www.heise.de/security/meldung/ShellShock-Teil-3-Noch-drei-Sicherheitsprobleme-bei-der-Bash-2404788.html |date=28 September 2014 |work=[[Heise Online]] |access-date=28 September 2014 }} On 1 October, Zalewski released details of the final bugs and confirmed that a patch by Florian Weimer from [[Red Hat]] posted on 25 September does indeed prevent them. He has done that using a [[fuzzing]] technique with the aid of software utility known as ''[[american fuzzy lop (fuzzer)|american fuzzy lop]]''.{{cite web | url=http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-cracked.html | title=Bash bug: the other two RCEs, or how we chipped away at the original fix (CVE-2014-6277 and '78) | work=lcamtuf blog | date=1 October 2014 | access-date=8 October 2014}}