Bugtraq mailing list archives
Re: Exploit of rpc.cmsd
From: appro () FY CHALMERS SE (Andy Polyakov)
Date: Sun, 11 Jul 1999 13:43:39 +0200
Hi, everybody!The calendar manager (rpc.cmsd) on Solaris 2.5 and 2.5.1 is vulnerable to a buffer overflow attack...... Shall we have a look? Let's 'cm_lookup -cblah-blah () 2 6 host' and simultaneously 'truss -p <rpc.cmsd's pid> on2.6.host: ... statvfs("/var/spool/calendar/callog.blah-blah", 0xEFFFF88C) Err#2 ENOENT open("/usr/spool/calendar/callog.blah-blah", O_RDONLY) Err#2 ENOENT ... ... 1fb80: 40 01 1d 02 call malloc 1fb84: 90 10 21 01 mov 257, %o0 1fb88: b8 10 00 08 mov %o0, %i4 ... 1fbc4: 90 10 00 1c mov %i4, %o0 1fbc8: 40 01 1d 0e call sprintf 1fbcc: 94 10 00 10 mov %l0, %o2 1fbd0: 90 07 bf 24 add %fp, -220, %o0 1fbd4: 40 01 1d 38 call strcat 1fbd8: 92 10 00 1c mov %i4, %o1 1fbdc: 90 07 bf 24 add %fp, -220, %o0 1fbe0: 40 01 1d 38 call statvfs 1fbe4: 92 07 bf 64 add %fp, -156, %o1 ... Doesn't look good, huh? Indeed! %i4 points at 257 large buffer allocated with malloc. Then they do sprintf to it and then strcat it to %fp-220 resulting in %fp-220 pointing at "/var/spool/calendar/callog.blah-blah". What makes me worried is that nor sprintf or strcat performs boundary checks. Well, one can still instruct sprintf in the format line... BUT! The buffer %i4 points at is 257 bytes large. And how much do we have left in %fp-220? What do they smash with stack overruns? Something between %fp and %fp-96, right? Secondly "/var/spool/calendar/callog." is a 27 char long constant. So that we can't have more than 220-96-27=97 bytes left in %fp-220 which is way less than 257 %i4 points to...
After a bit of extra thinking I've realized that attack against the current stack frame won't work and you can only attack the frame below. In addition in order for such attack to work, the program should experience a context switch (malloc *may* cause one if it has to ask kernel for more memory:-) before strcat. You'll also may have to screw caller's registers other than return adress and then the program may simply crash before the exploit code gets the opportunity to violate the security of attacked system. I mean the attack may be more sophisticated (if possible at all) than you might have imagine from my previous post. Well, all above was about SPARC. On Intel in turn the attack aginst the current frame is *perfectly* possible and should work like a charm. Strangely enough corresponding Intel patch is one revision level down and doesn't mention "buffer overflows in rpc.cmsd" at all. We also know that CDE code is shared among vendors and there's a chance that systems other than Solaris are vulnerable. Andy.
Current thread:
- Exploit of rpc.cmsd Bob Todd (Jul 09)
- Re: Exploit of rpc.cmsd Andy Polyakov (Jul 09)
- Re: Exploit of rpc.cmsd Andy Polyakov (Jul 10)
- Re: Exploit of rpc.cmsd Andy Polyakov (Jul 11)
- Re: Exploit of rpc.cmsd John Hall (Jul 12)
- Re: Exploit of rpc.cmsd Aleph One (Jul 13)
- Re: Exploit of rpc.cmsd Casper Dik (Jul 14)
- Re: Exploit of rpc.cmsd Dan Astoorian (Jul 15)
- Re: Exploit of rpc.cmsd Casper Dik (Jul 15)
- Re: Exploit of rpc.cmsd Aleph One (Jul 13)
- <Possible follow-ups>
- Re: Exploit of rpc.cmsd Stephen C Woods (Jul 10)
- Re: Exploit of rpc.cmsd Casper Dik (Jul 14)