From silvio Thu Sep 19 16:30:09 2002 Return-Path: Delivered-To: silvio@big.net.au Received: from big.net.au [202.7.194.4] by localhost with POP3 (fetchmail-5.5.0) for silvio@localhost (single-drop); Thu, 19 Sep 2002 16:30:09 -0700 (PDT) Received: (qmail 1485 invoked from network); 19 Sep 2002 23:00:02 -0000 Received: from unknown (HELO netsys.com) (199.201.233.10) by mail.big.net.au with SMTP; 19 Sep 2002 23:00:02 -0000 Received: from NETSYS.COM (localhost [127.0.0.1]) by netsys.com (8.11.6/8.11.6) with ESMTP id g8JMmkK10807; Thu, 19 Sep 2002 18:48:46 -0400 (EDT) Received: from ns2.sea (ns2.sea.interquest.net [66.135.144.2]) by netsys.com (8.11.6/8.11.6) with ESMTP id g8JMljK10708 for ; Thu, 19 Sep 2002 18:47:45 -0400 (EDT) Received: from big.net.au (ip172.aurora.sfo.interquest.net [66.135.130.172]) by ns2.sea (8.12.5/8.12.5) with ESMTP id g8JMlE5H026207; Thu, 19 Sep 2002 15:47:14 -0700 Received: (from silvio@localhost) by big.net.au (8.11.0/8.11.0) id g8JMrRO03515; Thu, 19 Sep 2002 15:53:27 -0700 From: silvio@big.net.au To: chickenshitter@hushmail.com Cc: full-disclosure@lists.netsys.com Subject: another topic, was Re: [Full-Disclosure] RE: Administrivia Message-ID: <20020919155327.A3458@hamsec.aurora.sfo.interquest.net> References: <200209192024.g8JKOFF12844@mailserver2.hushmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200209192024.g8JKOFF12844@mailserver2.hushmail.com>; from chickenshitter@hushmail.com on Thu, Sep 19, 2002 at 01:24:14PM -0700 Sender: full-disclosure-admin@lists.netsys.com Errors-To: full-disclosure-admin@lists.netsys.com X-BeenThere: full-disclosure@lists.netsys.com X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Discussion of security issues List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 19 Sep 2002 15:53:27 -0700 Status: RO Content-Length: 4883 Lines: 102 On Thu, Sep 19, 2002 at 01:24:14PM -0700, chickenshitter@hushmail.com wrote: > > It seems certain people has an agenda ruin the full-disclosure list and force everybody back to Symantec's list. I wonder who is behind that movement? It appears as this, I agree. > Don't bother asking for the spam and fighting to stop, it will not. If a system CAN be abused, it WILL be abused. Unmoderated lists have this inherant flaw. trust mailing lists etc.. are vulnerable indeed :( > All these great minds on this list and you are not able to stop a few pea brains? Let's find a solution that is more solid than asking them to stop. At this point I see filtering on your own client as the only solution. > > -- on another note -- > > gobbles@hush.com is a very poor mimic of gobbles@hushmail.com. The REAL GOBBLES always spoke in 3rd person. The REAL GOBBLES posted good exploits. gobbles@hush.com is a nobody, a loser, a wannabe. He's not amusing, he is pathetic. You were annoyed by the real GOBBLES? Kind of puts things in perspective after seeing the fake gobbles spam the list for the past few weeks.. I want the REAL GOBBLES back! He was coo with me It looks like an attempt to --> a) annoy everyone b) establish an anti-gobbles, anti-disclosure etc mentality. c) establish moderation or an anti-open mailing list. for the last part, dave aitel apparently does have moderated content available, which may be useful for people to look at if the spam becomes unmanageable or simply too annoying. ps. can you trim the lines in your mail to fit into 80 columns or something. -- ok.. so perhaps something technial again. so fetchmail sources.. from what I remember of it, last i looked (about 16 months ago I guess), it had off by 1 stack overflows everywhere in the code.. due to the nature of the variable's on the stack, you were only able to overflow on some pointless data which wasn't really useful in terms of exploitation. of course.. there is no garauntee of how these variables would end up in memory according to the c specs - i'm not quoting or even paraphrasing, but it seems unlikely that it could be otherwise.. consider the use of register changing auto layout's.. or for architectures where stack growth is in different directions etc. seems very dependant on the abi here (whatever that means). the off by 1's afaik, were never documented for this iirc (i never sent anything to the fetchmail mail) --> it also had an adjacent buffer overflow that was reported on bugtraq, but was not vulnerable in the sense of arbitrary code execution etc, since the adjacent buffer was of adequate size such that the initial overflow, would not lead to execution flow dependant data etc (overwriting ebp/eip etc, or used later on for flow control), nor was it any authentication or priveledge related data etc. this bug was reported but not fixed (is it now?) as exploitation was not possible at the time. as history shows though.. if its buggy, but not exploitable, give it some time, and someone will probably be able to do it. for the record.. yes i do use fetchmail, and am very happy with it.. though i have see a few times where fetchmail -> procmail would hang consistanty with certain types of non compliant mail.. -- there was a mention in recent days about the possibility of randomizing pid selection in Linux. this is good for some things, but not so good in other respects.. if you look at those programs which fork/exit in attempt not to be killable.. the typical way to kill them, is by predicting the next pid's it will use. you could get into some extremely hard to kill runaway processes, without this (and without a concept of grouping the processes together so they can be referenced easier, preferably in association with specific users). i dont know the kernel internals here at all.. so maybe this is true, not true, possible, not possible.. can we have ulimit's in the kernel, and associate a resources allocated for identities? a problem arises, resources for a group (ie, gid). i say screw it :) identities are only by uid. and gid is simply a "group" they belong too.. in worst case scenario, you associate a gid with its own identity, and say wether resource allocation belongs with user or group semantics.. problems i'm sure though with gid's. anyway.. its ofcourse easy to ask for such wish lists.. it might be cool if someone tried writing an experimental version or if anything has been done for linux in the past. and have /proc/identity/ heh.. nice for lsof and sysadmins ;-) then have on the fly killing of resources/pid's etc for specific identities. anyway.. maybe i'm dreaming here :) but seems not impossible to implement with current linux sources. -- Silvio _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html