Re: samba base64 encode vulnerability

[infamous41md () hotpop com]

On Fri, 23 Jul 2004 23:08:56 -0400
Valdis.Kletnieks () vt edu wrote:

> On Fri, 23 Jul 2004 02:24:39 EDT, infamous41md () hotpop com  said:
> > a question about exploiting the samba vuln.
> >
> >     if (*s == '=') n -= 1;
> >
> >     /* fix up length */
> >     decoded.length = n;
> >
> >     memcpy(s, decoded.data, decoded.length);
>
> > if n == 0 before it is decremented, then it will wrap around to ~0 and the
> > memcpy will eventually SEGFAULT.  but can you exploit it still?
>
> I haven't actually looked at the code, but several things come to mind:
>
> 1) Sometimes, being able to cause a segfault is more than sufficient by itself,
> if your goal is to cause a DoS....
>
> 2) Being able to cause a DoS is a good start to playing a MITM attack against
> somebody else...
        im strictly interested in remote code execution, so:

> 3) A full root-shell type exploit will depend on whether you can cause the
> memcpy() to leave interesting bytes at the right places - remember that you can
> potentially go quite a long way before actually segfaulting.  Note well that
> not only will we walk off the end of the string 's', but we will ALSO most
> certainly go strolling off the end of decoded.data.  So focus your attention on
> what's immediately following decoded.data in memory, keeping in mind that you
> may have to rely on "stuff left over by previous packet".  So you may end up
> having to send ONE bogus packet to force an malloc() or leave stuff on the
> stack, and then the NEXT packet walks off the end of decoded.data and picks up
> what was in the malloc or left on the stack by a previous function.
        could you expand further on this?  the problem as i see it, is that the 's' string is located on the stack.  
above the stack in a linux process is kernel space.  once you start plowing your way up the stack in memcpy, sure u can 
overwrite return addresses, etc, but when memcpy hits 0xc0000000 it will segfault and process will be killed.  what im 
unsure of is if there is still some way to seize control despite this.  as i see it, there is no way to stop memcpy 
from eventually faulting.  i remember in an openBSD kernel exploit by noir he had the same problem with copying too 
much data, and he solved it by turning off read permission on a page located after the buffer being copied from.  once 
the buffer was copied, the unreadable page was hit, copying stops, process gets sent a SIGSEGV, which was then caught, 
and exploit goes on.  but that is not possible here of course.

> Hopefully those thoughts help....


-- 
-sean