> Digest Name: Daily Security Bulletins Digest > Created: Thu Oct 21 3:00:03 PDT 1999 > > Table of Contents: > > Document ID Title > --------------- ----------- > HPSBUX9910-104 Security Advisory regarding automountd > I was involved with tracking down this vulnerability and reporting it to HP, SGI, and CERT, so I thought I'd contribute a bit more info for those you of (justifiably!) worried about this. The exploit code has been around for a while, but was written in a way that made it pretty system specific and would be more difficult to build today (because the system it was written for is getting out of date :) ) Apparently it is not the one that automountd (aka autofsd) was "fixed" for previously. To make our testing easier, I modified it to be general and build and run on about any system, which would make a whole lot more dangerous if I posted it (especially now when there are no vendor patches available) so I will not be doing that at this time. I will do so later after the vendors have had a chance to do their thing. Who is vulnerable? As far as I know, all of the new generation automounters (the ones that use RPC, support executable maps, and no longer have the /tmp_mnt directory) are vulnerable. I have only personally tested against HP-UX 10.20 and IRIX 6.5.4, both are vulnerable. HP-UX 11.0 adds a wrinkle to make things harder, but I suspect the exploit could be modified and it would still work. I have no reason to believe IRIX 6.5.5 changed anything to make it not vulnerable. I have not tested against anything else -- HP, SGI, and CERT have a copy of the exploit, so all the vendors should have it by now. I know that people with e.g. Sun, IBM, etc. systems would like to know if they are vulnerable. So I will make the exploit available to the moderators of Bugtraq if they wish to ask me for it, and they can make it available to people they trust to test it on other systems, and the findings can be reported. I just don't think it would be fair to the vast majority of sysadmins out there to just post it to the world now, when there is no good fix. The vulnerability lets anyone anywhere run anything as root on your system. Since it uses RPC, you can't use tcpwrappers to block it or filter an extra port or two on your router. Unless you have an application level firewall or use the "deny all ; allow these few things" type of router rules, you can get hit. Even with a firewall, you are still vulnerable to anyone on the inside (I hope you trust them!) The exploit does not require root privileges to run (but it does require Unix, at least without a lot of work) What can you do? If you are running that new generation automounter, unless/until you know for sure you are not vulnerable, I would go back to the old generation one immediately (the one that uses /tmp_mnt) That one is not vulnerable. Who is using this exploit? Some systems at the U of Iowa were hit in the early AM on Monday the 18th, the footprint was adding "+ +" to /.rhosts and creating a file /tmp/bob and trying to run "inetd /tmp/bob". An old script kiddie script, used in many previous attacks on various other holes. This is the first we've seen of it, and it seems like the vendors and CERT were very much caught off guard that the automountd fix for the previous exploit was incomplete. Ideally CERT would post a notice about this right away, and update it as soon as they get info from each vendor on the results of their testing, but unless they have changed their policies from what they were in the past, I don't think that this is going to happen, which is why I made the offer to send the exploit to the moderators of Bugtraq so they can determine what other systems are or are not vulnerable. Everyone else, please do NOT email me about this asking me for the code, asking me if OS XXX is or is not vulnerable, or ask me to try the exploit against one of your systems. I had recently been thinking about "upgrading" to the new automounter (I had mainly been dragging my feet waiting for it to become stable on HP-UX) But now I don't think I ever will until they provide a way to completely disable executable maps (and put a sanity check in the code right before the fork() and exec(), to be extra sure no one finds a new code path to get around the checks) IMHO that code has no business existing. I wonder how many people really even make use of that misfeature? -- Douglas Siebert Director of Computing Facilities douglas-siebertat_private Division of Mathematical Sciences, U of Iowa I'm not too interested in caller ID. But caller IQ, I'll pay a lot for that!
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:08:37 PDT