The attack was mounted from a FreeBSD 2.2 machine which itself was on
a 10Mb/s ethernet twisted pair connection. (I'm not sure network
speed/interface is an issue here, however I'm including it to be as
verbose as possible.) The code compiled with no errors and appeared
to run as 'designed'.
On the target machines, there appeared to be no effect, including high
loads, excessive memory usage and no complaints in system log files
etc... I was able to telnet/rlogin to the target machines both
during and immediately after the attack with no appreciable delay.
Whether or not this is a direct result of the Kerberos v5 1.0.4
binaries being in place of the stock Solaris binaries or some function
of patchlevel is (for me) inconclusive at this point in time as I was
not prepared to test attack against the stock binaries.
SunOS xxx 5.5.1 Generic_103640-09 sun4u sparc
SunOS xxx 5.5.1 Generic_103640-09 sun4m sparc
SunOS xxx 5.5.1 Generic_103641-12 i86pc i386
--Robert Sink - Asst. Dept. Head - Computer/Network Services Univ. of Maryland Chesapeake Biological Laboratory - Solomons, MD. [o] 410/326-7306
On Dec 13, Jason Zapman II (zapman@CC.GATECH.EDU) wrote: > This is sunkill.c > > It Affects at least solaris 2.5.1 machines, both sun4c and sun4m > achitecutures. I imagine it affects all solaris 2.5.1 machines, both sparc > and x86, but im not sure. It basically works by opening a telnet > connection on the victim machine and sends a few bad telnet negotiation > options, then flooods the port with lots of ^D characters. This uses all > the streams memory (i think) on the victims machine and causes the kernel > to get very angry. The machien crawls to a halt, the cursor in X stops > moving, the machine is unresponsive to the network. Its a bad situation > all around.