From silvio Sun Sep 15 15:58:13 2002 Return-Path: Received: (from silvio@localhost) by big.net.au (8.11.0/8.11.0) id g8FMwBg07533; Sun, 15 Sep 2002 15:58:11 -0700 Date: Sun, 15 Sep 2002 15:58:11 -0700 From: silvio@big.net.au To: full-disclosure@lists.netsys.com Subject: sandboxing Message-ID: <20020915155811.D813@hamsec.aurora.sfo.interquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Status: RO Content-Length: 713 Lines: 21 ok.. so like.. this is old hat, but it's never been talked about alot I spose.. i have mentioned it a few times before.. but oh well LD_PRELOAD is a poor mans sandbox when you think about it in terms of analysing a binary. because.. a binary that runs knows about all the shared libraries involved. look at the link map list.. you can just count them, and if you have too many.. something is whack. if your forensics guy is smart, he wont use an env variable for LD_PRELOAD, but more like /etc/ld.so.preload - but doesnt matter since everything is available anyway. ** ok.. quick comment.. who the hell uses libpcap in multithreaded code? i think they may have by now (or never) made it MT safe.. -- Silvio