On Mon, 18 Jun 2007, Matt D. Harris wrote:
A lot of times in an exploit scenario, you don't have access to stdin.
Why not? If you can call execve, you can go for sh -c 'echo "foo()" | perl
-' instead of calling perl interpreter directly. Or use pipe() + fork().
While the script could still be feasibly passed on the command line,
this is a much greater restriction and would shut down a number of
existing exploits.
*Existing* exploits usually have little to do with invoking perl - and
unless you're fearing local account attacks (unlikely on a firewall?),
little to do with creating executable files in /tmp.
All it takes to stop most of common exploits is to disallow /bin/sh
invoked with stream socket stdin or *id/e*id discrepancies. If you want to
defend yourself against off-the-shelf attacks, perl restrictions and
noexec are of probably of least use; and if you want to defend yourself
against clever, targeted attacks - very much the same...
/mz
-------------------------------------------------------------------------
This list sponsored by: SPI Dynamics
ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper
It's as simple as placing additional SQL commands into a Web Form input box
giving hackers complete access to all your backend systems! Firewalls and IDS
will not stop such attacks because SQL Injections are NOT seen as intruders.
Download this *FREE* white paper from SPI Dynamics for a complete guide to
protection!
https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E
--------------------------------------------------------------------------
