rpc_exploit.txt

`Subject: Re: Exploit of rpc.cmsd  
To: [email protected]   
  
  
> 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 -c  
> [email protected]' and simultaneously 'truss -p <rpc.cmsd's pid> on  
> 2.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.  
`