Bugtraq: Re: Exploit of rpc.cmsd

[appro () FY CHALMERS SE (Andy Polyakov)]

> 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
> > blah-blah () 2 6 host' 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.