From: Noam Rathaus <noamr@beyondsecurity.com>
Date: Mon, 6 Oct 2014 18:40:20 +0300
To: Michael Meeks <michael.meeks@collabora.com>
Cc: officesecurity@lists.freedesktop.org

LibreOffice Impress Remote Control Use-after-Free Vulnerability
===============================================================

The Bug
-------
In LibreOffice 4.0.0 and later, a new feature was added for remote
control capabilities in Impress. Users can run a smart phone
application to communicate with Impress over a custom protocol to switch
slides and the like. By default whenever Impress is started, it
immediately begins listening on TCP port 1599 on all interfaces.

The protocol used by Impress is currently very simple and is described
here:
https://wiki.documentfoundation.org/Development/Impress_Remote_Protocol

A simple initial handshake message sent by clients looks like:
LO_SERVER_CLIENT_PAIR
client name
client PIN


The message is terminated with a blank line. Encoded, the above message
looks like:
"LO_SERVER_CLIENT_PAIR\nclient name\nclient PIN\n\n"


The source code responsible for handling these requests is in:
sd/source/ui/remotecontrol/Server.cxx
sd/source/ui/remotecontrol/BufferedStreamSocket.cxx

Please see attached the annotated versions of these files, respectively
named:
lo-4.2.6.2-Server_annotated.csv
lo-4.2.6.2-BufferedStreamSocket_annotated.csv


(If you open these in a spreadsheet, be sure to resize columns and rows
so you can actually read the text comments in the right column.)


The vulnerability lies in the line:
118: if ( ! pSocket->readLine( aLine ) ) delete pSocket;

If readLine returns 0, then the pSocket is freed, but execution does not
stop there. Most likely what was intended is:

if ( ! pSocket->readLine( aLine ) )
{
delete pSocket;
/* ... clean up other data structures, as needed, due to this error
condition ... */
continue;
}

However, pSocket continues to be used for the rest of this while loop
iteration. pSocket is used in a few places, but most interestingly,
during the inner do...while loop when the remaining portion of content
is read in. If the freed memory can be overwritten sometime before or
during these later readLine calls, then either the readLine vptr can be
hijacked, or the buffer counters stored within pSocket can be messed
with to generate a subsequent overflow or something similar.


We can easily supply data to this socket while still causing readLine to
return 0
on vulnerable line of code. Looking at the readLine implementation in
BufferedStreamSocket.css, input is capped at 20000 bytes.
(MAX_LINE_LENGTH is the key check we're targeting.)

So for this first request, we want to send a very long PIN, since that is
what
is being read in on the vulnerable line of code.

A one liner like this will cause a reliable crash of Impress and the
rest of LibreOffice:
python -c 'print("LO_SERVER_CLIENT_PAIR\nMYNAME\n"+("A"*30000)+"\n\n")' |
nc 127.0.0.1 1599



Exploitation
------------
I've never exploited a use-after-free bug before, but here's what I
think might be possible, based on my observations--

Step 1: overwrite pSocket
I have definitely seen cases where my socket-supplied strings are
written over the freed pSocket object. I'm just not sure how reliable I
can make that happen. There are two versions of the name string that
get converted to UTF-16 strings. Since the socket read functions care
only about the existence of '\n' bytes, it should be possible to feed
multi-byte UTF-8 strings in as the name line in order to create nearly
arbitrary UTF-16 strings, including ones in pointer ranges.

Note that when sending data to the 1599 port, one can trickle strings in
small chunks by writing to the socket and flushing it repeatedly. This
may give us options for creating smaller objects on the heap that are
more likely to land in the appropriate freed memory.


Step 2/Option A: vptr -> vtable control
If in Step 1 it is possible to control the vptr of pSocket, then we need
a way to heap spray to reliably point vptr to a crafted vtable. Using
the socket interface on port 1599, it is possible to spray maybe
20-40kbytes of data into the heap, but perhaps not much more. It may be
necessary to have the user load up a malicious presentation file first
that contains lots of data to fill in as the vtable. After gaining
control of EIP through the vtable, you'd need to use a ROP chain.

Step 2/Option B: pSocket overflow
If in Step 1 we can overwrite pSocket's data fields but not the vptr, we
could still try to alter the aRead and aBuffer properties to create
an overflow or other secondary memory corruption during the next
readLine call. However, in many tests I performed, I found that often
the pSocket vtable had been overwritten by another object's vtable by
the time it reached the do ... while loop. Not sure if that can be
avoided.





Work-Around: Disable Impress Remote
-----------------------------------
While the remote control service is enabled by default, it can be
disabled easily through the following menus:

1. Open LibreOffice, go to "Tools -> Options..."
2. Select "LibreOffice Impress -> General"
3. Uncheck "Presentation -> Enable remote control"



Affected Systems
----------------
This bug should affect any system running LibreOffice 4.0.0 and later,
which includes Ubuntu versions:
14.04.1 LTS (Trusty Tahr)
13.10 (Saucy Salamander)
13.04 (Raring Ringtail)

Not sure about 12.10 (Quantal Quetzal) as it is no longer supported
Does not affect 12.04.5 LTS (Precise Pangolin) since it runs 3.x

Obviously, any recent desktop Linux distro would be affected in addition
to Windows systems with LibreOffice (all 6 of them ;-).