[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
