Bugtraq mailing list archives
Irix: more suid fun/exploits
From: volobuev () t1 chem umn edu (Yuri Volobuev)
Date: Thu, 28 Nov 1996 05:55:38 -0600
Howdy, In our continuing effort to make bugfree future closer and have some fun on the way, one more example of buggy Irix program carrying suid bit is brought to you for your added enjoyment. If it sounds like a broken record to you, that's because it is. Bugs are there, and a lot of them, all look alike, so the gap between regular and superuser in Irix is closing. It's hardly there right now, in fact. ABSTRACT /var/rfindd/fsdump is owned by root, has suid bit set by default and has bugs. It allows local users to create zero-length files anywhere on the system. If the file already exists, content is lost. With little work, it can be converted to root compromise. 5.3 is is affected, 6.2 doesn't seem to have it, at least not on a standard installation. FIX. chmod -s /var/rfindd/fsdump This will break it. But the whole idea of rfind is sort of risky, and I haven't heard about people using it a lot, so if you are concerned about the security on your system, you may want as well to do this: chkconfig rfindd off Or, alternatively, you can wait for a patch from SGI. Chances are, it'll be out this millenium (but I wouldn't bet on it). Full story. Yes, I know it's Thanksgiving and people are supposed to eat turkey and give thanks, not post exploits, but what the hell. For some people this is the best present. And I finally got some free time on my hands. Hacking fsdump doesn't require any standard steps. Just run it and see what happens. In the current directory, zero-length file is created, named after the dump file with extension .lock. For example, if your command is /var/rfindd/fsdump -F/tmp/rfd / then rfd.lock will be created. And it's owned by root. Sure sign. Rule of thumb tells us the next thing: symlink .lock file to somethign else, say, /.rhosts (yes, I know there are other means of hacking a system, but I just like .rhosts 'cos it's the easiest and I'm lazy). If there's no /.rhosts, it'll be created. If there was one, contents is gone, it's zero-length now. So right away we've got a great denial-of-service attack. Nuke on will. But with little work, it can go further than that. Suid programs are good in many ways, especially in how they handle non-standard situations. Most of them change effective uid to user's, or give up root privileges in some other way. To be precise, most of them _try_. Under normal conditions, it works. But what if /etc/passwd suddenly shrinked to zero size (maybe because somebody played with fsdump)? setreuid() will fail, but poorly written program, such as fsdump, will carry on anyway. So, remembering that fsdump can write logs (owned by user) cp /etc/passwd /tmp/passwd ln -s /etc/passwd rfd.lock /var/rfindd/fsdump -F/tmp/rfd / /var/rfindd/fsdump -L/etc/passwd -F/tmp/rfd / First fsdump will nuke /etc/passwd, so that the second one fails to give up root privileges. If you think you can now write to /etc/passwd, you are right. /etc/passwd will be owned by you. So edit it, delete all that crap that fsdump puts there, all you need is root::0:0::/:/bin/sh Now su and enjoy. Remember to restore the original password file, possibly fitting it for your needs at the same time and chowing it back to root. Complaints. Once again, why in the world is this thing root-suid? Who else except root is supposed to run it? rfindd? Man page says it needs to be suid to read raw device file. Hm. Experience shows that such things can be done without root-suid but by elaborate groups setup. If it's indeed to hard for SGI to implement, then fsdump needs to be run by root. Whe whole idea of rfindd user is too obscure to me. Anyway, why all "value-added" stuff in Irix is always written in a sloppy way? When I read phrases like "rfind is a fast, client-server adaptation of the find(1) command" it scares me. One more network daemon written in a sloppy way is the last thing I need, I don't want my machine to be a server for somebody's "fast client". Good thing it's dropped in 6.2 (though no one probably noticed). I now respect SGI for its self-confidence. Some other companies, for some reasons more worried about such low-priority things as security, tend to overreact when a hole is discovered in their software. Look at IBM. Bug was found in AIX that merely allows users to read first 256 bytes of normally unreadable files. Big deal. But IBM reacts right away and releases PTF shortly and while work is in progress, recommends people to remove suid bit temporarily. Now look at SGI. Severals exploits are posted that provide easy root for everybody. Weeks go by, SGI is confident and silent, no comments, no patches. Still way to go to catch up with HP, of course, but it's on the right track. cheers and happy holidays, yuri Always speaking for myself and only for myself
Current thread:
- Re: BOOTP/DHCP security itudps (Nov 27)
- <Possible follow-ups>
- Re: BOOTP/DHCP security itudps (Nov 27)
- Re: BOOTP/DHCP security Benedikt Stockebrand (Nov 27)
- Re: BOOTP/DHCP security itudps (Nov 27)
- CIAC Bulletin H-08: lpr Buffer Overrun Vulnerability David Crawford (Nov 27)
- Re: BOOTP/DHCP security Valdis.Kletnieks () vt edu (Nov 28)
- Irix: more suid fun/exploits Yuri Volobuev (Nov 28)
- Re: BOOTP/DHCP security Alan Cox (Nov 28)