.
--
Robert Wesley McGrew
http://cse.msstate.edu/~rwm8/
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
Just got around to looking at it, and from where I sit, it appears to be
merely an annoyance, apart from fringe circumstances where discernable
audio output from a workstation is critical and is disrupted by this. In
that case, any bgsound, remote or local, is undesirable.
The file accessed is
Good of a point as any to jump into this, with a couple of questions to
steer conversation towards something resembling productivity ;). For the
record, I support full-disclosure with reasonable vendor notification,
taking into account a time to acknowledge and a time to patch, and I also
process
On Mon, 28 Jul 2003, Robert Wesley McGrew wrote:
2) For this DCOM RPC problem in particular, everyone's talking about
worms. How would the worm know what return address to use? Remote OS
fingerprinting would mean it would be relatively large, slow, and
unreliable (compared
On Mon, 28 Jul 2003, Schmehl, Paul L wrote:
2) For this DCOM RPC problem in particular, everyone's
talking about worms. How would the worm know what return
address to use? Remote OS fingerprinting would mean it would
be relatively large, slow, and unreliable (compared with
Slammer),
As far as your code is concerned any number that suits
(real_vuln_protocol)+256*n should crash the machine. However, this is
meaningless, since, as you say, the IP header's protocol field is only 8
bits, so you can generate larger numbers all day, but only your
least-significant 8 bits are being
