BugTraq
Back to list
|
Post reply
Re: Need help. Proof of concept 100% security.
Aug 18 2003 11:43PM
xenophi1e (oliver lavery sympatico ca)
(1 replies)
In-Reply-To: <1061409854.1743.99.camel (at) limit.tm (dot) org [email concealed]>
>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
[ reply ]
Re: Need help. Proof of concept 100% security.
Aug 20 2003 01:16PM
Balwinder Singh (balwinder trustedmachines com)
Privacy Statement
Copyright 2010, SecurityFocus
>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
[ reply ]