full-disclosure - Execution Flow Control (EFC)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5.2.0.9.0.20030816135039.01a4df98@esse0027.email.umn.edu>
From: esse0027 at tc.umn.edu (Jimb Esser)
Subject: Execution Flow Control (EFC)

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