-----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 -- >> >> [EMAIL PROTECTED] is a very poor mimic of [EMAIL PROTECTED] >. The REAL GOBBLES always spoke in 3rd person. The REAL GOBBLES posted good exploits. >[EMAIL PROTECTED] 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 _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
