[vlc-devel] Re: [RFC] VLC denial of service bugs

[Skywing]

You can do similar on Windows with Structured Exception Handling (SEH).  However, I would not recommend this approach.

Even a seemingly innocent bogus read like this can sometimes lead to code execution; for example, on Windows, there is a mechanism to set a global last-chance handler (SetUnhandledExceptionFilter) for exceptions (e.g. access violations [segmentation fault in UNIX-land]).  This mechanism essentially involves a function pointer that is called when nobody has handled an exception (as would be the case with an AV due to a read on a bogus address as you have described here).

This turns out to be a bad thing because there is no way to effectively chain these last-chance handlers with eachother; the mechanism is essentially a wholesale replacement of a function pointer, in which any hook chain must be removed in the reverse order of creation or a dangling function pointer may result.

This point turns out to be bad as the Microsoft CRT, when static linked into a DLL, will always register an unhandled exception filter as part of its C++ exception handling support (no way to suppress this behavior); the end result is that in a program with many DLLs that might be demand-loaded and demand-unloaded, there is a high probability that a dangling function pointer might result.  Combined with a so-called "heap spray" attack and an "innocent", "non-exploitable" crash bug, this can turn into code execution if an attacker can allocate memory over a dangling unhandled exception filter function pointer.

Now, I don't know if this directly applies to VLC (e.g. whether your CRT has a similar behavior), but falling into the trap of "it's just a crash bug, we don't really need to worry about it" is not good at all; even if something seems like "just a crash bug", that doesn't mean that a clever attacker won't be able to do something more "interesting" with it given a bit of creative thinking.

This particular scenario may seem contrived, but it has been successfully demonstrated to be effective against real-world programs, namely, IE ( see http://www.uninformed.org/?v=4&a=5&t=sumry ).

-----Original Message-----
From: vlc-devel-bounce at videolan.org [mailto:vlc-devel-bounce at videolan.org] On Behalf Of Christophe Massiot
Sent: Monday, January 15, 2007 6:30 PM
To: vlc-devel at videolan.org
Subject: [vlc-devel] Re: [RFC] VLC denial of service bugs

At 22:51 +0200 15/01/07, Rémi Denis-Courmont wrote:

>As regards the last exploit, it's been fixed (by Sigmund, IIRC). Wrt
>zzuf, the MPEG1/2 bugs seems to be within libmpeg2; I cannot reproduce

I happen to have some information on the libmpeg2 bug. A few years 
ago I discussed with walken the libmpeg2 bugs remaining to be fixed. 
Walken told me that he was aware of only one type of crash : invalid 
motion vectors. The crash happens when the motion vector points 
outside of the boundaries of the reference picture. This is easy to 
trigger with zuff (change one bit in the motion code of macroblocks 
in the corners, and *paf*).

Unfortunately checking the boundaries of every motion vector is quite 
CPU-intensive (add several conditional branches in the macroblock 
loop, which is the main loop...), therefore walken decided against 
adding those checks. Some people may debate whether it is still 
appropriate now that a single core can decode 100 MPEG-2 streams in 
parallel, but bear in mind that it not that over-powered with 
1920x1080 HDTV content (yet).

It is interesting to notice that the segmentation fault is a read 
error (outside of the reference picture) but in no way the bug allows 
to write to random locations. Walken suggested (but never wrote the 
code) to set a signal handler on SIGSEGV, and whenever it got 
triggered, to longjmp to a safe location and resync on the next slice 
start code. Such approach has drawbacks too : playing with 
sighandlers in a lib is rarely a good idea, especially within 
multi-threaded programs, and I don't know if there is an equivalent 
under non-UNIX operating systems.

-- 
Christophe Massiot.

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html