This is the
talk page for discussing improvements to the
Shellshock (software bug) article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The name of the bug is spelled "Shellshock" (no StudlyCaps) in Red Hat's security advisory. The name "shellshocked" only occurs in the given source as a tag. QVVERTYVS ( hm?) 19:39, 25 September 2014 (UTC)
Same bug. QVVERTYVS ( hm?) 20:08, 25 September 2014 (UTC)
These should all be moved under a title of CVE-2014-7169 ( Edprevost ( talk) 20:05, 25 September 2014 (UTC)
I have taken the liberty of redirecting everything to this article, and overwriting this article with my version since it seemed more fleshed out. Feel free to merge anything from the two other old versions ( [1] and [2]). Thue ( talk) 22:18, 25 September 2014 (UTC)
Just because some hacker on the web creates a piece of artwork in response to this vulnerability, that hardly qualifies it as an official logo. (Since when do software bugs get logos anyway?) WikiDan61 ChatMe! ReadMe!! 20:45, 25 September 2014 (UTC)
These aren't official, this is simply documenting the history, you know, like an encyclopedia. So when we look back as a security community it will have been preserved. But thanks for slowing me down. :0) Edprevost 20:52, 25 September 2014 (UTC)
sad panda can we at least get it under the CVE name?
Edprevost (
talk) 21:46, 25 September 2014 (UTC)
Yes, please drop the logos for now, IMO. Thue ( talk) 22:19, 25 September 2014 (UTC)
For my own education Thue ( talk · contribs), How is the testing section any different then me providing the same content in a screenshot? Edprevost ( talk) 22:32, 25 September 2014 (UTC)
I've tagged the article for WikiProjects Computer Security, Apple, and Linux; at high, mid, and mid importance respectively, and start-class. Please feel free to amend the importance ratings if you feel otherwise. — Sasuke Sarutobi ( talk) 23:46, 25 September 2014 (UTC)
I imagine that many people will be coming to this article looking for more information. There are code examples on the page which some users will surely try to run (it seems that they are there, in part, to allow users to self-test). This is of course a good target for malicious wiki users who could change that example code and make users damage their computers. So I think it would be good to have some form of protection on the page at least for a week, so that that can't happen. CodeCat ( talk) 00:17, 26 September 2014 (UTC)
In my opinion, the details provided in this section are incorrect and misleading. What is presented as bash vulnerability, is in fact a correct and expected behavior. Specifically, by executing command line in form of variable=value command, it is expected that the command is executed. This is the reason why this purported "vulnerability" is seen in all shells. On the other hand, the vulnerability test included in "Testing" section is correct, provided that system uses bash as sh. 129.112.109.243 ( talk) 00:46, 26 September 2014 (UTC)
Please study my example below {user:chridd} Thank you for correcting that rm example that was wrong, but it is important to capture the vulnerability across the other shells, please put the other shell examples back. — Preceding unsigned comment added by Edprevost ( talk • contribs) 02:05, 26 September 2014 (UTC)
This is not seen in all shells by design, the newly patched systems, patched to bash-4.1.2-15.19 via Amazon have a protection in place, but ONLY for BASH, hence the creation of CVE 2014-7169
root@ ec2-user#
X='() { (a)=>\' bash -c "echo date"
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
[root@ ec2-user]# X='() { (a)=>\' csh -c "echo date"
date
root@ ec2-user# cat echo
Fri Sep 26 01:37:16 UTC 2014
Edprevost ( talk) 01:40, 26 September 2014 (UTC)
I recommend this section be removed completely. It appears to be Edprevost's own interpretation of the bug, and his own attempt to reproduce it. As such, it is purely WP:OR and has no place in a Wikipedia article. WikiDan61 ChatMe! ReadMe!! 12:56, 26 September 2014 (UTC)
This is an example of CVE 2014-7169. In which a local file is written with the contents of 'date'; it is not an "interpretation", it IS the bug. On what technical/academic grounds are you qualified to be commenting on this [[User talk:WikiDan61|WikiDan61] Edprevost ( talk) 13:06, 26 September 2014 (UTC)
This is my area and industry of expertise, please read the references supplied by myself and others WikiDan61, the examples given by those working on this page are taken from the references. Edprevost ( talk) 13:29, 26 September 2014 (UTC)
Please see the references Edprevost ( talk) 13:47, 26 September 2014 (UTC)
Please see [3] Edprevost ( talk) 18:45, 26 September 2014 (UTC)
The result of the move request was: not moved ( non-admin closure) — innotata 06:07, 8 October 2014 (UTC)
Shellshock (software bug) →
Shellshocked (computer security) – Incorrect Title –
Edprevost (
talk) 19:37, 25 September 2014 (UTC)
I created that section and, yes, it's OR. Someone will eventually figure it out and write about it, if they haven't already. This probably falls under WP:IAR because it's too important to get that information out there. Sparkie82 ( t• c) 19:46, 26 September 2014 (UTC)
I would say that Edprevost's most recent edit brings it into line with policy while improving the article. Thanks.
Sparkie82 removing all of the original research and having a smaller encyclopedia as a result would be a dramatic improvement. Quality of content is more important than quantity. If you look at our featured articles you will see there are rather long and contain little to no original research. Chillum 18:26, 27 September 2014 (UTC)
While working on patching Shellshock, Red Hat researcher Florian Weimer found two more bugs, CVE-2014-7186 and CVE-2014-7187, according to https://securityblog.redhat.com/2014/09/26/frequently-asked-questions-about-the-shellshock-bash-flaws/ . Could someone please add this to the text if appropriate? I need to get to bed. One can also dig through the relevant mailing list at http://www.openwall.com/lists/oss-security/ for more information. Thanks in advance. Jesse Viviano ( talk) 04:38, 27 September 2014 (UTC)
Added Jesse Vivano, thanks :0) Edprevost ( talk) 04:50, 27 September 2014 (UTC)
It's natural for a fast-moving topic like this to result in a article that's messy - but can we start tidying up?
Snori ( talk) 09:04, 27 September 2014 (UTC)
Should I remove the red link (or probably link it externally). I think there isn't so much sense putting it as an red link. - gacelperfinian( talk in - error? Start a new topic) 07:42, 28 September 2014 (UTC)
I rewrote the section, CVE-2014-6271, as:
The bug manifests itself as Bash is starting up. When Bash is invoked, it erroneously processes trailing strings after function definitions in the values of environment variables from its parent process. [a] This allows remote attackers to execute arbitrary code via a crafted environment. [b]
The bug requires that an environment variable be defined with a function that uses closed parentheses and brackets followed by arbitrary code, such as:
export x='() { :;}; echo this-should-not-run'
When a subsequent command invokes Bash, Bash processes the environment from its parent process, including the malformed environment variable. When the malformed environment variable is processed, the bug causes the trailing arbitrary code to execute before running the subsequent command, such as:
bash -c 'echo this-will-run'
this-should-not-run
this-will-run
The stackexchange reference [c] was removed with the edit. Sparkie82 ( t• c) 17:28, 28 September 2014 (UTC)
@ Sparkie82: I agree there are too many selfpub sources, as you tagged the article. I think some are used appropriately in the article, though. Specs and manpages seem vaguely okay, and I think it's fine to reference security releases from Ubuntu, Redhat, etc, in certain cases. Blogs from sources known in the field like Qualys may be okay, at least for now. I think the Zalewski blog about the Florian Wiemer patch should go, as it doesn't match the apparent corresponding patch. [4] There's a Twitter ref too. I'm going to remove both of those things. Which selfpub sources did you have an issue with? IRW0 ( talk) 19:02, 28 September 2014 (UTC)
More Self pub stuff added by Ericblake, it's great history, but is once again coming from Blogs and newslists; which is just how the Security community is. Ed Prevost profile| contributions 22:14, 6 October 2014 (UTC)
http://www.cnet.com/news/bigger-than-heartbleed-bash-bug-could-leave-it-systems-shellshocked/
says "quarter-century-old security flaw", and http://www.inquisitr.com/1508290/shellshock-vulnerability-went-undetected-for-25-years/ states "gone undetected for 25 years", but neither states its sources
nor pinpoints the exact date the way the bash source code does. Ed Prevost profile| contributions 22:25, 6 October 2014 (UTC)
Can someone please do a write up of shellshocker.net? It's one of the most up to date resources and provides information on how to test and patch your system. It was the first available online shellshock vulnerability testing service that has provided over 42164 Total tests to date (as of the writing of this). It was originally on this page but has been removed. — Preceding unsigned comment added by 184.19.8.213 ( talk) 22:09, 28 September 2014 (UTC)
Does the software from The Wikipedia as used in many other wikis suffer from this vulnerability? 194.176.105.153 ( talk) 09:34, 29 September 2014 (UTC)
I don't like this section. It truly would be pages long if we attempted to create every possible entry here. I think the first paragraph can stay, but from CGI-based web server attack to Note of offline system vulnerability should go, and the other CVEs should just be referenced in the remaining content. Ed Prevost profile| contributions 13:32, 29 September 2014 (UTC)
I also thnk we need to cover notiable exploit vectors in this article, especially ones that have gotten repeated coverage along side articles about the active bug as well as ones that have been already exploited. This article is not just about the bug but the security implications of it, and as such it should cover the implications especially as readers that might not be security experts. That said we do not need to cover all; such a list would be impossibly long. PaleAqua ( talk) 22:14, 1 October 2014 (UTC)
— a long list of commands from Amazon's EWS —
|
---|
|
Albeit, it's not infinite, but perhaps that was simply an expression. Ed Prevost profile| contributions 01:57, 3 October 2014 (UTC)
We don't need reliable sources for things we are not going to include in the article. Chillum 15:31, 3 October 2014 (UTC)
Thanks for clarifying on the moving of the section... however it was moved in its entirety and is very much so related to this discussion, but as you protest such a move I've added a note to this section. As for your question my reply is the same, add only what we have good verifiable references for; not your friends blogs and twitter accounts and forum posts. I really think Chillum said it best when we previously discussed this: "...removing all of the original research and having a smaller encyclopedia as a result would be a dramatic improvement. Quality of content is more important than quantity." Ed Prevost profile| contributions 01:03, 8 October 2014 (UTC)
PLEASE READ the previous discussion on the "logging" entry, which was removed from the "exploit" section due to the very issue of OR in this section that I am trying to avoid again. That previous discussion is most pertainent to discussions about the parent exploit section. /info/en/?search=Talk:Shellshock_(software_bug)#Section_.22Log_parsing.22 Ed Prevost profile| contributions 05:02, 8 October 2014 (UTC)
FWIW --
Following have been *very recently* registered (data possibly useful in the
article?):
Following were registered earlier - but also recently updated:
In any case - Enjoy! :) Drbogdan ( talk) 13:25, 30 September 2014 (UTC)
hi i'm not an admin
this bash(1) vulnerability is total bull
the premise is that a user cannot run bash to create a file using special quoting
the history of shells in general is that syntax (especially quoting, piping) is difficult to get correct AND different between competing shells, and that parsing might be flawed or cause something one didn't first expect. documentation focused on getting it right. whatever happens: it was limited to impacting the user running it. it's not suid.
there was never any concept that one might "abuse every part of sh(1) to find a parse error that allowed user to create a file owned by user". infact flaws are taken advantage of at times and called features and or compatibility!
again total non-sense. the proper perspective is: it cannot allow user to become another user. if user can run flawed software that creates a file: is not a security issue.
it's "an update" maybe but not a security issue. and one that may be targeted at causing old scripts to fail (that has YET to be seen as T/F)
so when are you fixing zsh(1), csh(1), ksh(1) for "parse flaws" huh? i thought so. total bull.
SUMMARY 1: under no circumstances would one allow users to pass args to a root owned shell (only an idiot would think that could ever be secure old unix docs told you so)
SUMMARY 2: under no circumstances would one allow foreigners to pass args to a user COMMAND shell and expect user account not to eventually be hacked by a, guess what, COMMAND. never.
EVEN WITH 1 FIX it'd stupid to think there was no other parsing trick that might be found. and old unix docs / linux docs told you so.
ONLY ONLY user should run "well known" applications (checking crc before using, of course) and expect failure in rare cases
UNIX SECURITY: no shell run as user can become root, no running process owne by user can become root (unless it's suid - which is reserved for legally feduciary software who's purpose is to manage the same barrier. otherwise a suid binary is likely a crafted virus in waiting, or could become one)
SOFTWARE SECURITY: if you value your user account don't run crappy software and of course don't let foreigners provide input to any software. don't put anything in an online user account you value greatly and always back up.
it's just as they always told you.
the idea this new fellow has found a flow unix gurus hadn't known about: IS FALSE ADVERTISEMENT - AIMED AT MAKING UNIX / LINUX LOOK BAD
any apple or microsoft or android, if it allowed user to allow foreigners to provide ANY input to ABOUT ANY running software expecting input ... any number of flaws will be found that could effect user and or create a file owned by user
....
you people sometimes i want to throw a shoe at these things 72.219.202.186 ( talk) 16:47, 2 October 2014 (UTC)
in 1980's IBM release to pubilc not to trust keyboards made in china
today hardware is very complex made of many components. infact some components are made so that government or police can evesdrop or hack consumer computers (ie, DOCIS modems)
circuits are very large and complex and what might be hidden in them to be (accidentally) invoked - it's too complex for most anyone to know
the fact is if one is using ANY large complex system produces by many foreigners around the world one should EXPECT there are hidden triggers waiting in the hardware. and moreso the software - that circle is even more bribe-able and loosely watched.
72.219.202.186 ( talk) 16:47, 2 October 2014 (UTC)
From the list
2014-10-03 15:28:31 -0400, David A. Wheeler: > FYI, I've created a timeline of major Shellshock events here: > > http://www.dwheeler.com/essays/shellshock.html#timeline > > If anyone has corrections or key additions, let me know. [...]
About the discovery.
I discovered it in the morning (UK) of 2014-09-12 and reported it at Fri, 12 Sep 2014 16:10:35 +0100 to Chet, and the security contacts of Debian, Red Hat, Ubuntu and Mandriva (SUSE added later) including details of the bug and the SSH and HTTP (Apache header) vectors and mitigation and a bit fat warning that it was very serious and not to be disclosed.
First patch by Chet at 2014-09-12 16:32:17 -0400, but was easily bypassed. Ensued a discussion on that original list, several patch iterations, whether or not to harden at this point and how, whether or not to output error messages on parsing error, additional vectors, scope, detection methods (IDS...), other affected shells, local privilege escalation?, whether localisation can bypass the fix, the impact of two env vars with the same name, backward compatibility, who to contact early... Of course, I have no visibility of what was discussed internally at Red Hat/Ubuntu/Mandriva...
I suggested the name "bashdoor" on that list on Sun, 14 Sep 2014 14:29:48 +0100.
A release schedule with public disclosure on the 24th at 14:00 UTC and early notification to other unix and linux vendors on the 22nd and select infrastructure provider notification (such as CDNs including Microsoft) on the 23rd proposed on the 16th by Florian.
Chet had patches for the final (before disclosure) fix for the current and all past versions of bash up to 3.0 by 2014-09-16 22:00:02 -0400 (from diff dates)
I was out of the loop after the 19th
bashdoor.com was registered (not by me) with a creation date of 2014-09-24 13:59 UTC sometime before 2014-09-24 06:59:10Z according to whois. Florian also said here that someone brought the early notification sent to vendors/infrastructure to the press, so someone obviously intended to take it to the press. I don't know whom.
To answer the other post. The feature was definitely not in 1.05 nor 1.12 (the source of which can be found on the web), but was in 1.13.5. Chet confirmed (to me and news outlets) that it was added in 1.13.
Cheers, Stephane
The idea of a security bug in a program that allows users to destroy files strikes me as silly. No shell, including bash, was ever originally intended to be executed indirectly by someone who had the ability to manipulate environment variable values. Arguably, the CGI mechanism that allows that is the security issue.
I think characterizing Shellshock as security bug in bash is misleading at best. It's certainly a bug in bash - but what makes the whole thing a security bug is the CGI mechanism, which is utilized only a small percentage of systems that have bash. I suggest the introduction be more clear about this.
The perception out there bash has a security bug is confusing people. They think using bash, in any way, makes them vulnerable. -- В²C ☎ 01:18, 8 October 2014 (UTC)
Again, bash was never intended to be secure - so to say it has a security bug is nonsensical. It's like saying there is a security breach on a public beach. -- В²C ☎ 17:31, 9 October 2014 (UTC)
It is very simple. Bash executes codes that it is not supposed to execute. It fails to properly escape user input allowing an injection attack. This is a security vulnerability in bash by any objective measure. Bash is not behaving as it is supposed to and this is causing severe security issues. The suggestion that bash is not meant to be used in secure environments is contradicted by decades of actual security practice.
I don't mean to be rude but your position seems to lack a basis. Chillum 20:19, 9 October 2014 (UTC)
All I'm trying to say is that there is nothing inherently insecure in using bash in how it is normally used, even if it has this bug in it. Only if you are trying to use bash in a particular way — with the -r option or to execute scripts in a secure environment but in which the environment variables can be manipulated — is there a potential issue. -- В²C ☎ 21:07, 9 October 2014 (UTC)
I am glad that you recognize the issue. Your remaining argument seems to be that bash is not meant to be used in secure environments where users can define environment variables, this is not supported by general practice. Chillum 21:43, 9 October 2014 (UTC)
Bash is a tool - it is not a security tool. The following is a valid bash command. It will remove many if not all files on a system (depending on relevant user/directory permissions).
rm -rf /
I know that it was considered a security issue, because many CGI scripts invoke some bash scripts to produce an output, and there is nothing wrong with that on its own. It allows writing some servers easily, and if proper care is taken for input sanitization it works just fine. It is not that the environmental variables are inherited, or that they should contain values only, and they were not properly parsed, because Bash's PROMPT_COMMAND environmental variable by design allows to run arbitrary commands. The main problem with Shellshock is that when using CGI, all the input headers and URL data are put into HTTP_xyz, QUERY_STRING and PATH_INFO environmental variables. And that is fine too, becasue it is not possible to put stuff into PROMPT_COMMAND for example, and all HTTP servers will ensure that other environment variables are sane (i.e. PS1, or LANG, or HOME, BASH_ENV, etc, and some of these are even ignored when run in 'privileged' mode using bash -p), and there is no direct way to add new or modify existing variables other than the HTTP_xyz ones, which are not going to conflict with any existing variable used by shell. The expectation, and the design of environment variables, is that they just carry some strings, and if they are not used by the shell in any particular way, they shall remain just strings, and not interpreted in any specific way. Bash violated this behavior with this bug. How the bash did had a bug like this is absolutely beyond me.
2A02:168:F609:0:DA58:D7FF:0:F02 (
talk) 19:57, 16 December 2018 (UTC)
The Background section currently has this statement:
I think the "fix" for Shellshock has broken this. You used to be able to do this:
$ x='() {echo in x;}' $ x in x $
That no longer works in versions of bash with the Shellshock fix.
-- В²C ☎ 01:07, 10 October 2014 (UTC)
$ echo $BASH_VERSION ::4.2.45(1)-release ::$ x='() {echo in x;}' ::$ -bash: x: command not found ::$
$ echo $BASH_VERSION ::4.3.28(2)-release ::$ x='() {echo in x;}' ::$ -bash: x: command not found ::$
Hey, PaleAqua! I've just reverted your edit, so please allow me to explain it a bit further. While looking at MOS:SECTIONCAPS and MOS:LCITEMS, they both pretty much boil down to "the correct case should always be retained, even in situations where normal rules would require capitalization". At the same time, I'm not sure that "qmail" is a true registered trademark so MOS:TMRULES would apply? Am I missing something? — Dsimic ( talk | contribs) 01:37, 6 November 2014 (UTC)
Stéphane Chazelas contacted Bash's maintainer...
The name Stéphane Chazelas is introduced without any mention of who he is. Is his name relevant? If so, he should be described in some way, even if it is just "a Unix user". (He is apparently not important enough to have his own Wikipedia entry.) — 91.238.123.116 ( talk) 11:57, 26 November 2015 (UTC)
env X='() { (a)=>\' bash -c "echo echo \$'\166\165\154\156\145\162\141\142\154\145'"; cat echo
The escaped characters, "\166\165\154\156\145\162\141\142\154\145" is ASCII for "vulnerable".
$ echo $'\166\165\154\156\145\162\141\142\154\145'
vulnerable
The dollar substitution converts the backslashes to ASCII, but if we escape the dollar:
echo \$'\166\165\154\156\145\162\141\142\154\145'
$\166\165\154\156\145\162\141\142\154\145
On a vulnerable system:
$ X='() { (a)=>\' bash -c "echo echo \$'\166\165\154\156\145\162\141\142\154\145'"
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
$ cat echo
vulnerable
On a non vulnerable system, it will simply output $\166\165\154\156\145\162\141\142\154\145 instead of date.
Husseydevin ( talk) 17:20, 28 February 2017 (UTC)
The following source is dead. But I found the site in the Wayback archive.
I found the following guide to fix it, but the given template doesn't feel right in the preview - I have no idea how to fix it. /info/en/?search=Help:Using_the_Wayback_Machine
Dead Source:
http://www.futuresouth.us/wordpress/?p=5 [20]
Wayback machine: http://wayback.archive.org/web/20160328232448/http://www.futuresouth.us/wordpress/?p=5
Thank you for your help DopeforHope ( talk) 10:59, 25 July 2017 (UTC)
This hack was done using this vulnerability. Considering how massive this hack was, it could be a good idea to include this in the "Reports of Attacks" section Skyturnrouge ( talk) 06:02, 19 November 2019 (UTC)
The link for the BusinessWeek citation ( http://www.businessweek.com/news/2014-09-30/shellshock-draws-hacker-attacks-sparks-race-to-patch-bug) is dead.
I found a mirror on Bloomberg ( https://www.bloomberg.com/news/articles/2014-09-30/shellshock-draws-hacker-attacks-sparks-race-to-patch-bug), but I do not know how to edit a citation. Could someone more knowledgeable than me with Wikipedia source editing please fix it? Lplawlor ( talk) 23:34, 7 October 2022 (UTC)
This is the
talk page for discussing improvements to the
Shellshock (software bug) article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The name of the bug is spelled "Shellshock" (no StudlyCaps) in Red Hat's security advisory. The name "shellshocked" only occurs in the given source as a tag. QVVERTYVS ( hm?) 19:39, 25 September 2014 (UTC)
Same bug. QVVERTYVS ( hm?) 20:08, 25 September 2014 (UTC)
These should all be moved under a title of CVE-2014-7169 ( Edprevost ( talk) 20:05, 25 September 2014 (UTC)
I have taken the liberty of redirecting everything to this article, and overwriting this article with my version since it seemed more fleshed out. Feel free to merge anything from the two other old versions ( [1] and [2]). Thue ( talk) 22:18, 25 September 2014 (UTC)
Just because some hacker on the web creates a piece of artwork in response to this vulnerability, that hardly qualifies it as an official logo. (Since when do software bugs get logos anyway?) WikiDan61 ChatMe! ReadMe!! 20:45, 25 September 2014 (UTC)
These aren't official, this is simply documenting the history, you know, like an encyclopedia. So when we look back as a security community it will have been preserved. But thanks for slowing me down. :0) Edprevost 20:52, 25 September 2014 (UTC)
sad panda can we at least get it under the CVE name?
Edprevost (
talk) 21:46, 25 September 2014 (UTC)
Yes, please drop the logos for now, IMO. Thue ( talk) 22:19, 25 September 2014 (UTC)
For my own education Thue ( talk · contribs), How is the testing section any different then me providing the same content in a screenshot? Edprevost ( talk) 22:32, 25 September 2014 (UTC)
I've tagged the article for WikiProjects Computer Security, Apple, and Linux; at high, mid, and mid importance respectively, and start-class. Please feel free to amend the importance ratings if you feel otherwise. — Sasuke Sarutobi ( talk) 23:46, 25 September 2014 (UTC)
I imagine that many people will be coming to this article looking for more information. There are code examples on the page which some users will surely try to run (it seems that they are there, in part, to allow users to self-test). This is of course a good target for malicious wiki users who could change that example code and make users damage their computers. So I think it would be good to have some form of protection on the page at least for a week, so that that can't happen. CodeCat ( talk) 00:17, 26 September 2014 (UTC)
In my opinion, the details provided in this section are incorrect and misleading. What is presented as bash vulnerability, is in fact a correct and expected behavior. Specifically, by executing command line in form of variable=value command, it is expected that the command is executed. This is the reason why this purported "vulnerability" is seen in all shells. On the other hand, the vulnerability test included in "Testing" section is correct, provided that system uses bash as sh. 129.112.109.243 ( talk) 00:46, 26 September 2014 (UTC)
Please study my example below {user:chridd} Thank you for correcting that rm example that was wrong, but it is important to capture the vulnerability across the other shells, please put the other shell examples back. — Preceding unsigned comment added by Edprevost ( talk • contribs) 02:05, 26 September 2014 (UTC)
This is not seen in all shells by design, the newly patched systems, patched to bash-4.1.2-15.19 via Amazon have a protection in place, but ONLY for BASH, hence the creation of CVE 2014-7169
root@ ec2-user#
X='() { (a)=>\' bash -c "echo date"
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
[root@ ec2-user]# X='() { (a)=>\' csh -c "echo date"
date
root@ ec2-user# cat echo
Fri Sep 26 01:37:16 UTC 2014
Edprevost ( talk) 01:40, 26 September 2014 (UTC)
I recommend this section be removed completely. It appears to be Edprevost's own interpretation of the bug, and his own attempt to reproduce it. As such, it is purely WP:OR and has no place in a Wikipedia article. WikiDan61 ChatMe! ReadMe!! 12:56, 26 September 2014 (UTC)
This is an example of CVE 2014-7169. In which a local file is written with the contents of 'date'; it is not an "interpretation", it IS the bug. On what technical/academic grounds are you qualified to be commenting on this [[User talk:WikiDan61|WikiDan61] Edprevost ( talk) 13:06, 26 September 2014 (UTC)
This is my area and industry of expertise, please read the references supplied by myself and others WikiDan61, the examples given by those working on this page are taken from the references. Edprevost ( talk) 13:29, 26 September 2014 (UTC)
Please see the references Edprevost ( talk) 13:47, 26 September 2014 (UTC)
Please see [3] Edprevost ( talk) 18:45, 26 September 2014 (UTC)
The result of the move request was: not moved ( non-admin closure) — innotata 06:07, 8 October 2014 (UTC)
Shellshock (software bug) →
Shellshocked (computer security) – Incorrect Title –
Edprevost (
talk) 19:37, 25 September 2014 (UTC)
I created that section and, yes, it's OR. Someone will eventually figure it out and write about it, if they haven't already. This probably falls under WP:IAR because it's too important to get that information out there. Sparkie82 ( t• c) 19:46, 26 September 2014 (UTC)
I would say that Edprevost's most recent edit brings it into line with policy while improving the article. Thanks.
Sparkie82 removing all of the original research and having a smaller encyclopedia as a result would be a dramatic improvement. Quality of content is more important than quantity. If you look at our featured articles you will see there are rather long and contain little to no original research. Chillum 18:26, 27 September 2014 (UTC)
While working on patching Shellshock, Red Hat researcher Florian Weimer found two more bugs, CVE-2014-7186 and CVE-2014-7187, according to https://securityblog.redhat.com/2014/09/26/frequently-asked-questions-about-the-shellshock-bash-flaws/ . Could someone please add this to the text if appropriate? I need to get to bed. One can also dig through the relevant mailing list at http://www.openwall.com/lists/oss-security/ for more information. Thanks in advance. Jesse Viviano ( talk) 04:38, 27 September 2014 (UTC)
Added Jesse Vivano, thanks :0) Edprevost ( talk) 04:50, 27 September 2014 (UTC)
It's natural for a fast-moving topic like this to result in a article that's messy - but can we start tidying up?
Snori ( talk) 09:04, 27 September 2014 (UTC)
Should I remove the red link (or probably link it externally). I think there isn't so much sense putting it as an red link. - gacelperfinian( talk in - error? Start a new topic) 07:42, 28 September 2014 (UTC)
I rewrote the section, CVE-2014-6271, as:
The bug manifests itself as Bash is starting up. When Bash is invoked, it erroneously processes trailing strings after function definitions in the values of environment variables from its parent process. [a] This allows remote attackers to execute arbitrary code via a crafted environment. [b]
The bug requires that an environment variable be defined with a function that uses closed parentheses and brackets followed by arbitrary code, such as:
export x='() { :;}; echo this-should-not-run'
When a subsequent command invokes Bash, Bash processes the environment from its parent process, including the malformed environment variable. When the malformed environment variable is processed, the bug causes the trailing arbitrary code to execute before running the subsequent command, such as:
bash -c 'echo this-will-run'
this-should-not-run
this-will-run
The stackexchange reference [c] was removed with the edit. Sparkie82 ( t• c) 17:28, 28 September 2014 (UTC)
@ Sparkie82: I agree there are too many selfpub sources, as you tagged the article. I think some are used appropriately in the article, though. Specs and manpages seem vaguely okay, and I think it's fine to reference security releases from Ubuntu, Redhat, etc, in certain cases. Blogs from sources known in the field like Qualys may be okay, at least for now. I think the Zalewski blog about the Florian Wiemer patch should go, as it doesn't match the apparent corresponding patch. [4] There's a Twitter ref too. I'm going to remove both of those things. Which selfpub sources did you have an issue with? IRW0 ( talk) 19:02, 28 September 2014 (UTC)
More Self pub stuff added by Ericblake, it's great history, but is once again coming from Blogs and newslists; which is just how the Security community is. Ed Prevost profile| contributions 22:14, 6 October 2014 (UTC)
http://www.cnet.com/news/bigger-than-heartbleed-bash-bug-could-leave-it-systems-shellshocked/
says "quarter-century-old security flaw", and http://www.inquisitr.com/1508290/shellshock-vulnerability-went-undetected-for-25-years/ states "gone undetected for 25 years", but neither states its sources
nor pinpoints the exact date the way the bash source code does. Ed Prevost profile| contributions 22:25, 6 October 2014 (UTC)
Can someone please do a write up of shellshocker.net? It's one of the most up to date resources and provides information on how to test and patch your system. It was the first available online shellshock vulnerability testing service that has provided over 42164 Total tests to date (as of the writing of this). It was originally on this page but has been removed. — Preceding unsigned comment added by 184.19.8.213 ( talk) 22:09, 28 September 2014 (UTC)
Does the software from The Wikipedia as used in many other wikis suffer from this vulnerability? 194.176.105.153 ( talk) 09:34, 29 September 2014 (UTC)
I don't like this section. It truly would be pages long if we attempted to create every possible entry here. I think the first paragraph can stay, but from CGI-based web server attack to Note of offline system vulnerability should go, and the other CVEs should just be referenced in the remaining content. Ed Prevost profile| contributions 13:32, 29 September 2014 (UTC)
I also thnk we need to cover notiable exploit vectors in this article, especially ones that have gotten repeated coverage along side articles about the active bug as well as ones that have been already exploited. This article is not just about the bug but the security implications of it, and as such it should cover the implications especially as readers that might not be security experts. That said we do not need to cover all; such a list would be impossibly long. PaleAqua ( talk) 22:14, 1 October 2014 (UTC)
— a long list of commands from Amazon's EWS —
|
---|
|
Albeit, it's not infinite, but perhaps that was simply an expression. Ed Prevost profile| contributions 01:57, 3 October 2014 (UTC)
We don't need reliable sources for things we are not going to include in the article. Chillum 15:31, 3 October 2014 (UTC)
Thanks for clarifying on the moving of the section... however it was moved in its entirety and is very much so related to this discussion, but as you protest such a move I've added a note to this section. As for your question my reply is the same, add only what we have good verifiable references for; not your friends blogs and twitter accounts and forum posts. I really think Chillum said it best when we previously discussed this: "...removing all of the original research and having a smaller encyclopedia as a result would be a dramatic improvement. Quality of content is more important than quantity." Ed Prevost profile| contributions 01:03, 8 October 2014 (UTC)
PLEASE READ the previous discussion on the "logging" entry, which was removed from the "exploit" section due to the very issue of OR in this section that I am trying to avoid again. That previous discussion is most pertainent to discussions about the parent exploit section. /info/en/?search=Talk:Shellshock_(software_bug)#Section_.22Log_parsing.22 Ed Prevost profile| contributions 05:02, 8 October 2014 (UTC)
FWIW --
Following have been *very recently* registered (data possibly useful in the
article?):
Following were registered earlier - but also recently updated:
In any case - Enjoy! :) Drbogdan ( talk) 13:25, 30 September 2014 (UTC)
hi i'm not an admin
this bash(1) vulnerability is total bull
the premise is that a user cannot run bash to create a file using special quoting
the history of shells in general is that syntax (especially quoting, piping) is difficult to get correct AND different between competing shells, and that parsing might be flawed or cause something one didn't first expect. documentation focused on getting it right. whatever happens: it was limited to impacting the user running it. it's not suid.
there was never any concept that one might "abuse every part of sh(1) to find a parse error that allowed user to create a file owned by user". infact flaws are taken advantage of at times and called features and or compatibility!
again total non-sense. the proper perspective is: it cannot allow user to become another user. if user can run flawed software that creates a file: is not a security issue.
it's "an update" maybe but not a security issue. and one that may be targeted at causing old scripts to fail (that has YET to be seen as T/F)
so when are you fixing zsh(1), csh(1), ksh(1) for "parse flaws" huh? i thought so. total bull.
SUMMARY 1: under no circumstances would one allow users to pass args to a root owned shell (only an idiot would think that could ever be secure old unix docs told you so)
SUMMARY 2: under no circumstances would one allow foreigners to pass args to a user COMMAND shell and expect user account not to eventually be hacked by a, guess what, COMMAND. never.
EVEN WITH 1 FIX it'd stupid to think there was no other parsing trick that might be found. and old unix docs / linux docs told you so.
ONLY ONLY user should run "well known" applications (checking crc before using, of course) and expect failure in rare cases
UNIX SECURITY: no shell run as user can become root, no running process owne by user can become root (unless it's suid - which is reserved for legally feduciary software who's purpose is to manage the same barrier. otherwise a suid binary is likely a crafted virus in waiting, or could become one)
SOFTWARE SECURITY: if you value your user account don't run crappy software and of course don't let foreigners provide input to any software. don't put anything in an online user account you value greatly and always back up.
it's just as they always told you.
the idea this new fellow has found a flow unix gurus hadn't known about: IS FALSE ADVERTISEMENT - AIMED AT MAKING UNIX / LINUX LOOK BAD
any apple or microsoft or android, if it allowed user to allow foreigners to provide ANY input to ABOUT ANY running software expecting input ... any number of flaws will be found that could effect user and or create a file owned by user
....
you people sometimes i want to throw a shoe at these things 72.219.202.186 ( talk) 16:47, 2 October 2014 (UTC)
in 1980's IBM release to pubilc not to trust keyboards made in china
today hardware is very complex made of many components. infact some components are made so that government or police can evesdrop or hack consumer computers (ie, DOCIS modems)
circuits are very large and complex and what might be hidden in them to be (accidentally) invoked - it's too complex for most anyone to know
the fact is if one is using ANY large complex system produces by many foreigners around the world one should EXPECT there are hidden triggers waiting in the hardware. and moreso the software - that circle is even more bribe-able and loosely watched.
72.219.202.186 ( talk) 16:47, 2 October 2014 (UTC)
From the list
2014-10-03 15:28:31 -0400, David A. Wheeler: > FYI, I've created a timeline of major Shellshock events here: > > http://www.dwheeler.com/essays/shellshock.html#timeline > > If anyone has corrections or key additions, let me know. [...]
About the discovery.
I discovered it in the morning (UK) of 2014-09-12 and reported it at Fri, 12 Sep 2014 16:10:35 +0100 to Chet, and the security contacts of Debian, Red Hat, Ubuntu and Mandriva (SUSE added later) including details of the bug and the SSH and HTTP (Apache header) vectors and mitigation and a bit fat warning that it was very serious and not to be disclosed.
First patch by Chet at 2014-09-12 16:32:17 -0400, but was easily bypassed. Ensued a discussion on that original list, several patch iterations, whether or not to harden at this point and how, whether or not to output error messages on parsing error, additional vectors, scope, detection methods (IDS...), other affected shells, local privilege escalation?, whether localisation can bypass the fix, the impact of two env vars with the same name, backward compatibility, who to contact early... Of course, I have no visibility of what was discussed internally at Red Hat/Ubuntu/Mandriva...
I suggested the name "bashdoor" on that list on Sun, 14 Sep 2014 14:29:48 +0100.
A release schedule with public disclosure on the 24th at 14:00 UTC and early notification to other unix and linux vendors on the 22nd and select infrastructure provider notification (such as CDNs including Microsoft) on the 23rd proposed on the 16th by Florian.
Chet had patches for the final (before disclosure) fix for the current and all past versions of bash up to 3.0 by 2014-09-16 22:00:02 -0400 (from diff dates)
I was out of the loop after the 19th
bashdoor.com was registered (not by me) with a creation date of 2014-09-24 13:59 UTC sometime before 2014-09-24 06:59:10Z according to whois. Florian also said here that someone brought the early notification sent to vendors/infrastructure to the press, so someone obviously intended to take it to the press. I don't know whom.
To answer the other post. The feature was definitely not in 1.05 nor 1.12 (the source of which can be found on the web), but was in 1.13.5. Chet confirmed (to me and news outlets) that it was added in 1.13.
Cheers, Stephane
The idea of a security bug in a program that allows users to destroy files strikes me as silly. No shell, including bash, was ever originally intended to be executed indirectly by someone who had the ability to manipulate environment variable values. Arguably, the CGI mechanism that allows that is the security issue.
I think characterizing Shellshock as security bug in bash is misleading at best. It's certainly a bug in bash - but what makes the whole thing a security bug is the CGI mechanism, which is utilized only a small percentage of systems that have bash. I suggest the introduction be more clear about this.
The perception out there bash has a security bug is confusing people. They think using bash, in any way, makes them vulnerable. -- В²C ☎ 01:18, 8 October 2014 (UTC)
Again, bash was never intended to be secure - so to say it has a security bug is nonsensical. It's like saying there is a security breach on a public beach. -- В²C ☎ 17:31, 9 October 2014 (UTC)
It is very simple. Bash executes codes that it is not supposed to execute. It fails to properly escape user input allowing an injection attack. This is a security vulnerability in bash by any objective measure. Bash is not behaving as it is supposed to and this is causing severe security issues. The suggestion that bash is not meant to be used in secure environments is contradicted by decades of actual security practice.
I don't mean to be rude but your position seems to lack a basis. Chillum 20:19, 9 October 2014 (UTC)
All I'm trying to say is that there is nothing inherently insecure in using bash in how it is normally used, even if it has this bug in it. Only if you are trying to use bash in a particular way — with the -r option or to execute scripts in a secure environment but in which the environment variables can be manipulated — is there a potential issue. -- В²C ☎ 21:07, 9 October 2014 (UTC)
I am glad that you recognize the issue. Your remaining argument seems to be that bash is not meant to be used in secure environments where users can define environment variables, this is not supported by general practice. Chillum 21:43, 9 October 2014 (UTC)
Bash is a tool - it is not a security tool. The following is a valid bash command. It will remove many if not all files on a system (depending on relevant user/directory permissions).
rm -rf /
I know that it was considered a security issue, because many CGI scripts invoke some bash scripts to produce an output, and there is nothing wrong with that on its own. It allows writing some servers easily, and if proper care is taken for input sanitization it works just fine. It is not that the environmental variables are inherited, or that they should contain values only, and they were not properly parsed, because Bash's PROMPT_COMMAND environmental variable by design allows to run arbitrary commands. The main problem with Shellshock is that when using CGI, all the input headers and URL data are put into HTTP_xyz, QUERY_STRING and PATH_INFO environmental variables. And that is fine too, becasue it is not possible to put stuff into PROMPT_COMMAND for example, and all HTTP servers will ensure that other environment variables are sane (i.e. PS1, or LANG, or HOME, BASH_ENV, etc, and some of these are even ignored when run in 'privileged' mode using bash -p), and there is no direct way to add new or modify existing variables other than the HTTP_xyz ones, which are not going to conflict with any existing variable used by shell. The expectation, and the design of environment variables, is that they just carry some strings, and if they are not used by the shell in any particular way, they shall remain just strings, and not interpreted in any specific way. Bash violated this behavior with this bug. How the bash did had a bug like this is absolutely beyond me.
2A02:168:F609:0:DA58:D7FF:0:F02 (
talk) 19:57, 16 December 2018 (UTC)
The Background section currently has this statement:
I think the "fix" for Shellshock has broken this. You used to be able to do this:
$ x='() {echo in x;}' $ x in x $
That no longer works in versions of bash with the Shellshock fix.
-- В²C ☎ 01:07, 10 October 2014 (UTC)
$ echo $BASH_VERSION ::4.2.45(1)-release ::$ x='() {echo in x;}' ::$ -bash: x: command not found ::$
$ echo $BASH_VERSION ::4.3.28(2)-release ::$ x='() {echo in x;}' ::$ -bash: x: command not found ::$
Hey, PaleAqua! I've just reverted your edit, so please allow me to explain it a bit further. While looking at MOS:SECTIONCAPS and MOS:LCITEMS, they both pretty much boil down to "the correct case should always be retained, even in situations where normal rules would require capitalization". At the same time, I'm not sure that "qmail" is a true registered trademark so MOS:TMRULES would apply? Am I missing something? — Dsimic ( talk | contribs) 01:37, 6 November 2014 (UTC)
Stéphane Chazelas contacted Bash's maintainer...
The name Stéphane Chazelas is introduced without any mention of who he is. Is his name relevant? If so, he should be described in some way, even if it is just "a Unix user". (He is apparently not important enough to have his own Wikipedia entry.) — 91.238.123.116 ( talk) 11:57, 26 November 2015 (UTC)
env X='() { (a)=>\' bash -c "echo echo \$'\166\165\154\156\145\162\141\142\154\145'"; cat echo
The escaped characters, "\166\165\154\156\145\162\141\142\154\145" is ASCII for "vulnerable".
$ echo $'\166\165\154\156\145\162\141\142\154\145'
vulnerable
The dollar substitution converts the backslashes to ASCII, but if we escape the dollar:
echo \$'\166\165\154\156\145\162\141\142\154\145'
$\166\165\154\156\145\162\141\142\154\145
On a vulnerable system:
$ X='() { (a)=>\' bash -c "echo echo \$'\166\165\154\156\145\162\141\142\154\145'"
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
$ cat echo
vulnerable
On a non vulnerable system, it will simply output $\166\165\154\156\145\162\141\142\154\145 instead of date.
Husseydevin ( talk) 17:20, 28 February 2017 (UTC)
The following source is dead. But I found the site in the Wayback archive.
I found the following guide to fix it, but the given template doesn't feel right in the preview - I have no idea how to fix it. /info/en/?search=Help:Using_the_Wayback_Machine
Dead Source:
http://www.futuresouth.us/wordpress/?p=5 [20]
Wayback machine: http://wayback.archive.org/web/20160328232448/http://www.futuresouth.us/wordpress/?p=5
Thank you for your help DopeforHope ( talk) 10:59, 25 July 2017 (UTC)
This hack was done using this vulnerability. Considering how massive this hack was, it could be a good idea to include this in the "Reports of Attacks" section Skyturnrouge ( talk) 06:02, 19 November 2019 (UTC)
The link for the BusinessWeek citation ( http://www.businessweek.com/news/2014-09-30/shellshock-draws-hacker-attacks-sparks-race-to-patch-bug) is dead.
I found a mirror on Bloomberg ( https://www.bloomberg.com/news/articles/2014-09-30/shellshock-draws-hacker-attacks-sparks-race-to-patch-bug), but I do not know how to edit a citation. Could someone more knowledgeable than me with Wikipedia source editing please fix it? Lplawlor ( talk) 23:34, 7 October 2022 (UTC)