re: Testing for Shellshock ... combinatorics and latest(Shellshock) Bash Vulnerability...(attn: Chet Ramey)

[Rick Karcich (rkarcich)]

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