Test-suite for a password protected website

David Dick david_dick at iprimus.com.au
Mon Dec 29 14:37:12 CST 2003



Joshua Goodall wrote:

>Using code that represents a well-known security error cannot be recommended
>without major, major caveats about usage.
>
>For example, Leif - there have been plenty of application vulnerabilities
>that have allowed people to run commands like "ps" *without* obtaining
>shell access, as you've erroneously assumed.  Very few of them would
>be stopped by a firewall, and I expect there will be more in future.
>
>I have discovered such vulnerabilities during audits of commercial
>software (a memorable case was an unsafe use of "ls" in a commercial
>ftp server).
>
>The rest of the "gives us more time" items you've listed seem like
>pretty trivial barriers in these days where real black-hats can and
>do write invasive kernel modules (c.f. recent Debian compromise).
>
>So David - please don't ever pass a password you care about via
>an environment variable.
>
>- J
>
>  
>

The problem is to allow automated as well as normal running of a program 
if the user desires it.  For a test-suite, both of these cases seem 
highly desirable.  Automated execution means the access method need to 
be written in the clear somewhere.  Whatever method is chosen for 
automated testing, the game is over in milliseconds of the box being 
compromised. 

Additionally, while reading from stdin is as secure as it is possible to 
get (afaik), to automate it, it requires the user to be well versed in 
Expect.  Most programmers (not perl programmers of course ;)) have no 
idea even how to use Expect, let alone users. 

Thinking a bit more about it, it's not even as simple as that (you could 
generate the test suite at "make" time for the user).  A typical perl 
test-suite runs the main (Test::Harness) process which kicks off x 
number of test scripts and reads the results from them.  To pass input 
to the test script as well as reading output from it would require 
Expect (or equivalent 'orrible code) to be hacked into Test::Harness (or 
more specifically Test::Harness::Straps) as well.  So you have Expect 
kicking off the Test::Harness process, which then uses Expect itself to 
handle the sub-processes.  Very ugly.  It opens up the problem of how to 
test the test-suite actually even works at all on the box you are 
deploying on.  To the innocent user, it may seem as if the code has 
failed to build correctly.




More information about the Melbourne-pm mailing list