The following reply was made to PR kern/29124; it has been noted by GNATS.

From: List Mail User <track@Plectere.com>
To: andreas@planix.com, gnats-bugs@NetBSD.org
Cc: gnats-admin@NetBSD.org, kern-bug-people@NetBSD.org
Subject: Re: kern/29124: Invalid TCP connection (from hacker/spam site) causes diagnostic panic
Date: Tue, 25 Jan 2005 23:40:25 -0800 (PST)

 	Yes, it looks very similar.  If fact, while I'm unfamiliar with the
 domain SUPERSTARAVATAR.COM, its whois contact data is suspicious - the email
 for the contacts is "polly_pandemonium@yahoo.com" (valid, I checked) and the
 name servers are in the domain "SECURESERVER.NET", a favorite with both hacker
 and spammer sites.  Also, the "mail addr" for the DNS of SECURESERVER.NET is
 handled by a private registration through GoDaddy hiding the actual domain's
 controller.  The domain in my case is *possibly* involved in fraud and IP
 hijacking.  Both are *not normal* domains.  Also, the contact telephone number
 for SUPERSTARAVATAR.COM is forwarded through at least two PBXs before reaching
 a "fast busy" signal - more not normal behavior, and a reverse lookup of the
 address "2519 Mission St. SF, CA 94110" gives a "Moral Minority Inc." using
 the same telephone number.  Very bad mojo;(  Also, that site resolves to the
 'CNAME' record "ip-64-202-167-129.secureserver.net" which does *not* have
 a corresponding 'A' record despite being hosted on a GoDaddy network, i.e.
 purposefully invalid DNS records!  (In my opinion, GoDaddy is quite upstanding,
 but, being so large, they are often "taken-in".)
 
 	Also, the site at 64.202.166.12 is apparently part of he same swip,
 uses the same name servers as SUPERSTARAVATAR.COM, but is registered through
 "wildwestdomains.com" a purely hacker/spammer service provider (Ralsky, iMedia,
 and Andrew Westmoreland have all used them extensively for spam domains).  Also,
 the DNS servers' domain "SECURESERVER.NET" is a private registration through
 "Domain Services, Inc.", another hacker/spammer provider (I've *never* seen
 a legitimate customer of these guys - and they charge alot of money). Further,
 wdprs,internic.net shows the "registry whois" server to be the host named
 "SECURESERVER.NET.EPHARMACY-RX.COM" - a clear sign of a questionable operation.
 And the domain "EPHARMACY-RX.COM" uses name servers in the domain named
 "BADWHOISSHUTDOWN.COM" which are allocated inside of a swip run by Google
 (i.e. at IP 216.239.35.100) which resolves to www.google.com, but does *NOT*
 serve and DNS (or even have port 53 open, either TCP or UDP).
 
 	I did file the bug as confidential and "high" priority as this
 seems to be directed specifically at at least some *nix flavors.  It seems
 almost certainly to be a purposeful exploit (the mere blocking of almost all
 commercial proxies is it self suspicious), and the "weird" messages the other
 proxies I tried get (very different than my lynx on cygwin on XP dump)
 regarding "packet too large" or "malformed html reply" show that something
 else is also happening at these sites.
 
 	It seems possible that some hacker "just discovered" this, but it is
 clearly being used maliciously by some sites now.
 
 	After identification, this should probably be reported to CERT etc.
 If I have time, I'll plug in an old hub and try to capture the conversation
 from a third machine in promiscuous mode (like everybody else, all my equipment
 is on switches, but I keep a few old hubs just for debugging).
 
 	I think maybe the existing reports (at least the comments about the
 domain SUPERSTARAVATAR.COM) and my own should be combined, and the issue is the
 first I've found which definitely warrants "confidential" treatment - It is
 already being used maliciously - I have to wonder how do the other 'BSDs react
 to this exploit and what does Linux do?
 
 	I don't think this is as much a bug as the need for some more type of
 "defensive" checking to be performed - a quick perusal of Stevens and Comer
 show nothing obviously incorrect in the code - more that convinces me that
 someone has found a flaw/loophole in the original design.
 
 	Well, my half hour of digging into the malefactors is up now.  I
 didn't expect to find such an easy to trace history of this problem and some
 of the miscreants using it.
 
 	Bye,
 
 	Paul Shupak
 
 P.S.  I've removed "netbsd-bugs" from the "CC:" list for the reasons above.