[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20030816211132.GF3751@spoofed.org>
From: warchild at spoofed.org (Jon Hart)
Subject: Execution Flow Control (EFC)
On Sat, Aug 16, 2003 at 01:55:56PM -0700, Jimb Esser wrote:
> 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).
Yes, that check is part of the webshell, but I avoided detailing the
specific exploit and instead found flaws in his/their argument. The
code isn't in the tarball mentioned previously on this list, but
elsewhere in the webtree.
> 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
Either could certainly be true. If 'a)', then the idea is flawed and
the system was broken because webshell either wasn't trained or it
was trained improperly. Security systems and products are great, but a
careless setup by an administrator can leave gaping holes as this may be
demonstrating. 'b)' is probable, but I certainly would not trust a system
that trusts certain programs or accounts but heavily scrutinizes others.
Its a seemingly small foothold like that that an attacker needs to
leverage his way to whatever end goal he/she might have.
-jon
Powered by blists - more mailing lists