By "read buffer" I assume they mean reading data from the AVI stream into a buffer (ie. writing to and beyond the buffer memory). Buffer overflow can corrupt adjacent return addresses on the stack since those are usually in higher memory, therefore above the buffer, therefore overwritable if you can write beyond the end of the buffer. This is the "classic" stack smashing exploit, somewhat mitigated these days if your code was compiled with hardening. Or if the buffer is on the heap then any adjacent data structures which might contain pointers, especially function pointers, can be overwritten. Or inter-allocation malloc structures can be corrupted, see next point.
Double free just generally corrupts the malloc structures and all bets are off afterwards. Modern libcs usually have mitigations so they can detect certain double frees and will deliberately abort the program, but this depends on your distro having enabled hardening flags when compiling VLC (which most distros do these days).
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.
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.
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.
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.
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.
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.
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.
12 comments
[ 2.7 ms ] story [ 43.0 ms ] threadDouble free just generally corrupts the malloc structures and all bets are off afterwards. Modern libcs usually have mitigations so they can detect certain double frees and will deliberately abort the program, but this depends on your distro having enabled hardening flags when compiling VLC (which most distros do these days).
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.
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...
[1]: https://en.wikipedia.org/wiki/Return-oriented_programming
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?
It turns out that a lot of programs can be tricked into interpreting a family of languages called rop chains.
VLC might run quite a bit worse as well, because hardware video decoding is most likely unavailable in a VM.
Would like it if OS’s ran binaries in micro-vms by default. At least with a very much de-privileged container.