Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix test for CVE-2014-6277 to be a function import test from environment... #23

Closed
wants to merge 2 commits into from

Conversation

bdrewery
Copy link

@bdrewery bdrewery commented Oct 2, 2014

....

Bash 4.3.28 currently does crash with the example scripts for
both CVE-2014-6277 and CVE-2014-6278 with no patch[1], but it
will not run any code from them without specially setting up
the environment to use the prefixing. Both CVE are documented
as specifically environment issues; if you can pass bad code
directly to bash -c then the attacker has already won.

The check must involve the environment or it will needlessly scare
users who have deployed appropriate mitigations. For example,
on FreeBSD (and NetBSD) we have disabled all function importing from
the environment. So this test passes fine on our bash versions.

The syntax used here is to check the return value to see if it
crashed, while hiding the core dump messages. There's no
code execution proven for CVE-2014-6277 yet so there is no
output that can be checked against.

Switch the test to more closely match the examples from the
disclosure [2].

[1] http://www.openwall.com/lists/oss-security/2014/10/01/25
[2] http://lcamtuf.blogspot.de/2014/10/bash-bug-how-we-finally-cracked.html

…ent.

Bash 4.3.28 currently does crash with the example scripts for
both CVE-2014-6277 and CVE-2014-6278 with no patch[1], but it
will not run any code from them without specially setting up
the environment to use the prefixing. Both CVE are documented
as specifically environment issues; if you can pass bad code
directly to bash -c then the attacker has already won.

The check must involve the environment or it will needlessly scare
users who have deployed appropriate mitigations. For example,
on FreeBSD (and NetBSD) we have disabled all function importing from
the environment. So this test passes fine on our bash versions.

The syntax used here is to check the return value to see if it
crashed, while hiding the core dump messages. There's no
code execution proven for CVE-2014-6277 yet so there is no
output that can be checked against.

Switch the test to more closely match the examples from the
disclosure [2].

[1] http://www.openwall.com/lists/oss-security/2014/10/01/25
[2] http://lcamtuf.blogspot.de/2014/10/bash-bug-how-we-finally-cracked.html
@bdrewery
Copy link
Author

bdrewery commented Oct 2, 2014

You might want to consider making the BASH_FUNC/prefix tests pink and not red as they are not as critical as the initial shellshock ones. Here's another opinion on it: http://www.openwall.com/lists/oss-security/2014/10/02/4

These are seen to not be worth testing and scaring people over[1][2]. Plus
there is currently no patch to fix them.

[1] http://www.openwall.com/lists/oss-security/2014/10/02/4
[2] http://www.openwall.com/lists/oss-security/2014/10/02/5
@hannob
Copy link
Owner

hannob commented Oct 2, 2014

I see that this is an issue, however I'll try a different approach. I still want it to be able to check for all bugs separately.
I think I'll change the script so it first checks if the function parser is active/non-prefixed and output less scary message if it isn't

@hannob
Copy link
Owner

hannob commented Oct 2, 2014

I now have re-designed the whole script in a way to make things more clear.
What I do now: The very first check looks if the arbitrary variable function parsing is active. If it's not then all further checks will output a yellow message with a note that they are non-explitable.
I think this is the right approach. Once you have the prefix-patch or any patch that completely disables the variable funciton parsing you are safe from all further bugs.

@hannob hannob closed this Oct 2, 2014
@bdrewery
Copy link
Author

bdrewery commented Oct 2, 2014

Yes this approach works for me. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants