Message-ID: <20020919155327.A3458@hamsec.aurora.sfo.interquest.net>
From: silvio at big.net.au (silvio@....net.au)
Subject: another topic, was Re: RE: Administrivia

On Thu, Sep 19, 2002 at 01:24:14PM -0700, chickenshitter@...hmail.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@...h.com is a very poor mimic of gobbles@...hmail.com. The REAL GOBBLES always spoke in 3rd person. The REAL GOBBLES posted good exploits. gobbles@...h.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

Powered by blists - more mailing lists