VLC Player 2.1.5 Write Access Violation Vulnerability
Title : VLC Player 2.1.5 Write Access Violation Vulnerability Discoverer: Veysel HATAS (vhatas@gmail.com) Web page : www.binarysniper.net Test: Windows XP SP3 Status: Not Fixed Severity : High
Discovered: 24 November 2014
Description : VLC Player contains a flaw that is triggered as user-supplied input is not properly sanitized when handling a specially crafted m2v file. This may allow a context-dependent attacker to corrupt memory and cause a denial of service or potentially execute arbitrary code.
attachment 1: windbglog.txt
Activity
Added attachment:
You can find here : https://www.dropbox.com/s/fuobsqy1pwvkyex/poc.rar?dl=0 Pass: Qwertz
added Status::not VLC label
I Tested the samples for ticket 13389 and 13390 under valgrind + FFmpeg with libavcodec from all FFmpeg release branches, from 0.5 to 2.5. None showed a crash or relevant issue. Testing vlc 2.1.5 i was able to reproduce a assertion failue
vlc: misc/picture_pool.c:195: picture_pool_Delete: Assertionvlc_atomic_get(&picture->gc.refcount) == 0' failed.vlc 2.2.0-pre1 did not show any failure, in no case could i reproduce a crash. Looking into what causes the assertion failure, it appears that vlc callsThreadReinit() -> ThreadStop() -> vout_EndWrapper() -> picture_pool_Delete()` which then fails with one of the picture->gc.refcount being 1. At the same time there still is a buffer in use by libavcodec and the codec has not been closed, that is avcodec_close() is never called Iam not a vlc developer and thus do not really know the vlc code but this looks more like an issue in vlc than libavcodec. Note that of course i do not know if the assertion failure and the reported crash are related. But that was everything i could find after searching for several hours. If someone belives there is an issue in libavcodec, then i do need more information/details about where the issue is.
Replying to [comment:11 michaelni]:
I Tested the samples for ticket 13389 and 13390 under valgrind + FFmpeg with libavcodec from all FFmpeg release branches, from 0.5 to 2.5. None showed a crash or relevant issue. Testing vlc 2.1.5 i was able to reproduce a assertion failue
vlc: misc/picture_pool.c:195: picture_pool_Delete: Assertionvlc_atomic_get(&picture->gc.refcount) == 0' failed.`Assert is the right thing to do, and is therefore not exploitable.
Replying to [comment:12 jb]:
Replying to [comment:11 michaelni]:
I Tested the samples for ticket 13389 and 13390 under valgrind + FFmpeg with libavcodec from all FFmpeg release branches, from 0.5 to 2.5. None showed a crash or relevant issue. Testing vlc 2.1.5 i was able to reproduce a assertion failue
vlc: misc/picture_pool.c:195: picture_pool_Delete: Assertionvlc_atomic_get(&picture->gc.refcount) == 0' failed.`Assert is the right thing to do, and is therefore not exploitable.
How do you conclude that it is not exploitable?
As Michaelni says that there was an unclosed buffer in use when the crash happened. Also as it can be seen in the crash logs (https://trac.videolan.org/vlc/attachment/ticket/13390/windbglog.txt), it seems that crash is write access violation and not near null.
I can provide a demo video about the crash and logs. Can you provide any technical info regarding that it is not exploitable?
-
Replying to [comment:13 Veysel]:
Replying to [comment:12 jb]:
Replying to [comment:11 michaelni]:
I Tested the samples for ticket 13389 and 13390 under valgrind + FFmpeg with libavcodec from all FFmpeg release branches, from 0.5 to 2.5. None showed a crash or relevant issue. Testing vlc 2.1.5 i was able to reproduce a assertion failue
vlc: misc/picture_pool.c:195: picture_pool_Delete: Assertionvlc_atomic_get(&picture->gc.refcount) == 0' failed.`Assert is the right thing to do, and is therefore not exploitable.
How do you conclude that it is not exploitable?
Because an assert stops the execution of the program.
Can you provide any technical info regarding that it is not exploitable?
Can you give the technical info that it is?
Why do you refuse to:
- report security issues in the correct way (aka not a public tracker)
- answer the emails we've sent you
- provide a full exploitable backtrace
- test the latest nightly builds and release candidates, as asked
- assign the CVE to the correct library (if any)
- give a way to reproduce your claim
Not to mention sending to seclists or to press.
And yes, so far, noone was able to reproduce your crash or claim.
Replying to [comment:14 jb]:
Replying to [comment:13 Veysel]:
Replying to [comment:12 jb]:
Replying to [comment:11 michaelni]:
I Tested the samples for ticket 13389 and 13390 under valgrind + FFmpeg with libavcodec from all FFmpeg release branches, from 0.5 to 2.5. None showed a crash or relevant issue. Testing vlc 2.1.5 i was able to reproduce a assertion failue
vlc: misc/picture_pool.c:195: picture_pool_Delete: Assertionvlc_atomic_get(&picture->gc.refcount) == 0' failed.`Assert is the right thing to do, and is therefore not exploitable.
How do you conclude that it is not exploitable?
Because an assert stops the execution of the program.
From security point of view, stopping the execution doesn't mean it can not be exploitable.
Can you provide any technical info regarding that it is not exploitable?
Can you give the technical info that it is?
Popular !exploitable script executed inside windbg clearly shows that it is highly probable.
Why do you refuse to:
- report security issues in the correct way (aka not a public tracker)
- answer the emails we've sent you
- provide a full exploitable backtrace
- test the latest nightly builds and release candidates, as asked
- assign the CVE to the correct library (if any)
- give a way to reproduce your claim
I was kind enough to publish the security issue here about one month ago, but got no decent response till it gets public attention. Btw, I didn't get any email from you. Also, in your bug reporting policy I don't see any other place or person to submit a bug report. (https://wiki.videolan.org/Report_bugs)
Not to mention sending to seclists or to press.
I chose to disclose the it because no further comment has been made from your side. Press got it from there, not from me.
And yes, so far, noone was able to reproduce your crash or claim.
Michealni was able to reproduce the failure in vlc 2.1.5, isn't it obvious in his post?
First you were saying it is not a VLC bug but you have come to a point where you accept that it is VLC but not exploitable.
-
Replying to [comment:15 Veysel]:
Because an assert stops the execution of the program.
From security point of view, stopping the execution doesn't mean it can not be exploitable.
I think you fail to understand what assert is. It aborts the program directly, so cannot go to the next step.
Can you give the technical info that it is?
Popular !exploitable script executed inside windbg clearly shows that it is highly probable.
Probable does not mean exploitable.
Why do you refuse to:
- report security issues in the correct way (aka not a public tracker)
- answer the emails we've sent you
- provide a full exploitable backtrace
- test the latest nightly builds and release candidates, as asked
- assign the CVE to the correct library (if any)
- give a way to reproduce your claim
I was kind enough to publish the security issue here about one month ago, but got no decent response till it gets public attention. Btw, I didn't get any email from you. Also, in your bug reporting policy I don't see any other place or person to submit a bug report. (https://wiki.videolan.org/Report_bugs)
Every other security researcher reports it privately, except you.
Not to mention sending to seclists or to press.
I chose to disclose the it because no further comment has been made from your side. Press got it from there, not from me.
Without exploit. Without reproducibility.
And yes, so far, noone was able to reproduce your crash or claim.
Michealni was able to reproduce the failure in vlc 2.1.5, isn't it obvious in his post?
No, he claims he can get an assert, which is an abort, and is CLEARLY not the backtrace you potentially shown.
First you were saying it is not a VLC bug but you have come to a point where you accept that it is VLC but not exploitable.
No, I don't see where the VLC bug is.
Noone else makes it crash, and you refuse to share your details.
It could even be your video drivers.
WinDBG dump on Windows 7 x64 VLC 2.1.5
Added attachment:
Original author: gregory gascon
