Hello Chet, Re: testing for Shellshock... would like your feedback... specifically, regarding the possibility of human-directed combinatorial testing to find this Bash vulnerability...
Given the knowledge about Shellshock that's been developed, I'm wanting to define more of the attack surface for Shellshock - and put this into an input model for combinatorial testing... Problem Statement: - Ultimately develop a fuzzing script for testing for vulnerabilities like 'Shellshock'... - Develop a fuzzing variant, 'human-directed' fuzzing with combinatorial intelligence added... - Employ combinatorial testing for testing the triggering mechanisms surrounding 'Shellshock'... - Learn more about Shellshock and put together an input model like that described in the attached(test-parm-partition~)... References: http://blog.crowdstrike.com/crowdstrike-shellshock-scanner/ https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/ https://github.com/mubix/shellshocker-pocs Discussion of the problem: Explore finding these vulnerabilities through testing or at least how they've escaped detection via testing... There has been a debate in the test community about high profile exploits(Shellshock, Heartbleed) in open source code. Most seemed to think from looking at the bug in the code that neither testing, nor fairly advanced static analysis would have necessarily caught it. Perhaps the problem is that, - While checking for the conditions that trigger 'Shellshock' doesn't look hard, it's validating all possible configurations in their class that would be prohibitively expensive... - So we end up having to pick some, and of course miss other conditions that would have hit the issue... - Propose investigating combinatorial testing applied to exploring the space of triggering mechanisms and helping to choose the most effective set of test variables... - Explore how combinatorial testing could play a role in eliminating vulnerabilities like Shellshock... - Specifically explore testing with virtual test parameters like the testing that might be done for a "find" function with two arguments, string and file name. For such a "find" function we might define the following set of test parameters and values in an input table/model: String length: {0, 1, 1..file_length, >file_length} Quotes: {yes, no, improperly formatted quotes} Blanks: {0, 1, >1} Embedded quotes: {0, 1, 1 escaped, 1 not escaped} Filename: {valid, invalid} Strings in command line: {0, 1, >1} String presence in file: {0, 1, >1} Similarly, for Shellshock, perhaps the same approach could be used for testing shell commands, with test parameters that include things like environment variable, with values such as numeric, alpha, function etc... in an input table/model to capture triggering mechanism(s)? - ENV variable: {numeric, alpha, function} - As I understand it, for CGI scripts the 'Shellshock' issue occurs when the defined environment variable is a function AND the REMOTE_USER variable is set to an account that is present on the host... - It seems reasonable that testing could also include a test parameter such as "remote-user-present" with values "yes" and "no". An input model that included these two test parameters, plus the various configuration options, could presumably find the problem. As always, it depends on the input model and test parameters defined, but these seem reasonable, and pretty basic for testing. The test parameters and input model might also be re-used in testing a variety of shell commands to possibly discover other vulnerabilities... - this specific issue (Shellshock) was triggered by a specific 4 byte sequence at the beginning of the value of an environment variable... - in this case, that 4 byte sequence wouldn't, by itself, do much ... an attacker then needs to have syntactically valid bash input after it, and in most of those cases, nothing would happen... - an attacker would have needed to provide specific syntactically valid input that would cause undesired output ... the most obvious type of which would have been a segfault... ... I'm having difficulty in understanding the breadth of the input space and the variables in play... One useful test of an input model for combinatorial testing would be the extent to which it applies to other shell commands; how general it is. I'm trying to lay out the factors and values for the input model below, in order to use NIST's ACTS tool(http://csrc.nist.gov/groups/SNS/acts/index.html) in order to generate a covering array to include t-way combinations. I suspect someone has applied this approach to shell script testing. Are you aware of any... what are your thots? Parameters (factors) involved in Shellshock configurations... 1. Shellshock 'human-directed' fuzzing ... factor default value levels (possible values) number of options treat it as don't-care value other factors interacting with this factor ENV variable numeric, alpha, function My 'ask' - (please) chime in with more triggering factors surrounding 'Shellshock' and proposed values for those factors etc... Please let me know if you have questions... Best, -Rick
test-parm-partition.docx
Description: test-parm-partition.docx
