Date: 18 Aug 2003 23:43:36 -0000
From: xenophi1e <oliver.lavery@...patico.ca>
To: bugtraq@...urityfocus.com
Subject: Re: Need help. Proof of concept 100% security.


In-Reply-To: <1061409854.1743.99.camel@...it.tm.org>

>3. Results of EFC are in front of you all. There have been 2000+ plus
>attacks, still system is up and running without a reboot. All
>applications are doing what they are supposed to do. All these
>security loopholes and attacks have cost money in past.
>

Ok, hang on a second here. 

- It's already been pointed out on vuln-watch that it is possible to view 
the contents of /etc/shadow using the webshell.cgi located 
in /var/www/cgi-bin/. This is just the result of a bad path check, so I 
thought I would hammer on EFC a bit more...

- It was possible using the webshell.cgi to dump the full contents 
of /dev/hd* through the web. This bypasses EFCs filesystem restrictions 
in a obvious way. Again maybe just bad configuration.

- It was not possible via the webshell.cgi to view the contents of 
numerous directories. Finally some visible signs of security. 
Unfortunately it was possible to bypass these restrictions by accessing 
the same directories via the proc filesystem ( /proc/N/root/whatever-
directory ). This is clearly a flaw in EFC's checks. I imagine a hard-
link would have worked as well. This made it possible to obtain a copy of 
efcm.o, the EFC kernel module, as well as all of the configuration 
information available in /var/efc/. In fact it was possible to read any 
file on any filesystem. Good thing there wasn't anything sensitive 
in /home/bal, although thank you very much for the collection of 
precompiled exploits... 

So clearly rules like:
open /var/www/html/* /usr/sbin/httpd

Plain old don't work.

  Various people have pointed out why EFC's design can never be 100% 
secure, which is transparently obvious, really. From what I've seen the 
implementation is pretty broken as well, and I was trying to be forgiving.

  Maybe EFC is providing some protection against shellcode, but from what 
I could tell from /proc/efc/, all of the shellcodes being run against it 
were failing on a socketcall. I'm guessing the protection is generally as 
solid as it appears, which is to say not very, and a somewhat cleverly 
crafted shellcode could get through without much trouble. From what I 
could tell from /var/efc/db/usr/sbin/sshd, sshd was allowed to 
access /etc/shadow. So I'm guessing one could read the contents back 
through the open socket to sshd without much trouble and then crack them 
offline. Maybe the syscall restrictions are clever and take ordering into 
account, or maybe they take the value of EIP at the time of the call into 
account, unless you can point out something novel your doing, common 
sense dictates that breaking these schemes is just a question of writing 
a smart shellcode.

Seriously, you should release the source instead of holding silly h4x0r 
cockfights, this isn't a bad idea, but breaking it in it's current state 
isn't worth the trouble. 

Cheers,
~x

Powered by blists - more mailing lists