another topic, was Re: RE: Administrivia

[phc () hush com (phc () hush com)]

-----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@hushma
> 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 () 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 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