Re: Apache Vulnerability through a Proxy?

[Ben Laurie <ben () algroup co uk>]

Ulf Bahrenfuss wrote:
> Hi!
>
> Does anyone know, if the chunk handling vulnerability carries through
> a proxy i.e. Squid or Webcache? (Updating is currently not possible,
> because it is not the plain apache, but the Oracle IAS flavour...)
>
> Or has anyone further information how this vulnerabilty really works?

Here's an analysis I wrote for iternal use at the ASF - it doesn't go 
into detail on the shellcode (which is just the usual shellcode), but 
does explain how the expected SEGV from overrunning the stack is 
avoided. Note that someone (sorry, forgotten who) posted a similar 
generic analyis a day or two ago - this one was independently arrived at 
 and refers to the Gobbles attack specifically.

First, the exploit code puts stuff on the stack (legitimately, in 
buffers). It then arranges a negative offset, as previously described, 
to be handed to memcpy. Here's where it gets cute. memcpy has memmove 
semantics (i.e., it copies in the correct direction to handle 
overlapping source/dest) on both OpenBSD and FreeBSD (in fact, I believe 
this is a requirement for this exploit to work on any system where the 
stack grows downwards). As a result, when the memcpy is attempted, it is 
done backwards (i.e. the copy starts at source+length-1 -> dest+length-1 
and downwards for length bytes). Now, here's the cute bit. memmove (et 
al) are optimised to copy in 4 byte chunks, for speed. This means that 
they have to copy the leftover bytes separately. This is handled by 
copying the odd 0-3 bytes before the remaining bytes.

So, if you arrange for the negative offset of the buffer to point at 
where the length is stored on the stack, then when these odd bytes are 
copied, you can modify the length. What they do is modify an initial 
length of 0xffffxxxx to 0x0000xxxx - note that the length is also the 
offset, so there is also a certain amount of luck involved, but all that 
is needed is for the offset to be small enough that the length remains 
big enough to zap enough stack (since the offset is a few hundred, that 
leaves the length at near to 64k, which is plenty to zap a few return 
addresses). Then, when the length is reloaded to do the second copy, it 
is miraculously smaller (I boggled first time I saw this in the 
debugger), and doesn't cause the expected SEGV, just nice corruption of 
the stack, as required![1]

So, to illustrate with source:

0x400f9d6c <memcpy>:    push   %esi
0x400f9d6d <memcpy+1>:  push   %edi
0x400f9d6e <memcpy+2>:  mov    0xc(%esp,1),%edi
0x400f9d72 <memcpy+6>:  mov    0x10(%esp,1),%esi
0x400f9d76 <memcpy+10>: mov    0x14(%esp,1),%ecx
0x400f9d7a <memcpy+14>: cmp    %esi,%edi
0x400f9d7c <memcpy+16>: jae    0x400f9d94 <memcpy+40>
...

at this point, we've decided to go backwards, edi is dest, esi is source 
and ecx is count (aka -146 aka ffffff6e)

0x400f9d94 <memcpy+40>: add    %ecx,%edi
0x400f9d96 <memcpy+42>: add    %ecx,%esi

Now we are pointing at the "end" of the buffers (i.e. somewhere down the 
stack from them, and, lo and behold, edi now points at the two MS bytes 
of the count)

0x400f9d98 <memcpy+44>: std
0x400f9d99 <memcpy+45>: and    $0x3,%ecx

calculate spare bytes (2 in this case)

0x400f9d9c <memcpy+48>: dec    %edi
0x400f9d9d <memcpy+49>: dec    %esi
0x400f9d9e <memcpy+50>: repz movsb %ds:(%esi),%es:(%edi)

and copy them - in fact two zeroes are copied, so the length is now 
0000ff6e.

0x400f9da0 <memcpy+52>: mov    0x14(%esp,1),%ecx

load the length again (now ff6e)

0x400f9da4 <memcpy+56>: shr    $0x2,%ecx

divide by 4

0x400f9da7 <memcpy+59>: sub    $0x3,%esi
0x400f9daa <memcpy+62>: sub    $0x3,%edi
0x400f9dad <memcpy+65>: repz movsl %ds:(%esi),%es:(%edi)

and copy that many longs (i.e. just shy of 64k bytes). Here is where we 
would have gone bang with a SEGV, but don't coz of the cunningness.

0x400f9daf <memcpy+67>: mov    0xc(%esp,1),%eax
0x400f9db3 <memcpy+71>: pop    %edi
0x400f9db4 <memcpy+72>: pop    %esi
0x400f9db5 <memcpy+73>: cld
0x400f9db6 <memcpy+74>: ret

return to a corrupted return address (or is it the next one up that's 
corrupted? not sure, don't care). And hey presto, remote shell.

Note that glibc is _not_ vulnerable in this way, so I have no idea how 
the Linux attack works. I have not examined Solaris.

Cheers,

Ben.

[1] For those not familiar with this class of exploit, the stack is 
corrupted such that the return address for some function call points to 
code which spawns a shell, which is then used by the attacker to have 
his or her evil way with your machine.

--
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff