Content deleted Content added
Rescuing 2 sources and tagging 0 as dead.) #IABot (v2.0.8.6) (Neko-chan - 9462 |
rvv |
||
| (16 intermediate revisions by 12 users not shown) | |||
Line 16:
}}
'''Shellshock''', also known as '''Bashdoor''',<ref name="NYT-20140925-NP">{{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 }}</ref> is a family of [[security bug]]s<ref name="TSM-20140927">Although 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=
On 12 September 2014, Stéphane Chazelas informed Bash's maintainer Chet Ramey<ref name="NYT-20140925-NP" /> of his discovery of the original bug, which he called "Bashdoor". Working with security experts, Mr. Chazelas developed a [[Patch (computing)|patch]]<ref name="NYT-20140925-NP" /> (fix) for the issue, which by then had been assigned the vulnerability identifier ''{{CVE|2014-6271}}''.<ref name="seclist-q3-650">{{cite
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.<ref name="NYT-20140925-NP" /><ref name="TR-20140924">{{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}}</ref> 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.<ref name="ITN-20140929"/><ref name="zdnet-betterbash"/>
Line 27:
==Background==
The Shellshock bug affects [[Bash (Unix shell)|Bash]], a program that various [[Unix]]-based systems use to execute command lines and command scripts. It is often installed as the system's default [[command-line interface]]. Analysis of the [[source code]] history of Bash shows the bug was introduced on 5 August 1989, and released in Bash version 1.03 on 1 September 1989.<ref name="BASH105_CHANGELOG">{{cite web |last=Fox |first=Brian |title=Bash 1.05 ChangeLog |url=http://www.oldlinux.org/Linux.old/bin/old/bash-1.05/ChangeLog |date=21 March 1990 |access-date=14 October 2014 |archive-date=6 December 2023 |archive-url=https://web.archive.org/web/20231206061143/http://www.oldlinux.org/Linux.old/bin/old/bash-1.05/ChangeLog |url-status=dead }}</ref><ref name="BASHBUG-20141010-SC">{{cite web |last=Chazelas |first=Stéphane |work=Stéphane Chazelas and Chet Ramey confirm the vulnerability introduction date on Bash official communication channel |title=when was shellshock introduced |url=http://thread.gmane.org/gmane.comp.shells.bash.bugs/22418 |date=10 October 2014 |access-date=14 October 2014 |archive-url=https://web.archive.org/web/20161220033324/http://thread.gmane.org/gmane.comp.shells.bash.bugs/22418 |archive-date=20 December 2016 |url-status=dead }}</ref><ref name="Stack Exchange Thread">{{cite web |last=Chazelas |first=Stéphane |url=https://unix.stackexchange.com/questions/157381/when-was-the-shellshock-cve-2014-6271-7169-bug-introduced-and-what-is-the-pat/157495#157495 |title=When was the shellshock (CVE-2014-6271/7169) bug introduced, and what is the patch that fully fixes it? |date=25 September 2014}}</ref>
Shellshock is an [[arbitrary code execution]] vulnerability that offers a way for users of a system to execute commands that should be unavailable to them. This happens through Bash's "function export" feature, whereby one Bash [[process (computing)|process]] can share command scripts with other Bash processes that it executes.<ref>{{cite web|url=https://www.gnu.org/software/bash/manual/bash.html#Shell-Functions|title= Bash Reference Manual: Shell Functions |access-date= 2 October 2014}}</ref> This feature is implemented by encoding the scripts in a table that is shared between the processes, known as the [[environment variable]] list. Each new Bash process scans this table for encoded scripts, assembles each one into a command that defines that script in the new process, and executes that command.<ref name="exported-function">{{cite web|url= http://git.savannah.gnu.org/cgit/bash.git/tree/variables.c?id=ac50fbac377e32b98d2de396f016ea81e8ee9961#n315 |title=Bash 4.3 source code, file variables.c, lines 315-388 |access-date= 2 October 2014}}</ref> The new process assumes that the scripts found in the list come from another Bash process, but it cannot verify this, nor can it verify that the command that it has built is a properly formed script definition. Therefore, an attacker can execute arbitrary commands on the system or exploit other bugs that may exist in Bash's command interpreter, if the attacker has a way to manipulate the environment variable list and then cause Bash to run. At the time the bug was discovered, Bash was installed on [[macOS]] and many [[Linux]] operating systems as the main command interpreter, so that any program that used the <code>system</code> function to run any other program would use Bash to do so.
The presence of the bug was announced to the public on 2014-09-24, when Bash updates with the fix were ready for distribution,<ref name="seclist-q3-666"
==Reports of attacks==
Within an hour of the announcement of the Bash vulnerability, there were reports of machines being compromised by the bug. By 25 September 2014, [[botnet]]s based on computers compromised with exploits based on the bug were being used by attackers for [[Denial-of-service attack#Distributed attack|distributed denial-of-service]] (DDoS) attacks and [[vulnerability scanner|vulnerability scanning]].<ref name="Wired" /><ref name="IT-20140926-JS" /><ref name="bbconShellshock">{{cite web |author=Various |title=Web attacks build on Shellshock bug |url=
On 26 September, the security firm [[Incapsula]] noted 17,400 attacks on more than 1,800 web domains, originating from 400 unique IP addresses, in the previous 24 hours; 55% of the attacks were coming from China and the United States.<ref name="NYT-20140926-NP">{{cite news |last=Perlroth |first=Nicole |title=Companies Rush to Fix Shellshock Software Bug as Hackers Launch Thousands of Attacks |url=http://bits.blogs.nytimes.com/2014/09/26/companies-rush-to-fix-shellshock-software-bug-as-hackers-launch-thousands-of-attacks/ |date=26 September 2014 |work=[[New York Times]] |access-date=29 September 2014 }}</ref> By 30 September, the website performance firm [[CloudFlare]] said it was tracking approximately 1.5 million attacks and probes per day related to the bug.<ref name="businessweek">{{cite web|last1=Strohm|first1=Chris|last2=Robertson|first2=Jordan|title=Shellshock Draws Hacker Attacks, Sparks Race to Patch Bug|url=http://www.businessweek.com/news/2014-09-30/shellshock-draws-hacker-attacks-sparks-race-to-patch-bug|archive-url=https://archive.today/20141001033848/http://www.businessweek.com/news/2014-09-30/shellshock-draws-hacker-attacks-sparks-race-to-patch-bug|url-status=dead|archive-date=1 October 2014|publisher=Businessweek|access-date=1 October 2014|date=30 September 2014 }}</ref>
On 6 October, it was widely reported that [[Yahoo!]] servers had been compromised in an attack related to the Shellshock issue.<ref>{{cite news |last=Boren |first=Zachary |title=Shellshock: Romanian hackers are accessing Yahoo servers, claims security expert |url=https://www.independent.co.uk/life-style/gadgets-and-tech/news/shellshock-romanian-hackers-are-accessing-yahoo-servers-claims-security-expert-9777753.html |date=6 October 2014 |work=Independent |access-date=7 October 2014 }}</ref><ref>{{cite web | url=http://www.futuresouth.us/wordpress/?p=5 | title=Yahoo! Shellshocked Like Ninja Turtles! | access-date=7 October 2014 | url-status=dead | archive-url=https://web.archive.org/web/20141009075833/http://www.futuresouth.us/wordpress/?p=5 | archive-date=9 October 2014 | df=dmy-all }}</ref>
Line 46:
: Security documentation for the widely used [[Apache HTTP Server|Apache]] web server states: "CGI scripts can ... be extremely dangerous if they are not carefully checked,"<ref>{{cite web|url=http://httpd.apache.org/docs/2.2/misc/security_tips.html|title=Apache HTTP Server 2.2 Documentation: Security Tips|access-date=2 October 2014}}</ref> and other methods of handling web server requests are typically used instead. There are a number of online services which attempt to test the vulnerability against web servers exposed to the Internet.{{citation needed|date=September 2014}}
; OpenSSH server
: [[OpenSSH]] has a "ForceCommand" feature, where a fixed command is executed when the user logs in, instead of just running an unrestricted command shell. The fixed command is executed even if the user specified that another command should be run; in that case the original command is put into the environment variable "SSH_ORIGINAL_COMMAND". When the forced command is run in a Bash shell (if the user's shell is set to Bash), the Bash shell will parse the SSH_ORIGINAL_COMMAND environment variable on start-up, and run the commands embedded in it. The user has used their restricted shell access to gain unrestricted shell access, using the Shellshock bug.<ref name="qualys">{{cite web|url=https://blog.qualys.com/laws-of-vulnerabilities/2014/09/24/bash-shellshock-vulnerability|title=The Laws of Vulnerabilities|publisher=Qualys.com|author=Wolfgang Kandek|date=24 September 2014|access-date=26 September 2014
; DHCP clients
: Some [[Dynamic Host Configuration Protocol|DHCP]] clients can also pass commands to Bash; a vulnerable system could be attacked when connecting to an open Wi-Fi network. A DHCP client typically requests and gets an IP address from a DHCP server, but it can also be provided a series of additional options. A malicious DHCP server could provide, in one of these options, a string crafted to execute code on a vulnerable workstation or laptop.<ref name="mit-tech"/>
; Qmail server
: When using Bash to process email messages (e.g. through .forward or qmail-alias piping), the [[qmail]] mail server passes external input through in a way that can exploit a vulnerable version of Bash.<ref>
; IBM HMC restricted shell
: The bug can be exploited to gain access to Bash from the [[restricted shell]] of the [[IBM Hardware Management Console]],<ref>
==Reported vulnerabilities==
Line 58:
The maintainer of Bash was warned about the first discovery of the bug on 2014-09-12; a fix followed soon.<ref name="NYT-20140925-NP" /> A few companies and distributors were informed before the matter was publicly disclosed on 2014-09-24 with CVE identifier {{CVE|2014-6271}}.<ref name="seclist-q3-650" /><ref name="seclist-q3-666" /> However, after the release of the patch there were subsequent reports of different, yet related vulnerabilities.<ref name="wheeler-summary">{{cite web | url=http://www.dwheeler.com/essays/shellshock.html | title=Shellshock | date=13 February 2015 | access-date=17 September 2016}}</ref>
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 [[Whac-a-Mole|'whack-a-mole']] {{Sic}} job of fixing parsing errors that began with the first patch. Bash's parser is certain [to] have many many many other vulnerabilities".<ref name="BASH Whack-a-mole">{{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}}</ref>
On 27 September 2014, [[Michał Zalewski]] from [[Google Inc.]] announced his discovery of other Bash vulnerabilities,<ref name="ITN-20140929">{{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 }}</ref> one based upon the fact that Bash is typically compiled without [[address space layout randomization]].<ref name="HH-20140928">{{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 }}</ref> 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]]''.<ref name="lcamtuf-oct-1">{{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}}</ref>
Line 107:
===CVE-2014-7186===
Florian Weimer and Todd Sabin found this bug ({{CVE|2014-7186}}),<ref name="zdnet-betterbash">{{cite web|last1=Vaughan-Nichols|first1=Steven|title=Shellshock: Better 'bash' patches now available|url=
An example of the vulnerability, which leverages the use of multiple "<<EOF" declarations (nested [[Here document|"here documents"]]):
Line 138:
|url=http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-027 |title=BASH PATCH REPORT |date=25 September 2014 |website=[[GNU.org]] |access-date=2 November 2014
}}</ref><ref>{{cite web
| last=Gallagher | first=Sean | title=New "Shellshock" patch rushed out to resolve gaps in first fix [Updated] |date=26 September 2014 | access-date=2 November 2014|url=https://arstechnica.com/security/2014/09/new-shellshock-patch-rushed-out-to-resolve-gaps-in-first-fix/}}</ref>—These patches provided ''source code'' only, helpful only for those who know how to [[compile]] ("[[software build|rebuild]]") a new Bash [[binary executable]] file from the patch file and remaining source code files. The patches added a variable name prefix when functions are exported; this prevented arbitrary variables from triggering the vulnerability and enabled other programs to remove Bash functions from the environment.
The next day, Red Hat officially presented according updates for [[Red Hat Enterprise Linux]],<ref>{{cite web |url=https://rhn.redhat.com/errata/RHSA-2014-1306.html |title=Important: bash security update |date=30 September 2014 |publisher=Red Hat |access-date=2 November 2014
Line 192:
[[Category:Internet security]]
[[Category:Software bugs]]
[[Category:Computer security exploits]]
| |||