[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20020913053123.A2308@hamsec.aurora.sfo.interquest.net>
From: silvio at big.net.au (silvio@....net.au)
Subject: RE: remote kernel exploits?
On Fri, Sep 13, 2002 at 02:27:32PM +0300, Georgi Guninski wrote:
> silvio@....net.au wrote:
>
> > Has there been one ounce of technical discussion during this?
> > Has anyone even google'd on the topic and seen discussion of kernel issues
> > relating to security?
> >
>
> google shows that some ipv6 enabled freebsd boxes spontaneously crash on
> heavy
> load sometimes.
hmm.. i've seen userspace /bin/mail client crash under load! quick, call in
nipc, the criticial infrastructure is in grave threat!
i personally think they are too busy organizing events to give out free
t-shirts.
www.nipc.gov -->
"however, the raised threat condition level is deemed appropriate due to
credible intelligence and recent statements by terrorists in custody" [skip]
how many terrorists have nipc in custody? i thought the terrorists were too
busy becoming autonomous. do terrorists suffer from the hidden node problem in
"cell"ular systems.
Has anyone seen the movie "in the name of the father" or whatever it's
called. I suggest to hit the movie stores and grab it.
ok.. back to www.nipc.gov -->
"brian west" .. according to nipc website. this guy finds a security hole
in some website, copied 4 perl scripts (in the nipc commentry, it _must_
say "practical extraction report language") + passwd file and poked around
the rest of the website. the following day according to nipc, he
contacted the website and told them this. 10 days later, the fbi
pulled him in for interview etc. they say during that week is was rewriting
the perl scripts in php.. "so he could produce and market his own version".
(i really find it hard to believe this is even close to reality, but lets
make a presumption and say the website reported the correct information -
not likely).
way to go nipc! the internet infrastructure is safe now that we have
identified 1 guy rewriting 4 (no doubt) crappy perl scripts from some insecure
website.
can nipc explain to me why tcp/ip stacks against different vendors, sometimes
appear very similar in their very bizzare behaviour?
also like.. when a bug is released against software.. i occasionally expect
propriety closedsource software not to have the _exact_ same vulnerability as
opensource for obviously implementation specific vulnerabilities.
maybe its pure paranoia..
> Isn't the ping of death from 1996 or so an example of similar problem?
lol.. bring back nestea and teardrop also!
maybe some targa warez?
hehe.
its funny that almost every tcp/ip stack at the time didnt handle ip packets >
64k correctly.. well.. the rfc says ip packets arent this big, so
why the hell should anyone consider handling them!
> >
> > anyway.. int strlen() is obviously incorrect, as strlen() returns size_t,
> > which is specified as an unsigned integer.
> >
>
> unsigned strlen() is also incorrect on 64bits iirc :)
yep.. who knows what a size_t is in relation to anything, really :)
specs afaik, say it is an unsigned integer.. but dont specify if its
short unsigned int, unsigned int, or unsigned long.
unsigned long long ?
to be honest.. the specs for all this make me confused :)
> on IA32 there is a problem with memset(), but on other architecture it may be
> possible to have enough address space to play with int.
well.. the point with memset i was trying to make, is that when a memset
occurs, it modifies the backing store. MAP_SHARED may be useful somewhere I
guess for this ;-)
> georgi
>
(oh well.. i guess there goes away any .gov, nipc employment)
--
Silvio
Powered by blists - more mailing lists