Re: More parser odities

[Michal Zalewski <lcamtuf () coredump cx>]

> Maybe it's just the right opportunity to do that, instead of assigning
> yet another CVE to Michal's latest finding?  Oh, I think Michal's
> latest already got a CVE too?  Does this once again render the
> (previously) exposed parser not CVE-worthy? ;-(

Whoa :-) So to be clear, I felt that it makes sense to ask for CVEs
and report these externally because up until that point, we had no
conclusive evidence that the original patch is truly inadequate, and
that Florian's patch is anything more than a nice-to-have that several
people on oss-security are fond of. Tavis' EOL find was troubling, but
fixed upstream with a one-liner in bash43-026, not with Florian's
patch.

(In fact, Florian's patch wasn't upstreamed when I started fuzzing the
parser and hit the bugs.)

Anyway, I think that the confusion stemmed mostly from fairly
inaccurate "vanity" pages, news articles, and "vulnerability checkers"
that pulled off stuff like this
(https://shellshocker.net/shellshock_test.sh):

-- snip! --
# CVE-2014-7186
CVE20147186=$((bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF
<<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' 2>/dev/null || echo
"vulnerable") | grep 'vulnerable' | wc -l)

echo -n "CVE-2014-7186 (redir_stack bug): "
if [ $CVE20147186 -gt 0 ]; then
        echo -e "\033[91mVULNERABLE\033[39m"
else
        echo -e "\033[92mnot vulnerable\033[39m"
fi
-- snip! --

Assigning CVEs + maximum CVSS scores to the two probably non-risk
one-off bugs probably didn't help.

At this point, it definitely makes no sense to keep assigning CVEs to
additional prefix-requiring problems in the parser at this point,
since hopefully everybody got the message to upgrade.

/mz