Re: Execution Flow Control (EFC)

[Jimb Esser <esse0027 () tc umn edu>]

At 04:01 PM 8/16/2003 -0400, you wrote:
> > http://203.197.88.14/
> > http://203.197.88.14/efc
> I'm not one to judge product quality based (partially or otherwise) on
> past or current programming mistakes, but if I was, I'd say that
> something like:
>
> for(i=0;arg[i]; i++) {
>        if ((strncmp(arg[i], "/etc/shadow",11) == 0) ||
>                (strncmp(arg[i], "shadow",6) == 0)) {
>                        write(1,"arg cannot be shadow\n", 21);
>                        return 0;
>        }
> }
>
> is a pretty poor way of making sure people don't play with your shadow
> file.  There are many possibilities here, but the bottom line is that
> the webserver had a poorly written CGI application and EFC didn't seem
> to do much in the way of stopping someone from exploiting it and
> stealing the shadow file.  

FWIW, I think that check is just part of the webshell, and if you do something like "cat /etc/../etc/shadow" it doesn't 
complain and will behave as expected (and "as expected" means that since the 'cat' command didn't access the 
/etc/shadow command while they were generating the behavioral patterns, it's not going to let it access it now, if I 
understand this right).

It seems to me that their method of security should work perfectly, the kernel will only allow programs access to the 
operations they did during the "training".  But if I understand this right, either a) while EFC is running you cannot 
change any settings, install new programs, etc, because their kernel module won't allow it, or b) you have a "trusted" 
program or account that the EFC module ignores so that you can do these things, but then that account is now vulernable.
        jimb

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html