Home page logo

bugtraq logo 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
... Shall we have a look? Let's 'cm_lookup -c
blah-blah () 2 6 host' and simultaneously 'truss -p <rpc.cmsd's pid> on

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.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]