
VLC media player 3.0.6 and earlier: Read buffer overflow and double free - qndev
https://www.videolan.org/security/sa1901.html
======
rightbyte
How can a read overflow or a double free cause remote code execution?

~~~
vardump
Because the allocation memory address patterns are pretty predictable, heap
overflows can be used to modify state in an object known to be very probably
adjacent. Even read overflows enable the attacker to read the required state
to make some other exploit reliable.

Double free implies the attacker can control victim object's memory through
another object (which the attacker can somehow influence) occupying the same
addresses in memory.

So the attacker can now carefully craft state that causes the desired (=bad)
behavior in the original buggy object. Or to use it to learn something about
the buggy object's state, like code locations in memory (= reading C++ virtual
method pointers / function pointers directly _or_ indirectly) possibly leading
to defeating ASLR and other protection mechanisms. This leads into various
exploit scenarios.

Hopefully I explained this well enough... it's pretty straightforward really.
Especially if you step through in a debugger.

Double frees (and use after frees!) can be _very_ dangerous.

~~~
MuffinFlavored
Why is the memory VLC uses marked executable? Wouldn't read/write suffice?

~~~
vardump
Not sure what you mean.

There was no mention about executing anything in the heap (or stack for that
matter). I have no reason to believe VLC maps (a part of) its heap RWX (=read
+ write + execute). This kind of exploits don't even require memory to be
executable.

C++ virtual methods cause the compiler to add vPtr (that is writable, because
it's contained in the object) and vTable. Modifying vPtr can be used for
making certain class execute code somewhere else (or mostly crashing :-)).

However, neither vPtr and vTable themselves are executable. vTable doesn't
even need to be writeable.

If you can somehow do indirect vTable reads, you'll learn ASLR [0] base for
the module. With that information you might be able to circumvent ASLR, and
eventually be able to pull off code execution through a ROP [1] chain.

A C-style function pointer would be easier to use for a similar effect.

[0]:
[https://en.wikipedia.org/wiki/Address_space_layout_randomiza...](https://en.wikipedia.org/wiki/Address_space_layout_randomization)

[1]: [https://en.wikipedia.org/wiki/Return-
oriented_programming](https://en.wikipedia.org/wiki/Return-
oriented_programming)

~~~
MuffinFlavored
> This kind of exploits don't even require memory to be executable.

If this exploit is a memory leak, and the memory isn't executable, how do the
malicious contents that get put into the leaked memory get executed?

~~~
vardump
Possibly through a ROP chain. Abusing VLC's code itself. You don't need memory
that's writeable and executable for that. Check the Wikipedia link in my
comment about ROP exploits.

~~~
gubbrora
Just elaborating on this. One way of looking at it is that we turn the
attacked program into an interpreter thus bypassing the requirement for
executability.

It turns out that a lot of programs can be tricked into interpreting a family
of languages called rop chains.

------
ryacko
Personal preference to avoid these sorts of exploits is by using a virtual
machine with a browser VM from Microsoft, although by default those browser
VMs are run in admin mode.

~~~
vardump
Be aware that there have been plenty of virtual machine escape
vulnerabilities. If enough people did same, the attackers would start to
exploit that vector. Or a target interesting enough.

VLC might run quite a bit worse as well, because hardware video decoding is
most likely unavailable in a VM.

~~~
ec109685
Exploits around hardware implementation of bitstream deciding is more of a
constrained problem than arbitrary and legacy file formats that vlc needs to
decode.

Would like it if OS’s ran binaries in micro-vms by default. At least with a
very much de-privileged container.

