Opened 6 years ago
Closed 6 years ago
#13390 closed defect (notvlc)
VLC Player 2.1.5 Write Access Violation Vulnerability
| Reported by: | Veysel | Owned by: | |
|---|---|---|---|
| Priority: | high | Milestone: | 2.2.0 |
| Component: | Unknown | Version: | master git |
| Severity: | major | Keywords: | |
| Cc: | vhatas@…, cehoyos, michaelni | Difficulty: | unknown |
| Platform(s): | Windows desktop | Work status: | Not started |
Description
Title : VLC Player 2.1.5 Write Access Violation Vulnerability Discoverer: Veysel HATAS (vhatas@…) 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
Attachments (4)
Change History (34)
Changed 6 years ago by
| Attachment: | windbglog.txt added |
|---|
comment:1 Changed 6 years ago by
| Cc: | cehoyos added |
|---|
comment:2 Changed 6 years ago by
You can find here : https://www.dropbox.com/s/fuobsqy1pwvkyex/poc.rar?dl=0 Pass: Qwertz
comment:3 Changed 6 years ago by
comment:7 Changed 6 years ago by
It is still doubtful that this is VLC vulnerability, and not libav one.
comment:8 Changed 6 years ago by
| Resolution: | → notvlc |
|---|---|
| Status: | new → closed |
So, this is NOT a VLC bug, but a libavcodec one.
Assigning a CVE to VLC is just wrong.
Moreover, the 2.2.0-rc2 binaries already fix the problem.
comment:10 Changed 6 years ago by
| Cc: | michaelni added |
|---|
comment:11 follow-up: 12 Changed 6 years ago by
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: Assertion `vlc_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
calls ThreadReinit() -> 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.
comment:12 follow-up: 13 Changed 6 years ago by
Replying to 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: Assertion `vlc_atomic_get(&picture->gc.refcount) == 0' failed.
Assert is the right thing to do, and is therefore not exploitable.
comment:13 follow-up: 14 Changed 6 years ago by
Replying to jb:
Replying to 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: Assertion `vlc_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?
comment:14 follow-up: 15 Changed 6 years ago by
Replying to Veysel:
Replying to jb:
Replying to 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: Assertion `vlc_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.
comment:15 follow-up: 16 Changed 6 years ago by
Replying to jb:
Replying to Veysel:
Replying to jb:
Replying to 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: Assertion `vlc_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.
comment:16 Changed 6 years ago by
Replying to 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.
Changed 6 years ago by
| Attachment: | vlc-2.1.5-dump-trac13390.TXT added |
|---|
WinDBG dump on Windows 7 x64 VLC 2.1.5
comment:18 Changed 6 years ago by
For further technical details refer to
VLC Player 2.1.5 Write Access Violation (CVE-2014-9598) MITRE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=2014-9598 NIST: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9598
VLC Player 2.1.5 DEP Access Violation (CVE-2014-9597) MITRE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=2014-9597 NIST: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9597
comment:19 Changed 6 years ago by
This is not further technical details, this is the same.
And once again, this is still not a full backtrace.
Not to mention if the issue is in libavcodec or VLC or the video driver.
Changed 6 years ago by
| Attachment: | vlc-2.1.5-13390.dmp added |
|---|
WinDBG minidump - Write Access Violation
comment:20 follow-up: 23 Changed 6 years ago by
Veysel,
In picture_t structure, you have :
/** Private data - the video output plugin might want to put stuff here to * keep track of the picture */ picture_sys_t * p_sys; /** This way the picture_Release can be overloaded */ struct { vlc_atomic_t refcount; void (*pf_destroy)( picture_t * ); picture_gc_sys_t *p_sys; } gc;
And in 2.1.5 picture.c>picture_Release(picture_t * picture)
if( vlc_atomic_dec( &p_picture->gc.refcount ) == 0 && p_picture->gc.pf_destroy ) p_picture->gc.pf_destroy( p_picture );
Pointer p_sys can permit to another video output plugin (libavcodec ??) to perform a buffer overflow and overwrite pf_destroy... So it's NOT a VLC security issue
comment:21 Changed 6 years ago by
| Resolution: | notvlc |
|---|---|
| Status: | closed → reopened |
comment:22 follow-up: 25 Changed 6 years ago by
directsound audio output error: cannot initialize DirectSound main audio output error: module not functional main decoder error: failed to create audio output
This is not even a working version of Windows XP.
comment:23 follow-up: 26 Changed 6 years ago by
Replying to gregory gascon:
Pointer p_sys can permit to another video output plugin (libavcodec ??) to perform a buffer overflow and overwrite pf_destroy... So it's NOT a VLC security issue
p_sys is internal to one plugin.
comment:25 follow-up: 28 Changed 6 years ago by
Replying to jb:
directsound audio output error: cannot initialize DirectSound main audio output error: module not functional main decoder error: failed to create audio outputThis is not even a working version of Windows XP.
The windbgxpsp3.TXT attachment on Windows XP SP3
comment:26 Changed 6 years ago by
Replying to jb:
Replying to gregory gascon:
Pointer p_sys can permit to another video output plugin (libavcodec ??) to perform a buffer overflow and overwrite pf_destroy... So it's NOT a VLC security issue
p_sys is internal to one plugin.
Yes yes that's what I've understood. Unfortunately I don't have yet the chance to compile it in debug to exactly analyze this overflow. And yes you are right, this ticket should be closed because this bug does not exist in master branch, with some protection in the picture_Release function.
comment:27 follow-up: 29 Changed 6 years ago by
If you want to close this ticket please update vlc player version from 2.1.5 to 2.2.0 in this page http://www.videolan.org/vlc/ and http://www.videolan.org/vlc/download-windows.html.
Because almost every Windows user download vlc those pages.
comment:28 Changed 6 years ago by
Replying to Veysel:
Replying to jb:
directsound audio output error: cannot initialize DirectSound main audio output error: module not functional main decoder error: failed to create audio outputThis is not even a working version of Windows XP.
The windbgxpsp3.TXT attachment on Windows XP SP3
You don't have directsound and you claim it's a full XP installation?
I doubt it.
comment:29 Changed 6 years ago by
Replying to Veysel:
If you want to close this ticket please update vlc player version from 2.1.5 to 2.2.0 in this page http://www.videolan.org/vlc/ and http://www.videolan.org/vlc/download-windows.html.
Because almost every Windows user download vlc those pages.
In software development, tickets are closed when the issues are fixed in the repository, not in production releases. Hence you can know when to release your binary... when no major feature or bug ticket is still opened...
comment:30 Changed 6 years ago by
| Milestone: | Bugs paradize → 2.2.0 |
|---|---|
| Resolution: | → notvlc |
| Status: | reopened → closed |
So, in the end, all this fuss was about a crash in YOUR Virtualbox video driver, on a non-maintained version of Windows. And you claim the issue was VLC.
Not to mention failing to report the proper way...
Where can I find the media file that causes the crash?