|
Message-ID: <20141005164111.GA23299@openwall.com> Date: Sun, 5 Oct 2014 20:41:11 +0400 From: Solar Designer <solar@...nwall.com> To: Rob Fuller <jd.mubix@...il.com> Cc: oss-security@...ts.openwall.com Subject: Re: Shellshocker - Repository of "Shellshock" Proof of Concept Code On Sun, Oct 05, 2014 at 11:25:37AM -0400, Rob Fuller wrote: > Ladies and Gents, I'm the owner of the repo in question and would love > to fix any misgivings you have with the list. But as you are the > experts it would be awesome if you could help me understand which > parts exactly are incorrect, or what you think should be added to help > people better understand. I'll try to consolidate the statements in > this thread, but would greatly appreciate any pull requests or issues > posted to https://github.com/mubix/shellshocker-pocs/issues that could > help me with that process. Sorry, no time for proper GitHub workflow, so I'll just reply here. I suggest that before giving the tests for various CVEs, you emphasize that either a prefix/suffix patch should be applied (typically obtained as part of a distro vendor's update package) or function imports should be disabled (as some other distro vendors did). You should also point out that this makes the individual parser bugs, which got CVEs assigned, irrelevant. Then, while your current tests for CVE-2014-6271 and CVE-2014-7169 will detect actual vulnerabilities, your next two CVE tests try (and mostly fail) to detect parser bugs without checking whether they are vulnerabilities or not. That is, they would claim "vulnerable" even when this is not so due to a prefix/suffix patch or disabled function imports. In your CVE-2014-6271 test, I recommend running e.g. ":" (empty label) or "echo" in place of "id" (which you currently run outside of the injected code), since the output of "id" may look scary to some people. In addition to only testing for bugs rather than vulnerabilities, the CVE-2014-7186 and CVE-2014-7187 tests are unreliable. They tend to give false negatives. For CVE-2014-7186 this may likely be repaired by having it open and close many more EOF's via a script it'd generate and run (since you'd need too many EOF's to write them explicitly - I was using 1000 of them to seemingly reliably trigger the bug). For CVE-2014-7187 no reliable test is possible without instrumentation since the bug is an off-by-one. You could wrap these two tests in manual function exports and automatic function imports, so they'd only work on versions of bash without a prefix/suffix patch and with function imports supported, or you could adjust reporting not to claim "vulnerable" (but merely claim "bug present but might not pose a security vulnerability"). Your CVE-2014-6278 and CVE-2014-6277 tests are incomplete: you're giving env var values rather than full shell commands. You should use e.g.: env X='() { _; } >_[$($())] { echo hi mom; id; }' bash -c : and: env X='() { x() { _; }; x() { _; } <<a; }' bash -c : for consistency with your other tests (and with my suggested use of ":" in place of "id"). Warning: I am not sure the above two tests are correct, I did not look into these specific two bugs. To give proper context for those viewing this in the list archives, I wrote the above while looking at this revision (which will hopefully become outdated soon): https://github.com/mubix/shellshocker-pocs/blob/bd5170e43fd03f2cb0fe90a7b4b1f60fc4f9a651/README.md Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.