From: phc at hush.com (phc@...h.com)
Subject: another topic, was Re: RE: Administrivia

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Silvio how are you commrad. Let's beat these whitehats and own the gibson.

preparation-h crew , a.k.a. PHC

>On Thu, Sep 19, 2002 at 01:24:14PM -0700, chickenshitter@...hma
>il.com wrote:
>>
>> It seems certain people has an agenda ruin the full-disclosur
>e 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 wil
>l 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 st
>op 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 co
>ntent
>available, which may be useful for people to look at if the spa
>m 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 looke
>d (about 16
>months ago I guess),
>
>it had off by 1 stack overflows everywhere in the code..  due t
>o 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 pa
>raphrasing,
>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 ne
>ver sent
>anything to the fetchmail mail) -->
>
>it also had an adjacent buffer overflow that was reported on bu
>gtraq, but was
>not vulnerable in the sense of arbitrary code execution etc, si
>nce the
>adjacent buffer was of adequate size such that the initial over
>flow, 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 exploitatio
>n was
>not possible at the time.  as history shows though.. if its bug
>gy, but
>not exploitable, give it some time, and someone will probably b
>e 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 ran
>domizing
>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 i
>t will
>use.  you could get into some extremely hard to kill runaway pr
>ocesses,
>without this (and without a concept of grouping the processes t
>ogether so
>they can be referenced easier, preferably in association with s
>pecific
>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 kern
>el, and
>associate a resources allocated for identities?  a problem aris
>es, 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 sce
>nario,
>you associate a gid with its own identity, and say wether resou
>rce 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 migh
>t 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 specifi
>c identities.
>
>anyway.. maybe i'm dreaming here :)  but seems not impossible t
>o implement
>with current linux sources.
>
>--
>Silvio
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html
>

-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com

wlQEARECABQFAj2KWNsNHHBoY0BodXNoLmNvbQAKCRCcVkAK1xe2V7RPAJ4smxI2UAnE
QxKHgXatyLuOiq4L4QCgrnGrJALhRgu77ghYXB94lnhnPqc=
=hMXY
-----END PGP SIGNATURE-----




Get your free encrypted email at https://www.hushmail.com

Powered by blists - more mailing lists