Incidents
Suspicious files in /tmp Jun 16 2007 06:13PM
kladizkov.thehome (kladizkov thehome gmail com) (3 replies)
Re: Suspicious files in /tmp Jun 18 2007 05:12PM
Jamie Riden (jamie riden gmail com)
Re: Suspicious files in /tmp Jun 18 2007 05:08PM
Jamie Riden (jamie riden gmail com)
Re: Suspicious files in /tmp Jun 18 2007 04:47PM
Matt D. Harris (mdh solitox net) (5 replies)
Re: Suspicious files in /tmp Jun 21 2007 11:38AM
Remko Lodder (remko elvandar org) (1 replies)
Re: Suspicious files in /tmp Jun 21 2007 08:05PM
Cy Schubert (Cy Schubert komquats com)
Re: Suspicious files in /tmp Jun 19 2007 01:33AM
Robin Sheat (robin kallisti net nz) (1 replies)
Re: Suspicious files in /tmp Jun 20 2007 04:47PM
Valdis Kletnieks vt edu (1 replies)
RE: Suspicious files in /tmp Jun 20 2007 11:06PM
Thyago Braga da Silva (tbraga gasecurity com br) (1 replies)
RE: Suspicious files in /tmp Jun 21 2007 05:09PM
kaneda bohater net (1 replies)
Re: Suspicious files in /tmp Jun 22 2007 12:19AM
Eduardo Tongson (propolice gmail com)
Re: Suspicious files in /tmp Jun 19 2007 12:23AM
Rainer Duffner (rainer ultra-secure de)
Re: Suspicious files in /tmp Jun 19 2007 12:17AM
Rainer Duffner (rainer ultra-secure de)
Re: Suspicious files in /tmp Jun 18 2007 09:32PM
Michal Zalewski (lcamtuf dione ids pl) (1 replies)
Re: Suspicious files in /tmp Jun 19 2007 12:37AM
Matt D. Harris (mdh solitox net)
A lot of times in an exploit scenario, you don't have access to stdin.
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. If you read further in my post, I do address that
there're plenty of other interpretters around that would need to adhere
as well. I don't see the ld_preload issue as being difficult to modify
either, and furthermore not all exploit scenarios involve access to the
env.
Of course, I'm talking about mitigation here, it's far from a perfect
solution, but for a web server environment where the "dump a file in
/tmp and then execute it" vector is fairly common, it seems like a
logical step for command interpretters to take. I don't think any of us
see it as a perfect be-all-end-all solution to prevent web server
compromises, but it's probably better than how it is now (the
performance hit is negligible, and I don't see any other real down
sides). If it even stops 5 out of 50 compromise attempts that get this
far due to things like bad cgi or web server-interpretted code (php,
asp, et al), then that's progress, and that's a good thing.
I might be missing something though in terms of down sides...
Take care, Matt

Michal Zalewski wrote:
> On Mon, 18 Jun 2007, Matt D. Harris wrote:
>
>> Some logic to check the underlying filesystem of a script before reading
>> it would be a very cool addition to perl from a security standpoint.
>
> This is not necessarily a great idea: not only Perl is in no way special,
> but like most interpreters, it can be invoked to read scripts from stdin
> or any other "volatile" source, without the necessity to store them in a
> file. Most interpreters also accept include file search paths and
> various command-line switches that would make such restrictions
> pointless anyway.
>
> But, say we implement heavily-handed restricted mode for Perl. Should bash
> refuse to read from stdin and implement the same check? Gdb? Awk? Sed?
> Where do you draw the line?
>
> If you don't want your users to use interpreters, make these programs not
> executable by that user; there's really no other way without a major
> ovehaul of how un*xes are built.
>
> And even then, interpreters aside, "noexec" flag is *not* an effective
> method to stop the user from running custom code, and never was:
>
> - /lib/ld-linux.so.2 /tmp/myexec
> - LD_PRELOAD=/tmp/foo.so ls
> - etc, etc.
>
> /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=70160000000Cn8
E
------------------------------------------------------------------------
--

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus