Talk:Shellshock (software bug)

Comments

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)

Actually, Red Hat doesn't give it a name at all. The ShellShock name is based on the posting by Troy Hunt. I'll admit to the mistake of the mixed case name. No arguments to moving to Shellshock (computer bug). WikiDan61^ChatMe!_ReadMe!! 19:42, 25 September 2014 (UTC)

Proposed merge with Shellshock vulnerability

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)

No, there are two CVE numbers, CVE-2014-6721 and CVE-2014-7169, so naming the article after one of them is wrong. Shellshock is a good name, since it covers both. Thue (talk) 22:18, 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)

Ideally, this needs following up with a formal merge to bring the page histories together. I propose the following structure:

• Shellshock (software bug) (current page; target for all merges)
  • CVE-2014-6721 (first source of merge)
  • Shellshock vulnerability (second source of merge)

The two sources would then remain as redirects to Shellshock (software bug), potentially also with another redirect at "CVE-2014-7169".

Any objections? — Sasuke Sarutobi (talk) 23:16, 25 September 2014 (UTC)

Logos

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)

The point isn't to document every blip that occurs along the trail, but to wait for the trail to be stable, and document the things that remained notable over time. So, each and every possible logo that has been created within a day of the announcement is really over the top. WikiDan61^ChatMe!_ReadMe!! 21:22, 25 September 2014 (UTC)

Edprevost, you should probably do the sensible thing and delete these "logos" before the entire wikipedia community gangs up on you. There is no way in which these daft pictures are "documenting the history ... like an encyclopedia". Pasicles (talk) 21:34, 25 September 2014 (UTC)

sad panda can we at least get it under the CVE name? Edprevost (talk) 21:46, 25 September 2014 (UTC)

Not understanding the "sad panda" response, but we have now three separate editors who have either reverted the addition of the logos or advised for their removal. Can we assume we have WP:CONSENSUS to remove them? As for the "Simple Proof" figure, also created by Edprevost (talk · contribs), this appears to be a screenshot off of his own Linux box, so we really have only his word that this is any valid evidence of anything, making for more WP:OR. I tried to remove this, but was reverted, with an accompanying note at my talk page. WikiDan61^ChatMe!_ReadMe!! 21:54, 25 September 2014 (UTC)

I was expressing an emotion WikiDan61, my apologies. I removed the logos. As for the exploit image, to better understand it, and the attack, please see CVE2014-7169 Edprevost (talk) 22:15, 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)

The testing section in text actually allows you to cut and paste the tests. Which you need to do if you want to test your own locally installed Bash. Also, text is always better than equivalent image, because you can manipulate it easily. Thue (talk) 22:36, 25 September 2014 (UTC)

WikiProject banners

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)

Protection or review process?

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)

Section about CVE-2014-7169 vulnerability details

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)

I just fixed it. The rest of the section appeared to have been based on the incorrect example that was there before, so I just deleted that part. I'm not sure what was meant by the sentence "The consequences are identical to the original CVE-2014-6271 vulnerability". ~User:chridd [[tʃɹɪː|Special:Contributions]] 01:49, 26 September 2014 (UTC)

The HELLO_WORLD_VAR example is still broken; the way it stands, `HELLO_WORLD_VAR=() { ...` will define `HELLO_WORLD_VAR` to be `()`, and throw syntax error on the rest of the line. The content of the variable should be quoted.136.187.146.174 (talk) 07:05, 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)

Are you saying that that shows that csh has the vulnerability? It doesn't look that way to me; csh is echoing "date", as it's supposed to, and not executing the "date" command like bash is doing. The file "echo" still exists from when you exploited the vulnerability in bash (and, just to be sure csh wasn't creating the file again, I ran the command on my own computer; no new files were created, and there's still no "echo" file). ~User:chridd [[tʃɹɪː|Special:Contributions]] 02:17, 26 September 2014 (UTC)

Gotcha I see my mistake now, I would delete the file then run bash to check the system was patched and then immediately run the command in another shell. Edprevost (talk) 02:26, 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)

The question is, on what academic grounds are you qualified to assert that this code snippet represents the bug in question. Wikipedia has a standard of verifiability that requires that facts such as this be cited to reliable sources. Creating your own knowledge and inserting it into articles is considered original research and is disallowed. Whether or not you are a recognized authority, the material must first be published in a source where proper editorial or peer review is in place before it can be asserted here at Wikipedia. Dem's da rulz, like 'em or not. WikiDan61^ChatMe!_ReadMe!! 13:24, 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)

@Edprevost: If examples are taken from sources, cite the sources. But the discussion in this section implies that you and chridd are tweaking code to reproduce the bug, which would be original research. I don't doubt your expertise in this area, but Wikipedia has rules about publishing original research. Your code snippet, if not previously published in a reliable source as an example of this bug in action, is not verifiable, and has no place. WikiDan61^ChatMe!_ReadMe!! 13:35, 26 September 2014 (UTC)

Please see the references Edprevost (talk) 13:47, 26 September 2014 (UTC)

The article has many references. From which reference did you pull the particular code snippet in question? WikiDan61^ChatMe!_ReadMe!! 13:52, 26 September 2014 (UTC)

Please see [3] Edprevost (talk) 18:45, 26 September 2014 (UTC)

Requested move 25 September 2014

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

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)

This is a contested technical request (permalink). Steel1943 (talk) 21:40, 25 September 2014 (UTC)

• Shellshock (or "Shell Shock") is used by The Register, Red Hat, Troy Hunt QVVERTYVS (hm?) 20:00, 25 September 2014 (UTC)
• Shellshocked is what the researcher who found it, named it securityblog.redhat.com/tag/shellshocked/Edprevost (talk) 20:05, 25 September 2014 (UTC)

The researcher tagged the post as "shellshocked", never named it in the article itself. In my interpretation, he was shocked by the shell behaviour, thus "shellshocked" tag as an adjective, describing his state of mind, not naming the vulnerability.136.187.146.174 (talk) 07:09, 26 September 2014 (UTC)

• Really it should be CVE-2014-6271 as the title, then have the various names. Edprevost (talk) 20:15, 25 September 2014 (UTC)

• Oppose - We use common names and not official names for article titles. I doubt many outside the tech/security arena would use CVE-2014-6271. If news articles are using Shellshock and ShellShock, then that is more likely to be the common name then Shellshocked. That said it might be better to name this Shellshock (security bug) as it would be a little more precise. PaleAqua (talk) 04:54, 26 September 2014 (UTC)
• Oppose - FWIW - seems the New York Times, a worthy representative of the news media, is using the term "Shellshock" software bug - see < ref name="NYT-20140925-NP">Perlroth, Nicole (September 25, 2014). "Security Experts Expect 'Shellshock' Software Bug in Bash to Be Significant". New York Times. Retrieved September 25, 2014.</ref> - same as the name of the present article - maybe good enough for now? - in any case - Enjoy! :) Drbogdan (talk) 11:59, 26 September 2014 (UTC)
• Oppose - It's there even when there is no apparent security risk and it can potentially cause software to run incorrectly when there is no malicious intent, irrespective of the security risks. Sparkie82 (t•c) 19:37, 26 September 2014 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Section "Log parsing"

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)

In an edit comment, Chillum said: "I cannot think of even on log parser that stores log entries in bash variable. Citation really needed"

Where do you store line/field data from logs in your Bash scripts? I can't think of a single IT guy with any experience who doesn't use Bash to write quick scripts to scrub or sift logs. Google quickly yielded four examples: http://unix.stackexchange.com/questions/58550/how-to-view-the-output-of-a-running-process-in-another-bash-session http://stackoverflow.com/questions/6143838/bash-script-log-file-display-to-screen-continuously http://mesastar.org/tools-utilities/python-based-stuff/history-log-scrubber/view http://oclug.on.ca/archives/oclug/2005-January/043294.html

And as I said, this clearly falls under WP:IAR. If you want to change the section name/scope to a more general title like offline processing or something like that, go ahead. Sparkie82 (t•c) 17:36, 27 September 2014 (UTC)

I don't think it should be included without a source showing it exists. I could make 50 sections right now based on vulnerabilities that might exist in home made scripts. While IAR does allow you to ignore the rules to improve or maintain Wikipedia I believe the inclusion of original research does not improve or maintain Wikipedia.

If this is a real concern then you should be able to find a security expert describing it. While there are many venues where a potential vulnerability that you thought up are very appropriate and encyclopedia is not one. We should not create new information, we should document information already created by reliable sources. Chillum 17:41, 27 September 2014 (UTC)

+1 The article will start becoming a beastial collection of every possible attaakck, and with a compromised shell, that is quite literally anything the system can do. Ed Prevost profile|contributions — Preceding undated comment added 18:04, 27 September 2014 (UTC)

I understand the rule and why we have it. However, if every bit of OR on WP was removed, WP would only have a 1/3 of the information it has -- especially in articles on software and technology. We could change the scope of the section to discuss, generally, how the bug effects machines running offline with examples of how that works. Those examples could be backed up with cites from programming reference sources. Sparkie82 (t•c) 18:03, 27 September 2014 (UTC)

As it is now, it is incorrect to give the impression that the bug only affects machines connected to the internet. Sparkie82 (t•c) 18:06, 27 September 2014 (UTC)

As a security expert, I wouldn't expect an exhaustive list here. Instead, I would anticipate a detailed description of how the vulnerability works, so I could go and test it in various scenarios. I think the opening and other portions ofy the article demonstrate clearly that it' not limited to internet connected systems only. Ed Prevost profile|contributions 18:11, 27 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)

If we are ok with the current edit, I'll remove the cite and OR. Agreed? Ed Prevost profile|contributions 18:35, 27 September 2014 (UTC)

Yes I don't think they apply anymore and I have removed them. Generally these templates go after the disputed text and not in the section header. Chillum 18:46, 27 September 2014 (UTC)

Noted, thanks for the help and education Chillum Ed Prevost profile|contributions 18:51, 27 September 2014 (UTC)

To summerize and close the loop on this older discussion: I wanted an exception to the OR rules to include some info I thought important to include in the article. Others disageed. End of discussion. Sparkie82 (t•c) 22:30, 7 October 2014 (UTC)

CVE-2014-7186 and CVE-2014-7187

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)

Why are these vulnerabilities being added to the Shellshock article? They are not vulnerabilities in the function export mechanism, nor does the source cited to connect them actually do so that I can see. 50.185.134.48 (talk) 20:54, 27 September 2014 (UTC)

They are related, according to the reporter, Red Hat, but the specifics of the relationship hasn't been disclosed in detail yet see Red Hat Holding For release Ed Prevost profile|contributions 21:00, 27 September 2014 (UTC)

Tidy-up

It's natural for a fast-moving topic like this to result in a article that's messy - but can we start tidying up?

• Think about structure - looking at Heartbleed a "History" section might be useful
• The "shellshocker" site link is inappropriate, given that we have many authoritative sources
• Quoting text straight from "...email addressed to the oss-sec..." is a Primary Source

Snori (talk) 09:04, 27 September 2014 (UTC)

About shellshocker.net's red link

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)

 Done - yes - agreed - adj to italics - at least for now - hope this helps - Enjoy! :) Drbogdan (talk) 13:07, 28 September 2014 (UTC)

How the bug works, rewrite section

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. This allows remote attackers to execute arbitrary code via a crafted environment.

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 was removed with the edit. Sparkie82 (t•c) 17:28, 28 September 2014 (UTC)

I think this is a good change, and much better than the old section. I like breaking it up into the export and the bash call, as you've done, rather than just displaying the whole exploit as a single block. We may want to include a full example for the first CVE, but I'm not opposed to using that format for describing the other CVEs. The description is much better than what was there as well. IRW0 (talk) 19:28, 28 September 2014 (UTC)

Selfpub sources and tag

@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)

Actually, I tagged it rather than removing the cites myself because I didn't want to get into a bunch of pissing matches here. Just refer to WP:RS. Good luck. Sparkie82 (t•c) 19:52, 28 September 2014 (UTC)

The difficulty here is that it is very common within the security community to use mediums of communication, typically considered unfit for wiki references. Consider that almost all of this information has come from blogs and mailing lists, to date. My argument is Occamian, lets keep these references, and then update them as things mature and progress to more vetted publications. Ed Prevost profile|contributions 12:58, 29 September 2014 (UTC)

This is true, and needs to factor into our RS evaluation. It's okay if we're missing some information until more sources cover it, since those who want to know more technical detail can find it on the web. We may be able to add some blog sources that meet the last point of WP:USERG to make the material properly referenced. Mailing list sources and original research aren't really great, though. IRW0 (talk) 00:20, 1 October 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)

per Ericblake

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)

If you're going to nuke ACCURATE references to the actual source code commit date while waiting for a periodical publication to pick up on it, at least please ALSO nuke the INACCURATE 1992 date. The design flaw dates back to 1989, whether or not journalists care about the specific date. Ericblake (talk) 22:40, 6 October 2014 (UTC)

Feel free too, I lekely didn't see it. Ed Prevost profile|contributions 00:19, 7 October 2014 (UTC)

Shellshocker.net

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)

What sort of "write up"? I don't think it provides any information the article lacks, and I'm not comfortable including it as an external link, especially since at the very top it states: "curl https://shellshocker.net/fixbash | sh". Encouraging users to pipe the output of a script from a random remote server into a shell is a really fucking bad idea, especially when you're trying to fix a vulnerability, so directing Wikipedia users to such a site is harmful.

Additionally, I notice that your IP address is located in Fort Wayne, IN, where the company hosting shellshocker.net is based, and the only contributions you've made have been to add shellshocker.net to the article. (As the "official" site, even though the domain wasn't created until the day after the bug was released from embargo.) While I'm not accusing you of anything, you can see why that might be suspicious. IRW0 (talk) 22:38, 28 September 2014 (UTC)

I had actually added the shellshocker.net section to this article, only for the sake of quick access while the article was developing, as it had more information than the article did at the time. I do agree, regardless of the intentions of {u|184.19.8.213} that, this is not an appropriate source for this article. At least not to the degree that it should have it's own section. Ed Prevost profile|contributions 12:46, 29 September 2014 (UTC)

Shellshocker.net has an example of CVE-2014-6278 and a patch for it as well, this wikipedia article still has no information on CVE-2014-6278. Right now developers and system administrators are trusting shellshocker.net as the primary source for updated information about ShellShock. The GitHub repo is updated several times daily with new tests, fixes, etc. 64.186.39.3 (talk) 18:25, 30 September 2014 (UTC)

Others, and I have seen this, but there is no authoritative reference for what they are claiming is the actual issue being held behind that particular CVE. Do you have another reference? Ed Prevost profile|contributions 18:36, 30 September 2014 (UTC)

The IP 64.186.39.3 is registered to "MEDICAL INFORMATICS ENGINEERING, INC.", who run shellshocker.net. It's appropriate to mention that you are affiliated with a site when you're suggesting its inclusion in an encyclopedia article. (Please read the conflict of interest policy if you have not.) In any case, we would need a reliable source to state that people are trusting this site as you claim, and that it is the "primary source" of information about Shellshock. The site itself is a potential security problem, as noted above, so it also cannot be included as the external links policy prohibits malicious scripts and similar. (And the site fails the EL policy on several other grounds.) IRW0 (talk) 23:53, 30 September 2014 (UTC)

Also, you are of course welcome to add information about CVE-2014-6278 (or anything else you think is missing), since the article is open to editing by anyone. Rather than just suggesting we link to a site, adding that info to the article is the best way to help out! (Just keep in mind that reliable sources need to be cited.) IRW0 (talk) 04:57, 1 October 2014 (UTC)

Mediawiki affected?

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)

No. However, wikipedia, and any other software running on a system that uses a vulnerable version of bash could potentially be leveraged by an attacker as, IRW0 notes below. Ed Prevost profile|contributions 12:51, 29 September 2014 (UTC)

In the MediaWiki source, "includes/GlobalFunctions.php" calls bash in a widely used "wfShellExec()" function, which you could potentially get at by uploading an image or other things. Whether or not MediaWiki is vulnerable itself isn't the right question, but it is a potential attack vector with a vulnerable version of bash. IRW0 (talk) 13:18, 29 September 2014 (UTC)

Thanks. That was what I meant, in my sloppily-phrased way. 194.176.105.153 (talk) 17:54, 29 September 2014 (UTC)

Should that function specify usage of Korn shell or TCSH instead (or plain old sh ?) ? -- 65.94.171.225 (talk) 20:35, 30 September 2014 (UTC)

Specific exploitation vectors

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 agree, it's too complicated, poorly unreferenced, and unnecessary. We can summarize and condense the web/CGI, SSH, and possibly DHCP examples, since those are being widely reported, but the last two are kinda just givens. (If we mention setuid is a problem, we'd have to mention it's an issue if a program is just running as root without being setuid, and other obvious stuff like that.) IRW0 (talk) 16:04, 29 September 2014 (UTC)

I've reworked it, please review. Ed Prevost profile|contributions 16:14, 29 September 2014 (UTC)

I disagree. The section needs to be expanded not condensed. Privilege escalation is a local vulnerability which exists independently and needs to be mentioned. It's not a given - supplying arbitrary environment variables shouldn't cause arbitrary code execution. There are known-dangerous environment variables (PATH, SHELLOPTS etc) but shellshocked makes **any** variable passed to a setuid binary dangerous, even previously "known harmless" ones, when they need not be and are not under e.g. dash or any other posix shell. Ben@liddicott.com (talk) 12:30, 30 September 2014 (UTC)

We already had consensus on this topic, previously. The general feel was that the section would have to list every potential conduit, and isn't really the scope of this article, perhaps there is a List of exploitation types that we could link to? But this int a list article. Ed Prevost profile|contributions 15:00, 30 September 2014 (UTC)

Ben@liddicott.com and I do not consent to this change, so clearly there is no actual consensus. I'm reverting those changes and following WP:BRD. Also, the idea of discussing something for a couple of hours and then claiming consensus is improper. Many editors only check in at wikipedia every other day of so or even less frequently. This is particularly the case for this article as many of us have been working OT on addressing this bug in real life, so please give everyone time to contribute to the discussion and actually obtain consensus before claiming consensus. Sparkie82 (t•c) 18:53, 1 October 2014 (UTC)

A full discussion of the exploitation vectors in that section is essential to this article. Readers need to be given a complete explanation of how the bug is exploited. To say that the section may get to big is not the as it "being" too big. I suggest we change the name of the section to Exploitation vectors, so editors don't try to expand it with a bunch of specific examples. Then I suggest subsectioning it into broad categories like; offline exploits, web services, and other application layer exploits. (We can discuss the exact subsections.) Then within each of those subsections there can be explanations of how the various types of exploits work. Sparkie82 (t•c) 18:53, 1 October 2014 (UTC)

I also agree too much was trimmed with the original change (and hoped some bits would've been fleshed back out more by now.) I'm opposed to the escalation of privilege and offline vulnerabilities, because they're too vague (would be WP:UNDUE without listing even more theoretical vulnerabilities) and possibly unreferenceable. I'm okay with having separate CGI/SSH/DHCP sections if we have sufficient text to flesh them out. IRW0 (talk) 20:16, 1 October 2014 (UTC)

I'm still of the opinion that it would be better to start a list, or locate one and point to it from here, even if we pointed to sections of it. Otherwise it'll just be a big chunk of OR prose. Ed Prevost profile|contributions 20:56, 1 October 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)

This is my point. Any listing should be verifiable and not a bunch of speculative OR... which is where the list is currently headed. Ed Prevost profile|contributions 15:14, 2 October 2014 (UTC)

"That said we do not need to cover all; such a list would be impossibly long." Prove it. IRW0 listed three: CGI, SSH, and DHCP. Prove that a full list would be "impossibly long." Sparkie82 (t•c) 01:05, 3 October 2014 (UTC)

I think what PaleAqua, IRWO and myself are saying is that an error such as this, at such a granular level within day-to-day operations, touches on hundreds of possible points of exploitation. I still think a separate list of verified paths is needed. So, as you asked, on a typical AWS EC2 instance, bash could interact with or from an invocation of:

— a long list of commands from Amazon's EWS —

cp l. ll ls mv rm which . : [ alias bg bind break builtin caller cd command compgen complete compopt continue declare dirs disown echo enable eval exec exit export false fc fg getopts hash help history jobs kill let local logout mapfile popd printf pushd pwd read readarray readonly return set shift shopt source suspend test times trap true type typeset ulimit umask unalias unset wait if then else elif fi case esac for select while until do done in function time { } ! [[ ]] coproc cp l. ll ls mv rm which if then else elif fi case esac for select while until do done in function time { } ! [[ ]] coproc . : [ alias bg bind break builtin caller cd command compgen complete compopt continue declare dirs disown echo enable eval exec exit export false fc fg getopts hash help history jobs kill let local logout mapfile popd printf pushd pwd read readarray readonly return set shift shopt source suspend test times trap true type typeset ulimit umask unalias unset wait findfs vgscan start_udev audispd halt auditctl telinit e2undo fsfreeze wipefs installkernel vgrename vgimportclone insmod vgcreate service lvmdump sln ipmaddr install-info lvmconf lvresize mkbootdisk dmevent_tool nologin lvreduce logsave depmod dumpe2fs auditd dump vgreduce restore mkinitrd bridge faillock rmt cbq mkfs.cramfs pvck fuser chkconfig lvs restart ldconfig sysctl switch_root pwhistory_helper rdisc dmraid kexec mkswap mkfs.ext4 ifdown new-kernel-pkg modprobe ec2udev-vbd cfdisk reboot blkid accton fsck.ext3 pvscan e2fsck sfdisk vgexport ausearch dhclient ip6tables ether-wake losetup mii-diag quotacheck addpart tc clock dmeventd mkfs.ext2 restorecon vgconvert rdump debugfs fstrim ifenslave udevd modinfo ifcfg vgmknodes mke2fs fsck.ext4 chcpu swapon lvremove pivot_root ppp-watch lsmod ifup pam_timestamp_check resize2fs init blkdeactivate pvcreate rtmon killall5 shutdown lvscan pvremove fsck.ext2 cryptsetup lsinitrd plipconfig partx fsck.cramfs ip mkfs swapoff ip6tables-restore badblocks dmraid.static vgremove cgconfigparser autrace initctl pvs aureport xtables-multi grubby rsyslogd iptables-save ctrlaltdel consoletype sulogin lvmchange ethtool kdump mdadm rtpr e2image vgsplit securetty routef dm_dso_reg_tool lvcreate blkdiscard route rmmod pidof pvmove ifconfig fdisk delpart pam_tally2 lvextend rrestore dhclient-script pvchange unix_update unix_chkpwd lvmsar pvresize vgextend kpartx tune2fs lvmetad lvdisplay slattach fsck vgcfgrestore vmcore-dmesg cgrulesengd status blockdev agetty mingetty sgpio reload genhostid iptables arp lvmdiskscan fixfiles e2label vgcfgbackup mii-tool dracut mkfs.ext3 fstab-decode sushell weak-modules mkdumprd start udevsettle iptunnel setsysfont hwclock mkhomedir_helper netreport vgs MAKEDEV poweroff ec2udev-vcpu runuser busybox runlevel lvrename nameif stop lvmsadc quotaoff setfiles routel vgchange udevadm load_policy setkey pam_console_apply vgimport cgclear ip6tables-save fsadm mdmon change_console mgetty getkey lvconvert dmsetup arping iptables-restore quotaon lvchange vgck augenrules vgdisplay lvm pvdisplay vgmerge false cp iptables-xml ksh cpio dbus-uuidgen gettext netstat lscgroup awk mount dmesg unicode_stop gawk cut findmnt date bash egrep lsblk ln dbus-monitor dbus-cleanup-sockets df cgget touch dd ls chown rview mountpoint umount vi chgrp loadkeys nano cgexec gunzip rnano cat lssubsys cgclassify sh ipcalc sed zcat rmdir basename mknod pwd ping6 csh dbus-daemon gzip ping usleep cgset dbus-send ex fgrep ypdomainname env red rm mailx ps domainname raw tar mktemp dnsdomainname arch find cgcreate cgsnapshot su taskset unicode_start echo mail tracepath rvi setfont nice tracepath6 view kill traceroute mkdir dumpkeys unlink rpm cgdelete ed grep uname nisdomainname login sort chmod tcsh stty hostname more link traceroute6 readlink mv sync setserial kbd_mode true gtar ksh93 dash sleep rtcwake ntpdc tcpdmatch ctstat addgnupghome run_init tcpdump adduser tickadj raid-check insmod mkfs.minix racoonctl ss rdistd ntpdate rngd zic update-motd thin_restore rtstat fsck.minix usernetctl getsebool depmod e4defrag zdump nstat update-alternatives authconfig-tui makedumpfile sshd-keygen fdformat cache_check filefrag crond cache_repair yum-updatesd capsh ntp-keygen ntpd iconvconfig.i686 groupmems faillock iconvconfig tcpd httpd anacron pwhistory_helper lchage hardlink yum-complete-transaction modprobe cracklib-check swaplabel useradd luseradd praliases logrotate accton conmand ldattach acpid e2freefrag cc_dump saslpasswd2 pwck racoon usermod chroot arpd t1libconfig matchpathcon setenforce thin_check restorecon ping6 chpasswd iptstate pluginviewer newusers genhomedircon seunshare modinfo rotatelogs create-cracklib-dict htcacheclean lsof lsmod ntpq pam_timestamp_check setsebool irqbalance vipw sntp httpd.worker sys-unconfig grpunconv krb5-send-pr sendmail.sendmail pwunconv ntsysv groupdel testsaslauthd thin_metadata_size uuserver lnstat readprofile quotastats convertquota setcap cache_dump glibc_post_upgrade.i686 avcstat cacertdir_rehash packer togglesebool vigr getenforce gss-server resizepart httpd.event sulogin thin_rmap ethtool visudo lgroupdel sa suexec cc_test grpck accessdb mklost+found plainrsa-gen ifstat cracklib-format rmmod yumdb semodule userdel selinuxdefcon tracepath tcpslice pam_tally2 cracklib-packer callback unix_update tracepath6 unix_chkpwd build-locale-archive httxt2dbm apachectl getcap mksock selinuxexeccon dump-acct sestatus open_init_pty grpconv thin_repair mkdict sshd groupmod fixfiles applygnupgdefaults repquota genl weak-modules makemap groupadd saslauthd smrsh sendmail edquota thin_dump hwclock mkhomedir_helper sserver ntptime lpasswd getpcaps tmpwatch safe_finger setquota mailstats try-from selinuxconlist rtacct pwconv luserdel ccreds_chkpwd sasldblistusers2 lid setfiles selinuxenabled lusermod load_policy pam_console_apply authconfig cracklib-unpacker clockdiff quota_nld rpc.rquotad arping cache_restore sim_server lgroupadd atd lgroupmod lnewusers dump-utmp atrun alternatives strace-log-merge gss-client grap2graph callgrind_annotate intltoolize cg_annotate kibitz prlimit mysql linux64 symlinks aulast clean-binary-files msgattrib find-jar gzexe vdir pr rsync mkpasswd whiptail fipscheck openssl yum-config-manager head ksu klist elbadmin msgfmt ipcmk ruby rpmspec sqlite3 gettext semodule_deps eu-stack troff eu-size glib-compile-schemas cvsbug cheetah tfmtodit dislocate xzgrep db_dump setleds ltrace awk mysql_secure_installation pygmentize pre-grohtml uuidgen autoheader setmetamode ptargrep gcore cc grolbp tzselect cfadmin pod2usage gpic sdbadmin ftp-rfc gawk c++filt repo-graph eu-ranlib nohup rdistd editdiff build-jar-repository setup-nsssysinit kill_instance lua podselect whereis makedb h2xs db_upgrade instmodsh bzcmp id rlogin-cwd callgrind_control znew h2ph split pgawk build-classpath getkeycodes numastat timed-run luac latrace-ctl mysqld_multi diff-jars flex++ checkmodule xzmore gdb-add-index lchsh pdfroff semodule_expand cut infotocap dwp markdown_py tput lzfgrep bzgrep svnrdump nail cscope-indexer mmd bzip2 sha384hmac g32pbm gpg-zip lzdiff htdbm whatis as psfstriptable chage chacl tail ipcs fsfs-reorg grefer ssh-keyscan policytool6 espdiff eu-strip gfortran pgrep cpanp sechecker pinentry apropos conman setarch podchecker semodule_unpackage msginit myisam_ftdump stat eqn dynamodb_load compile_et stapsh kswitch lss3 lzmainfo mpartition mdeltree pl2pm cmsutil getent gsoelim xzcat tr gcov48 perlthanks aclocal swig bzless build-classpath-directory show-installed renice info psfxtable sftp rebuild-jar-repository zegrep free a2p ldd mysql_zap sudoreplay resolve_stack_dump gmake instance_events grolj4 fsfs-access-map preconv replace resolveip svnadmin fc-cat sha256hmac rpmverify grodvi repodiff gettext.sh slabtop byacc tclsh sclient dbiproxy mountpoint update-mime-database expand pod2texi rev zipsplit autoscan db_recover rmid hostid soelim killall sotruss nsupdate fipshmac sha256sum ac groups setfattr ranlib lwp-download rmid6 svnversion zipdetails showkey seq erb purgestat uuclient slogin rediff yum bzdiff batch tty python2.6 zforce vimdiff s3put msgcmp ktutil svnserve pod2man script weather reset objdump pic getopt innochecksum s2p printenv gettextize lexgrog fc-query setfacl xargs zipcloak nano my_print_defaults htpasswd shasum stdbuf oldrdist pyrsa-sign pstack cloud-init-per envsubst eu-elflint sha384sum eu-unstrip mesg cytune prtstat rmail gdiffmk expect erb1.8 sha1sum pkill bison lwp-request dtrace lddlibc4 lchfn semodule_link ld.bfd cheetah-compile gneqn cq lsattr nroff pstree skill fc-cache cmp ld.gold zless ccache-swig xmlcatalog isohybrid mrd ms_print gunzip flex migratepages sprof eu-ar ipcrm nc rnano rdist lkbib dbus-binding-tool json_pp mkhybrid stap mysqlbinlog eu-make-debug-archive gindxbib nm recode-sr-latin libtoolize lzless timed-read yum-debug-dump gcc48-ranlib unpack200 intltool-update which xzcmp xmllint msggrep mtools mysql_fix_extensions mcomp rpm2cpio c++48 uniq resizecons unxz git-upload-archive eject zipinfo mysqladmin latrace debuginfo-install gencat recountdiff autoupdate rebuild-security-providers run-parts get_module timeout rftp numfmt asadmin pod2html db_dump185 lookbib perl5.16.3 gpgconf mailq.sendmail cpan2dist pack200 xkibitz ruby1.8 zcat mysqlhotcopy mysql_upgrade cloud-init-cfg mkfifo mysql_convert_table_format python lzcat pkg-config i686-amazon-linux-gcc-4.8.2 eqn2graph unbuffer pstruct ssh-copy-id gethostip rngtest show-changed-rco zipgrep catman mysqldump gnroff update-ca-trust urlgrabber svn zipnote sha512sum isodebug getfattr stap-report fetch_file gtroff xz find2perl xxd memhog gpg-error zcmp test tac mapscrn psed strace migspeed strip geqn pack2006 post-grohtml nsenter mkmanifest xzegrep rcsmerge mysqlshow linux32 autoexpect libnetcfg orbd gcov setsid gcc48 dbiprof rpmdb gzip ptardiff c++ ctags intltool-merge bunzip2 lex tbl mcopy yes unshare isodump chfn write GET dc lzmore pod2latex perlbug mcat getfacl isosize cscope yum-groups-manager tgz valgrind addr2line vmstat yum-debug-restore perror git-upload-pack keytool svnlook java6 pyrsa-encrypt-bigfile cwutil numactl infokey rpmquery peekfd ci gpg-agent mdel lzcmp repotrack nl gdbus mysql_config comm uptime shred hexdump ex svn-bench objcopy manpath findcon gpg-zip2 newgrp logname i686-amazon-linux-c++48 mshowfat prove dig reposync rpmbuild taskadmin lzgrep chrt passmass phar gcc48-c89 refer psfaddtable corelist time env join autopoint fold less lslocks htdigest setterm at lesspipe.sh gcc48-ar rpmkeys launch_instance attr repo-rss lsdiff phar.phar memdiskfind sha512hmac sesearch atrm unpack2006 pmap hpftodit db_archive combinediff modutil rcs gcc48-nm pwmake who ntpstat msgmerge fgconsole db_deadlock tic pwscore automake-1.13 gpasswd msgexec mxtar flipdiff [ replcon cvs ssh-keygen mcheck dbilogstrip sum xsltproc msql2mysql rcsclean git-shell md5sum mysql_setpermission vgdb gcc48-c99 sediff passwd minfo cksum grn kdestroy valgrind-listener gtbl sudo patch svnsync unexpand staprun gsettings newaliases.sendmail diffstat list_instances hoststat db_stat chvt servertool factor mmount glacier numademo mzip install msgconv rename berkeley_db_svc g3cat snice g++48 vim signtool paste rmiregistry6 Mail aulastlog mailq splitdiff orbd6 curl pax pwdx eu-readelf lpunlock find glookbib pyami_sendmail ssltap lessecho merge loadunimap rcsfreeze pitchplay deallocvt php-cgi readelf mysqlbug i686-amazon-linux-gcc48 kpasswd tailf zip secon bzip2recover bashbug-32 db_checkpoint python2 open msguniq php tee wall autom4te pldd libtool getconf repoclosure grops semodule_package look showconsolefont file flock pathchk m4 indexcon stap-prep xsubpp mlabel ausyscall cloud-init intltool-prepare yacc doxygen i386 eu-findtextrel tload tabs tnameserv gpgsplit myisampack pystache procmail db_load mysqlimport mysql_tzinfo_to_sql sedismod easy_install gstack catchsegv get_reference_source mformat idn zfgrep afs5log cpan mcookie stapdyn logresolve wget indxbib setkeycodes sudoedit gendiff col mdir funzip eu-elfcmp utmpdump keytool6 i686-amazon-linux-g++48 interdiff xzdec ssh-agent column certutil mysqlcheck printf truncate gpgv aclocal-1.13 quota find-repos-of-install krb5-config zdiff expr route53 grotty gpg xmlwf db_codegen servertool6 msgunfmt cpanp-run-perl od msgen gdb bzcat gprof crontab du mysqld_safe pic2graph myisamchk fc-scan perldoc unwrapdiff mdu xzless kill zsoelim bzmore needs-restarting fc-list tnameserv6 msgfilter ident base64 xzdiff watchgnupg conmen mailstat clear db_printlog pyrsa-decrypt-bigfile genisoimage gpgparsemail gpg2 autoreconf mysql_install_db lz lzegrep ab mysqltest f95 check-binary-files indent easy_install-2.6 lzmadec ifnames mysqlslap iconv eu-addr2line mattrib git pk12util intltool-extract mclasserase host uz quotasync cheetah-analyze wdctl rcs2log checkpolicy gpgsplit2 mysqlaccess cg_merge lesskey kvno chcon markdown_py-2.6 msgcomm db_verify texi2any diff3 pyrsa-keygen repoquery ssh ssh-add eu-nm captoinfo auvirt seinfo zmore co jvmjar size dircolors kbdrate fsfs-stats formail mysql_waitpid rhino newaliases gpg-connect-agent setpriv stap-merge mren lwp-dump sdiff ptx lscpu mbadblocks isoinfo g++ lwp-mirror sg makeinfo tclsh8.5 piconv eu-strings colrm neqn signver colcrt bundle_image ocs atq makemap unzipsfx rpcgen amuFormat.sh kmod yumdownloader scp ul p11-kit w ar infocmp oldfind perl localedef i686-amazon-linux-gfortran48 myisamlog gpgv2 verifytree xgettext setup-nsssysinit.sh cpp locale pyrsa-priv2pub rmail.sendmail dehtmldiff systool xzfgrep readmult automake chattr cal acpi_listen c89 fixcvsdiff fmt diff users isovfy tmpwatch eu-objdump svndumpfilter rcsdiff phpize lzma strings java vimtutor make pystache-test pydoc2 pydoc2.6 mcd pinky realpath svnauthz lastlog c99 gcc mysqldumpslow dirname nproc pstree.x11 unzip HEAD pinentry-curses package-cleanup filterdiff ionice crash perlivp readlink python26 elfedit pyrsa-decrypt kinit repomanage man fallocate rmiregistry mysql_fix_privilege_tables cpp48 igawk rvim pyrsa-encrypt tsort psfgettable openvt create-jar-links last unlzma pod2text kadmin valgrind-di-server sha224sum lastcomm runcon fc-match crlutil toe ptar pydoc msghack syslinux mtoolstest lockfile csplit config_data yum-builddep shuf testrb1.8 sedispol dir ld logger bc db_hotbackup watch mturk groff tset wc POST addftinfo dynamodb_dump pyrsa-verify mysql_find_rows cg_diff mandb grepdiff c2ph namei mmove chsh pfbtops splain testrb k5srvutil mtype ngettext gfortran48 whoami lastb sha1hmac aserver gio-querymodules-32 zgrep git-receive-pack sim_client top rlog scriptreplay autoconf nslookup msgcat mkisofs rds-create-db-snapshot iam-instanceprofiledel elb-create-lb iam-instanceprofilelistbypath iam-userlistcerts ec2-cancel-export-task ec2-reset-snapshot-attribute ec2-describe-instance-status ec2cim ec2-delete-route-table rds-describe-orderable-db-instance-options ec2dnicatt as-describe-auto-scaling-groups ec2-describe-vpc-attribute iam-grouplistusers ec2dvpc ec2-create-route ec2rnicatt ec2rsnapatt ec2udi iam-userdelcert iam-servercertupload as-create-or-update-tags iam-grouplistbypath ec2dxt ec2-describe-spot-price-history ec2csir mon-cmd ec2-detach-volume rds-create-option-group ec2-create-snapshot ec2-revoke ec2dsnapatt ec2gpass ec2-describe-account-attributes ec2-create-reserved-instances-listing ec2-run-instances ec2-resume-import ec2-create-vpc iam-userenablemfadevice mon-describe-alarms elb-describe-instance-health as-exit-standby elb-delete-lb-listeners ec2-create-vpc-peering-connection ec2-delete-bundle rds-remove-option-from-option-group ec2-describe-conversion-tasks ec2-describe-network-interfaces ec2-bundle-instance ec2-migrate-manifest elb-delete-lb ec2detvol mon-set-alarm-state ec2rinatt ec2-delete-disk-image ec2apcx ec2dinatt ec2-describe-group ec2mri rds-add-source-identifier-to-subscription ec2cxt ec2reboot ec2dpgrp ec2-delete-vpn-connection-route rds-restore-db-instance-from-db-snapshot mon-delete-alarms ec2datt ec2-describe-availability-zones ec2minatt ec2-delete-subnet ec2dvs ec2digw rds-delete-option-group rds-modify-db-subnet-group rds-create-db-security-group rds ec2-create-keypair ec2-modify-vpc-attribute iam-groupaddpolicy rds-delete-db-instance elb-create-lb-policy ec2drim ec2-delete-network-acl iam-servercertgetattributes rds-describe-db-log-files elb-detach-lb-from-subnets as-version as-describe-adjustment-types ec2-purchase-reserved-instances-offering ec2-associate-dhcp-options ec2-disassociate-route-table ec2dsnap cfn-elect-cmd-leader ec2attigw rds-authorize-db-security-group-ingress ec2cbun as-describe-termination-policy-types rds-describe-db-parameter-groups ec2-download-bundle ec2reladdr ec2delvpn iam-usermodloginprofile ec2-create-vpn-gateway ec2addvol ec2-delete-dhcp-options ec2apip ec2addsnap rds-promote-read-replica ec2attvgw ec2delnae ec2fp ec2dimatt ec2-create-vpn-connection-route ec2-attach-volume as-describe-policies ec2ivol rds-describe-events iam-userdelloginprofile ec2-create-subnet ec2ddopt ec2dri ec2-accept-vpc-peering-connection ec2addnacl ec2daz iam-roledelpolicy ec2-create-customer-gateway ec2-reboot-instances iam-roleaddpolicy ec2-modify-volume-attribute ses-verify-email-address.pl as-delete-notification-configuration iam-instanceprofileaddrole iam-usergetloginprofile rds-describe-db-parameters ec2-create-group ec2addsds ec2deldopt iam-useraddloginprofile ec2-delete-vpc ec2dbun iam-accountgetpasswordpolicy ec2-copy-snapshot as-cmd ec2-describe-vpc-peering-connections ec2-describe-reserved-instances-listings ec2-describe-addresses ec2auth ec2-attach-network-interface iam-groupcreate ec2-delete-spot-datafeed-subscription ec2delvol ec2dvol cfn-send-cmd-result ec2assocdopt ec2assocrtb ec2-describe-vpcs ec2-delete-network-interface rds-create-db-instance-read-replica ec2-create-vpn-connection ec2-reset-image-attribute ec2addtag ec2-modify-reserved-instances ec2upip elb-set-lb-policies-of-listener ec2erp mon-list-metrics iam-useraddkey ses-get-stats.pl iam-roleupdateassumepolicy ec2delsubnet as-suspend-processes as-record-lifecycle-action-heartbeat iam-usermodkey ec2dvolatt ec2drtb ec2delpcx ec2-create-tags iam-usermodcert ec2-describe-reserved-instances as-delete-lifecycle-hook ec2-enable-volume-io ec2detigw ec2-describe-tags ec2-attach-internet-gateway ec2assocaddr iam-rolelistpolicies as-delete-policy ec2-modify-image-attribute ec2-describe-dhcp-options elb-delete-lb-policy as-describe-tags iam-instanceprofileremoverole ec2-import-volume ec2-delete-internet-gateway rds-delete-db-subnet-group ec2-add-keypair ec2ikey ec2-describe-keypairs iam-userlistmfadevices as-resume-processes iam-usercreate ec2evio as-create-launch-config iam-accountaliascreate ec2attnic ec2-migrate-image ec2-authorize ec2mimatt ec2-modify-network-interface-attribute ec2-create-internet-gateway iam-rolecreate elb-modify-lb-attributes ec2actlic ec2-unassign-private-ip-addresses ec2-confirm-product-instance ec2dnic elb-disassociate-route53-hosted-zone iam-userdeactivatemfadevice ec2-import-keypair rds-add-option-to-option-group ec2revoke ec2disaddr iam-usergetattributes mon-disable-alarm-actions rds-version ec2-add-group ec2diatt ec2repnaclassoc iam-rolegetattributes ec2daddr rds-describe-option-groups ec2cvcr ec2-request-spot-instances ec2-report-instance-status elb-enable-zones-for-lb ec2reprt ec2-activate-license ec2dvpn iam-roleuploadpolicy ec2gcons ec2ratt ec2-describe-customer-gateways rds-create-db-instance ec2iv rds-describe-db-security-groups elb-version ec2-unmonitor-instances ec2-create-volume ec2-disassociate-address cfn-hup ec2-ami-tools-version ec2tag rds-create-db-parameter-group iam-useruploadpolicy ec2-describe-spot-datafeed-subscription as-update-auto-scaling-group ec2-create-placement-group iam-virtualmfadevicedel ec2deactlic ec2-modify-instance-attribute rds-download-db-logfile iam-useraddpolicy rds-add-tag-to-resource ec2-cancel-spot-instance-requests ec2kill ec2-disable-vgw-route-propagation ec2-detach-internet-gateway ec2-delete-vpn-gateway ec2ver cfn-send-cmd-event ec2drp rds-describe-db-snapshots ec2-create-network-acl-entry iam-grouplistpolicies as-put-lifecycle-hook as-describe-account-limits ses-setup-notifications.pl ec2delvpc ec2msubnetatt ec2cpsnap ec2dsph rds-list-tags-for-resource iam-accountdelpasswordpolicy mon-describe-alarms-for-metric ec2addgrp ec2addrtb ec2-version ec2drio elb-disable-zones-for-lb ec2-bundle-image ec2-replace-network-acl-association ec2detnic iam-instanceprofilegetattributes ec2-stop-instances as-enable-metrics-collection ec2dim ec2addkey iam-accountgetsummary as-disable-metrics-collection iam-userdelkey ec2-describe-regions iam-instanceprofilelistforrole rds-describe-db-subnet-groups ec2deltag ec2-terminate-instances ec2rim elb-attach-lb-to-subnets as-describe-launch-configs rds-purchase-reserved-db-instances-offering as-set-instance-health ec2-assign-private-ip-addresses ec2dlic ec2-create-dhcp-options mon-describe-alarm-history ec2-unbundle ec2dpcx ec2delsnap ec2-monitor-instances ec2rsi rds-modify-db-instance elb-create-lb-listeners elb-apply-security-groups-to-lb ec2allocaddr iam-instanceprofilecreate iam-virtualmfadevicecreate ec2-create-network-interface ec2-delete-vpn-connection rds-restore-db-instance-to-point-in-time rds-reboot-db-instance ec2delgrp ec2-delete-keypair ec2dril iam-virtualmfadevicelist as-describe-scheduled-actions ec2-allocate-address ec2ii iam-servercertmod ec2-attach-vpn-gateway ec2-cancel-bundle-task rds-describe-reserved-db-instances ec2dvcr ec2-describe-vpn-connections ec2-create-instance-export-task as-describe-notification-configurations elb-create-lb-cookie-stickiness-policy rds-remove-tags-from-resource iam-userlistkeys rds-describe-reserved-db-instances-offerings ec2delnic ec2-describe-placement-groups ec2dsubnet iam-userlistgroups ec2rpcx elb-configure-healthcheck rds-update-option-in-option-group elb-set-lb-policies-for-backend-server ec2addigw iam-groupdel ec2riatt iam-userlistpolicies elb-describe-lbs ec2matt iam-userchangepassword as-execute-policy ses-verify-identity.pl elb-deregister-instances-from-lb as-put-notification-configuration ec2-describe-export-tasks ec2dtag rds-describe-event-subscriptions rds-modify-event-subscription ec2reprtbassoc ec2dva ec2addpcx iam-groupuploadpolicy as-describe-auto-scaling-notification-types iam-roledel ec2deligw rds-revoke-db-security-group-ingress ec2-delete-vpc-peering-connection iam-groupremoveuser iam-rolelistbypath ec2-delete-placement-group ec2addixt ec2cct ec2delrtb ec2-associate-route-table ec2-start-instances ec2dre ec2-describe-licenses ec2-create-route-table rds-describe-option-group-options ec2dcgw as-put-scaling-policy ec2daa ec2-delete-group ec2start ec2min rds-modify-db-parameter-group ec2dereg iam-accountaliasdelete ec2-describe-vpn-gateways ec2dvgw ec2iin ec2-get-password ec2mvolatt rds-describe-db-engine-versions ec2mim ec2-cmd ec2dgrp iam-accountaliaslist ec2-describe-spot-instance-requests ec2-modify-subnet-attribute rds-watch-db-logfile as-put-scheduled-update-group-action ec2-metadata as-describe-scaling-activities ec2cpi ec2-reject-vpc-peering-connection iam-groupmod ec2miatt ec2-get-console-output ec2bundle ec2-bundle-vol ec2-describe-network-interface-attribute as-describe-lifecycle-hook-types rds-create-event-subscription ec2addsubnet cfn-signal rds-delete-event-subscription as-describe-lifecycle-hooks ec2-delete-snapshot ec2-reset-instance-attribute ec2dins as-create-auto-scaling-group ec2delkey ec2-delete-tags iam-groupdelpolicy ec2-describe-bundle-tasks ec2msnapatt ec2-describe-image-attribute mon-version iam-useraddcert as-enter-standby rds-describe-db-instances ec2-replace-network-acl-entry rds-delete-db-parameter-group elb-cmd rds-reset-db-parameter-group ec2dct iam-userlistbypath iam-servercertlistbypath ec2-describe-route-tables ec2-deactivate-license ec2-cancel-reserved-instances-listing ec2delnacl ec2-modify-snapshot-attribute ec2-associate-address rds-delete-db-security-group ec2-release-address elb-associate-route53-hosted-zone ec2-detach-network-interface ec2addcgw mon-put-metric-alarm ec2-migrate-bundle ec2din ec2-delete-route as-complete-lifecycle-action cfn-get-metadata elb-create-app-cookie-stickiness-policy ec2rimatt iam-usermod ec2-delete-volume ec2-describe-volume-status ec2delcgw ec2-create-network-acl as-describe-metric-collection-types as-delete-scheduled-action ec2run ec2addrt ses-send-email.pl ec2-replace-route ec2-deregister ec2reg ec2addvpn ec2cpimg ec2addvgw ec2delpgrp ec2rep ec2-create-spot-datafeed-subscription ec2mnicatt ec2-describe-snapshots ec2-reset-network-interface-attribute ec2-delete-customer-gateway as-delete-tags mon-enable-alarm-actions ec2-import-instance ec2addvpc ec2-create-image iam-userdelpolicy ec2-replace-route-table-association mon-get-stats ec2-describe-volume-attribute ec2delvgw ec2detvgw ec2dkey ec2-upload-bundle rds-delete-db-snapshot iam-servercertdel ec2delsds ec2-delete-network-acl-entry ec2addnae ec2delrt ec2-upload-disk-image ec2-register elb-set-lb-listener-ssl-cert as-delete-launch-config ec2stop ec2mva as-delete-auto-scaling-group elb-describe-lb-policy-types elb-register-instances-with-lb ec2-describe-snapshot-attribute as-describe-process-types rds-copy-db-snapshot ec2-describe-subnets ec2crril ec2-enable-vgw-route-propagation ec2-detach-vpn-gateway ec2-describe-instance-attribute as-detach-instances rds-describe-engine-default-parameters ec2-describe-internet-gateways ec2addpgrp as-attach-instances ec2ddi ec2umin ec2caril ec2-describe-reserved-instances-offerings ec2attvol elb-describe-lb-policies ec2-describe-reserved-instances-modifications iam-accountmodpasswordpolicy ec2-describe-network-acls rds-remove-source-identifier-from-subscription ec2dnacl as-describe-auto-scaling-instances rds-describe-event-categories ec2adddopt ec2-cancel-conversion-task ec2-describe-images iam-userresyncmfadevice ec2prio ec2repnae ec2-copy-image iam-userdel iam-groupadduser as-terminate-instance-in-auto-scaling-group mon-put-data elb-describe-lb-attributes cfn-init as-set-desired-capacity ec2dsir ec2addnic ec2-describe-volumes rds-create-db-subnet-group ses-setup-dkim.pl ec2-fingerprint-key ec2-describe-instances ec2disrtb ec2dsds

Albeit, it's not infinite, but perhaps that was simply an expression. Ed Prevost profile|contributions 01:57, 3 October 2014 (UTC)

Very funny. Do you have reliable, verifiable sources for each one of thoses. :)

I guess we could have included the entire text of the King James Bible in that list; after all, an exploit could use any of the words within the string arguments of commands. Seriously, I think it's just a matter of defining how the attack vectors are categorized. The ones from above: CGI, DHCP, and SSH are common standards/protocols -- a subset of a much smaller list. So, how should the subsections be categorized? Sparkie82 (t•c) 04:36, 3 October 2014 (UTC)

Sadly, that you replied this way leads me to believe you fail to understand the potential attacks concerning "thoses", and are not willing to do due diligence to remedy that knowledge debt. This topic is longer about coming to an understanding, together as editors, but is simply you tantruming, until you get your way. Again, I submit we either direct to some exhaustive list and then add specific gritty details as a known attack becomes public, or we just continue to list attacks as they become public; addressing each and every possible attack path, without verifiable resources, is speculation, original research, and in my opinion "adding article text, just to say you did". Ed Prevost profile|contributions 15:10, 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)

OpnVPN PoC http://pastebin.com/VyMs3rRd — Preceding unsigned comment added by Edprevost (talk • contribs) 21:43, 3 October 2014 (UTC)

@Cillum, if you are referring to that long list of commands above, I agree, thus the smiley face. Sparkie82 (t•c) 17:25, 4 October 2014 (UTC)

I think I need to explain something here that I thought was already understood. For purposes of this explanation only, here is a general diagram of an attack using Shellshock.

Attacker → crafts a value for an environment variable containing malicious command(s) → uses a mechanism to introduce the bad data into a system → the value gets assigned to a variable →the variable gets exported to an instance of Bash → Bash executes the malicious command(s) → bad things start happening

The scope of the article section that we are discussing here, “exploit vectors”, covers the steps from where the bad data has been crafted, to the point where Bash executes the malicious command(s). Of course all the possibilities of what happens after the malicious command(s) execute are way beyond the scope of this article. Just as the motivations of the attacker are of no concern. I thought that was understood, but I guess not.

This section just needs to fully explain the types of vectors that could be used to get the the malicious code into a system and executed by Bash.

An additional note about instances of specific breaches. This section is about how the bug is exploited, not about incidents of security breaches. There could be another section listing specific incidents, but this section is not about that. Sparkie82 (t•c) 17:25, 4 October 2014 (UTC)

Again, I think you fail to understand "uses a mechanism to introduce the bad data into a system". The list I provided is a dump of every function or command that bash has reach to and from... meaning, if you could find access to, for example, a cp command call, either through an application or script or otherwise, you could in theory perform 6271. Ed Prevost profile|contributions 17:42, 4 October 2014 (UTC)

Ed, nobody but you is suggesting that we categorize the exploit vectors by command or system call. I suggested using broad categories. What I am hearing you say is "No, we shouldn't use broad categories, I think it should be categorized very finely, at the command or system call level, and oh, by the way, if we do that then the list is too long so let's get rid of the section all together." If that's what you are saying, it's absurd. Sparkie82 (t•c) 00:38, 7 October 2014 (UTC)

If that's what you're hearing, my apologies. Allow me to try and summarize again, Sparkie82, as you seem very eager to be 'published' here. All I'm saying is you're recommending a section that is basically 100% OR, and from a research perspective I would point out it needs to be all encompassing/exhaustive as possible for the vulnerabilities at hand. So even if you categorize it, there is still an open door created for adding a near infinite amount of OR content; and I would venture to guess this is some of the very reasoning behind the policy. But alas, it's OR and shouldn't be here any way. If you're so eager to produce this OR content, why don't you write a column and submit it for editorial review at a publication? Or perhaps your own blog? Or maybe even a small softcover? I am very-much-so in favor of providing details on verifiable paths of exploitation, as reported and verified according to policy, but I'm not at all interested in satiating your desire to just plop your speculative thoughts on the subject here. That being said, i'm very open to any clarification, if i'm not understanding you correctly. Ed Prevost profile|contributions 03:06, 7 October 2014 (UTC)

Ed, I reverted your last edit that moved unrelated content to the beginning of this talk page discussion because it violates WP:TPO. You may also want to (re)read WP:TPYES. This discussion is not about OR content, it's about whether of not to include the section on expoit vectors, and how to organize it. That being said, I think we have a consensus -- at least on the question of including details of the exploit vectors in the article, since you just said, "I am very-much-so in favor of providing details on verifiable paths of exploitation..." Of course, any editor, if she feels that incorrect information is being presented in the article may challenge that content by requesting a source. The exploit vector section is no exception to that WP process. So, beyond just cutting content you "don't like", how do you suggest that we present the details on exploit vectors in this section? Sparkie82 (t•c) 23:03, 7 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)

I once again reverted changes you make to previous comments in this discussion thread and I've placed a warning on your talk page. That older discussion has nothing to do with this discussion. It was over when you started this thread. In fact, the section under discussion in that thread (Log parsing) was no longer in the article when this thread started. Please do not edit previous comments to change meaning; and follow WP:TPO and WP:TPYES when editing in talk pages. Sparkie82 (t•c) 03:21, 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. https://en.wikipedia.org/wiki/Talk:Shellshock_(software_bug)#Section_.22Log_parsing.22 Ed Prevost profile|contributions 05:02, 8 October 2014 (UTC)

Well, I started that discussion, reread it, and posted a closing remark to it, but thanks for reminding me just one more time. Sparkie82 (t•c) 05:11, 10 October 2014 (UTC)

I guess we're done here; no consensus. Sparkie82 (t•c) 05:11, 10 October 2014 (UTC)

Regarding the removal of material you "don't like", you may want to (re)read WP:NOCITE. Sparkie82 (t•c) 05:11, 10 October 2014 (UTC)

Updated NIST Information Now Available?

FWIW --
Following have been *very recently* registered (data possibly useful in the article?):

• CVE-2014-6278 - 20140930nist
• CVE-2014-7186 - 20140929nist
• CVE-2014-7187 - 20140929nist

Following were registered earlier - but also recently updated:

• CVE-2014-6271 - 20140924nist
• CVE-2014-6277 - 20140927nist
• CVE-2014-7169 - 20140924nist

In any case - Enjoy! :) Drbogdan (talk) 13:25, 30 September 2014 (UTC)

OK, I will gladly check! - gacelperfinian^{(talk in - error? Start a new topic)} 13:32, 1 October 2014 (UTC)

Vandalism

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)

You do understand that this allows a form of command injection that was not expected prior to the discovery of the bug? You can become another user by fooling a program running as another user. Bash, DHCP and a bunch of other core utilities in unix/linux had serious faults that when added up allowed some very serious exploitation. Chillum 17:02, 2 October 2014 (UTC)

1980's advice

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)

Are you suggesting that a foreigner put that bash bug there on purpose? If so then this is not the appropriate forum for your theories. Chillum 17:03, 2 October 2014 (UTC)

Wheeler's timeline, and Stephane speaks

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

Further communication on the mailing lists by both Stephane and Chet has confirmed that the bug was present in 1.13, but that it was pre-existing even at that time, introduced by Brian Fox in August 1989 rather than Chet Ramey in 1992. The reason that the quoted email incorrectly suspected that 1.5 was not vulnerable is because it is so difficult to locate versions of bash earlier than 1.13 to actually confirm differences between versions. Ericblake (talk) 22:45, 6 October 2014 (UTC)

Is Shellshock really a security bug in bash?

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)

It's far more than a bug that can be exploited via CGI. The article lists other areas such as restricted shell bypass. --Oscarthecat (talk) 08:54, 9 October 2014 (UTC)

That's a bug in the restricted shell. --В²C ☎ 17:31, 9 October 2014 (UTC)

There is a bug. The bug is a security issue. The bug is in bash. There is a security bug in bash. Bash is an environment that commands run in, it does not simply mean a command prompt for a user to type anything into. The fact that SSH can be forced to run a command but will put your original command in an environment variable seems to contradict your theory that bash was not intended to be executed indirectly by someone who had the ability to manipulate environment variable values. Chillum 09:16, 9 October 2014 (UTC)

The ForceCommand feature of SSH is a feature of SSH, and has nothing to do with bash per se. Shells existed long before remote logins were invented, much less the SSH ForceCommand feature.

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)

Bash has a bug that can be exploited in environments that are meant to be secure and use bash - but bash itself does not have a security bug. --В²C ☎ 17:34, 9 October 2014 (UTC)

Going round in circles here. bash offers security in the form of its "-r" switch, which offers a restricted shell. Due to a security bug in bash it is possible to bypass the restrictions of the bash "restricted shell" feature. --Oscarthecat (talk) 19:11, 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)

If you try to have a private discussion on the beach, and your measures fail because it turns out the sand dunes on the beach bounce sound around in a way that enables others far away to hear your whispers, are you going to say the beach has a security issue? The point is: why would you expect to the beach to be secure? Same with bash.

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)

I never said "bash is not meant to be used in secure environments where users can define environment variables", nor anything that means that.

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 /

Any program that allows that is not a security tool! To say that such an inherently insecure program has a security bug is ridiculous because it implies it's supposed to be secure, which it's not (excepting restricted mode). --В²C ☎ 00:35, 10 October 2014 (UTC)

Nobody anywhere disputes that Bash is designed to execute arbitrary commands from its controlling terminal, its script input, or its command line. The function export mechanism, however, exists to pass definitions, not immediate commands, across a process boundary. Because Bash did not limit the export namespace and did not validate the definitions, immediate command execution was not only possible but staggeringly easy. This was careless, astonishing and dangerous. CGI, by contrast, defines a variable namespace. The Bash behavior has been acknowledged as a security bug by the program's mantainer, by several high-profile computer security experts and by the major Linux distributors. 50.185.134.48 (talk) 06:17, 11 October 2014 (UTC)

Security tools are not the only tools that may have security issues. Any tool that unnecessarily opens a system to attack is a tool that has security issues. But anyway, it doesn't matter what Wikipedia editors say; what do reputable sources say? —174.141.182.82 (talk) 15:02, 11 October 2014 (UTC)

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)

bug fix broke bash

The Background section currently has this statement:

Function definitions are exported by encoding them within the environment variable list as variables whose values begin with parentheses ("()") followed by a function definition.

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)

I'm using bash 4.2.45 (released 7th March 2013 [5]), which precedes all the Shellshock patching. Using that version of bash, the code you've written behaves as below.

$ echo $BASH_VERSION ::4.2.45(1)-release ::$ x='() {echo in x;}' ::$ -bash: x: command not found ::$

Using a fairly recent version of bash, 4.3.28(2) (released 1st October 2014 [6]), I see the same (consistent) behaviour.

$ echo $BASH_VERSION ::4.3.28(2)-release ::$ x='() {echo in x;}' ::$ -bash: x: command not found ::$

On which version of bash were you seeing the behaviour you're concerned with? --Oscarthecat (talk) 11:32, 10 October 2014 (UTC)

I'm going from memory. Maybe I'm wrong. Never mind unless I can recreate. Sorry! --В²C ☎ 16:36, 10 October 2014 (UTC)

You're relying on undocumented behavior. The documented way to export functions to a Bash instance is to use "export -f" within Bash. Bash has always handled the details of how to export the functions, which is why nobody thought about them for so long. As a result of the fix, it now handles the details differently. 50.185.134.48 (talk) 18:37, 11 October 2014 (UTC)

Section title capitalization

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)

The guidelines apply even if the name is not registered. The rules actually boil down to the opposite of that quote. Sentence case typically overrides preferred styling. The quote you give above is related to mathematical notation and programming languages were case changes meaning and is not the general case The other exception is pretty much single letter lower case followed by uppercase, such as eBay, iPod. Everything else should have the first letter capitalized at beginning of sentence or section name. PaleAqua (talk) 03:10, 6 November 2014 (UTC)

Please let me reread those MOS sections. — Dsimic (talk | contribs) 06:30, 6 November 2014 (UTC)

Sorry for my delayed response. You're right, and I was wrong. Thus, I've reverted my edit; however, having "Qmail" is still plain weird to me. — Dsimic (talk | contribs) 01:03, 9 November 2014 (UTC)

No worries. To be honest, it's a weird to me as well, but it's what the guidelines specify. I wonder if the wording could be tweaked so the section header doesn't begin with the name qmail. That would avoid the issue. PaleAqua (talk) 04:51, 9 November 2014 (UTC)

Hm, it could be tweaked for sure, but that would unnecessarily complicate the section title. In addition, I've seen this capitalization issue in section titles and sentences numerous times in a large number or articles. That makes me wonder whether it would make sense to adjust the guidelines, so that "the correct case should always be retained" is extended beyond mathematical notation and programming languages? I know, it's simply against the English grammar, but that's how we got "disk" as a new word, for example. :) — Dsimic (talk | contribs) 05:58, 9 November 2014 (UTC)

Who is Stéphane Chazelas?

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)

Better example for CVE-2014-7169?

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)

Dead source - "http://www.futuresouth.us/wordpress/?p=5" [20]

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. https://en.wikipedia.org/wiki/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)

Recent huge hack releasing 2 TB of data from Cayman National Bank and Trust

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)

Dead source for reference name "businessweek"

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)