Bash Still Vulnerable
According to the vulnerability test script from shellshocker.net, the latest bash versions on CentOS5 and CentOS6, 3.2-33.el5_11.4 and 4.1.2-15.el6_5.2, resp., are still vulnerable to CVE-2014-6277. In fact, on CentOS6, abrtd will send you a nice report about it. Does anyone know if upstream is working on a fix?
[root@host ~]# bash ~/shellshock_test.sh CVE-2014-6271 (original shellshock): not vulnerable
/root/shellshock_test.sh: line 16: 17229 Segmentation fault (core dumped) bash -c “f() { x() { _;}; x() { _;} <
CVE-2014-6278 (Florian’s patch): not vulnerable CVE-2014-7169 (taviso bug): not vulnerable CVE-2014-7186 (redir_stack bug): not vulnerable CVE-2014-7187 (nested loops off by one): not vulnerable CVE-2014-//// (exploit 3 on http://shellshocker.net/): not vulnerable
[root@host ~]#
4 thoughts on - Bash Still Vulnerable
https://bugzilla.redhat.com/show_bug.cgi?id47189 has conversation and details that you might find interesting.
I noticed this as well but did some homework ;-)
https://bugzilla.redhat.com/show_bug.cgi?id47189
https://access.redhat.com/security/cve/CVE-2014-6277
If I understand it correctly they think it’s not exploitable anymore. Still think it should get patched immediately as there is an upstream patch available and it avoids any more questions and confusion about this problem.
Kai
Well, the upstream patch, at least as it is written now, would require them to back out their patches to apply.
But regardless if whether or not they fix the segfault issue, that is NOT a security issue or exploitable.
It might possibly be a Denial of Service mechanism, I guess.
The place to address this is on the bugzilla entry though. We will publish the changes Red Hat rolls into the source and the upstream bugzilla is how to make that happen.
https://bugzilla.redhat.com/show_bug.cgi?id=1147189
Although, this is already in there:
“We can reproduce this parser bug. But we treat this as a regular bug, not a security bug, because of the fixes mentioned in comment #1.”
So, I would imagine that statement means that they are going to fix the segfault issue as a RHBA, not an RHSA. This likely means it will happen, but the QA and regression testing will be longer and more thorough as it is not a time critical security issue.