Slashdot Mirror
VLC And Secunia Fighting Over Vulnerability Reports
benjymouse writes "Following a blog post by security company Secunia, VideoLAN (vendor of popular VLC media player) president Jean-Baptiste Kempf accuses Secunia of lying in a blog post titled 'More lies from Secunia.' It seems that Secunia and Jean-Baptiste Kempf have different views on whether a vulnerability has been patched. At one point VLC threatened legal action unless Secunia updated their SA51464 security advisory to show the issue as patched. While Secunia changed the status pending their own investigation, they later reverted to 'unpatched.' Secunia claimed that they had PoC illustrating that the root issue still existed and 3rd party confirmation (an independent security researcher found the same issue and reported it to Secunia)."
There are two bugs: one is a vulnerability in ffmpeg's swf parser that vlc worked around since they don't support swf. The VLC developers think Secunia should have reported the bug to ffmpeg, which seems pretty sensible. The other bug is an uncaught exception in the Matroska demuxer with overly large chunks that merely results in std::terminate being called; the Matroska demux maintainer apologized, but, despite dire warnings from Secunia that it could be exploitable, it most certainly is not.
I tried accessing the VLC website, but all I got was an error message:
Please wait while your font cache is rebuilt. This should take less than a few minutes.
How is that phrase gibberish? It's quite clear what it means if you've ever used C++ and function pointers to implement callbacks for an object.
(original submitter here)
If Secunia is correct that the root cause is a use-after-free vulnerability, it exploitability is likely not limited to simple DOS. Secunia talk about a callback handler. A use after free vulnerability can easily lead to execution of arbitrary code, depending on how much control the artacker can assert over the memory.
Also, it is interesting if the sentiment is that it is not a vulnerability if it sits in a linked library. Should it really be considered a vulnerability of the library and not of the product using the library? For all intents and purposes, it is a vulnerability of the product.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Should it really be considered a vulnerability of the library and not of the product using the library? For all intents and purposes, it is a vulnerability of the product.
Why? We don't report vulnerabilities in the GNU C library (glibc) as being vulnerabilities of every program that has links to it. Even Secunia reports vulnerabilities in glibc as vulnerabilities of the library, not the individual programs using it. [cite: https://secunia.com/advisories/search/]
You can argue that it ought to be the other way, but at the very least Secunia should be consistent with their own practice. Flagging VLC because of a vulnerability in ffmpeg is not consistent with Secunia's own past practice.
You jest, but that's a decent example. It's a hostile world, and every little thing, no matter how trivial, can be used against you, in unexpected ways. If you're aiming to kill a sysadmin, perhaps VLC is just the right tool for the job. Perhaps the bus hit was planned, and the attacker just needed a way to get the admin out in the open.
One of my personal favorite exploits involved using a core dump to drop a file into cron.d. The kernel, being ever so helpful, would put the dump into whatever working directory the crashing program was running in. Cron, being ever so helpful, would run all the files in cron.d, and being ever so helpful, would ignore all the badly-malformed data in those files. Put them together, and suddenly any user who can run a program can schedule commands to be run as root.
As your example shows with ample hyperbole, even a clean termination may be part of a larger plan. Perhaps VLC terminating triggers a watchdog that is differently-exploitable. Perhaps VLC is interfering with another exploit the attacker wants to use. Perhaps something else altogether... what matters is that all such attack vectors can be blocked by fixing this unexpected behavior.
You do not have a moral or legal right to do absolutely anything you want.
If I update the library it resolves the problem for all users of the library. Therefore, the problem is in the shared library, not in the users of that library.
It may be possible to trigger the bug in users of the library, but the actual error (and the thing that must be fixed) is in the library, not the program using it.
Well I'm not a security expert so I can't comment on that, but what I DO have is a shitload of PCs at the shop and I can say that the VLC guy is right, I just tested the Securina "Proof Of Concept" SWF and it don't do shit under VLC. If any Securina fans are here it shows an image, the QT logo, and that's it.
I tried it on 32bit and 64bit win 7 and even the old XP box in the corner and he's right, first of all VLC won't even open it by default, won't show up in either open with nor any right click menus for that format, so you have to fire up VLC and THEN switch away from media files to all files to even see the thing in VLC and as I said when run? Nothing, hell it didn't even make VLC hang or crash.
So I'm sorry Securina but if that is your "proof" I gotta throw a flag, bullshit on the field. I haven't got any real old versions of VLC to check what it does on old versions but since VLC has had an updater in place for a couple of years now I can say that I just don't run into anybody running old versions of VLC in the wild so i don't consider that a test worth running.
ACs don't waste your time replying, your posts are never seen by me.