I will not comment much about the methods of this company or the fears they try to push onto their users. They are using the same tactics of other companies of this
security business. I will therefore go straight to the point.
A crashing PoC against VLC 2.0.4 was sent on the full disclosure mailing list on the December 7th.
You can get the POC here.
Note that this is a crash for swf, a format that VLC was officially able to open (no extensions assignation, not present in the open dialog,...) and one cannot open it automatically or by mistake.
You can see the stacktrace on our bugtracker.
The crash is in libavformat/libavcodec libraries, from the FFmpeg/libav projects. Not at all in VLC.
FFmpeg/libav are used by thousands of projects, including your TV, your smartphone, your DVD player and quite likely your browser. The list of projects includes Chrome, all Smart TVs from Samsung and LG, all media players codecs packs, all media players on Linux, most video editors, every video converter, most DVD players that play DivX or MKV files, etc... The normal thing to do is to report those kind of issues upstream, of course. This is what responsible security researchers do, because the issues are then fixed in all software... But that does not include Secunia.
I provided a fix that you can see here on December 11th.
As you see, this IS NOT the same fix that Secunia shows on their blog and claim we used: FFmpeg patch.
This is the of Secunia: they don't even look at our codebase, while we are open source!
Then, Secunia does its advisory on the December 12th : ie AFTER. And calls it unpatched, while a patch is ready and public, as you could see above. This is the of Secunia: they don't even check their advisories.
I did the release on the 14th December of VLC 2.0.5. 7 days after the full-disclosure POC. That's quite nice for a hobbyists project, no?
You can download the VLC 2.0.5 for Windows here.
Try it yourself! You have the POC, you have the VLC release 2.0.5. It does not crash at all. I just retested on Windows 8.
But they refused to close their advisory:
When the VLC team released version 2.0.5, which claimed to fix SA51464, Secunia Research contacted the VLC security team and informed them about the incorrect patch. However, VLC apparently disregarded our mail.
This is the of Secunia: the PoC was not crashing at all.
Moreover, I have no idea what mail they are speaking about: I have received no mail from Secunia in December, January or February.
That means the next 3 months after their advisory was out, and they did not change anything in it, nor tried to communicate, while we tried, people in their comments and forum did, repeatedly. Who is failing at
doing coordination between vendors and researchers ?
The mail from Secunia in March that they quoted even mentions: "Following my line of argument I hold the view that SA51464 has to be seen as fixed with VLC 2.0.5."
Then, they said, again, in their blogpost:
However, they failed to understand the root cause and provided a patch which did not fix the core issue.
This is, once again, wrong: we saw the crash they gave us and we fixed it.
Seriously, try it yourself with VLC 2.0.5.
You will see that this is fixed in all those versions.
The next day we re-visited the issue, ... in version 2.0.6. However, since we could not prove exploitation, we decided to change the status to “Patched”. ...concluded that the issue is exploitable even in the newly released version 2.0.7.
This is the of Secunia. No regression post 2.0.5 on this particular file.
I have no idea what they mean. The thing seems to be so confused on their side that they already changed 3 times the status of this advisory.
After that, I decided that I could not do much against Secunia, except being very annoyed by all this situation.
Secunia and MKV: SA52956
Then comes more WTF from Secunia.
Someone came to Secunia with a supposedly PoC on MKV. This PoC crashes VLC, indeed, but does nothing more.
We thought that the issue was an
uncaught exception in C++ in the MKV demuxer. We asked for some times, to fix the issue.
We did a fix and committed the issue here on April 27th. Only 4 days after. We told Secunia about this fix.
As you can see, this is not an integer overflow error, but an uncaught exception and I doubt that it is exploitable. This uncaught exception makes VLC abort, not execute random code, on my Linux 64bits machine.
This was told to Secunia on several occasions, including on the phone. They never came with a more complete explanation, nor with an actual exploit and refused to tell us more.
EDIT: Vupen seems to say this is exploitable with some "voodoo" code. I don't have more details about that.
Yet to me, Secunia does not even stand by what they claim is their core business, aka "putting vendors and researcher in contact" and refuses to discuss technical points. They just say: "no this is not good", and then defame us...
Secunia attacking VideoLAN on Twitter
Then, on May 22nd, Secunia started lying and misguiding our users as you can see on Twitter, while VLC did not appear on the US report... Selling their reports on accusations of not patching securities issues in VLC... When we mentioned the mistake, they did acknowledge but they did not even apologize.
As you can imagine, we were quite pissed against Secunia....
This is exactly what I call defamation.
EDIT: But, you know what, they re-edited their report on May 29th to make VLC show on the US report... Look at the date on the right-end corner, it is not the 22nd... Why else would they say "You are right"?
What kind of security company edits their reports afterwards to change the results? If they knew that they were clean, why doing that?
MKV issue fixed
At end of May, we were contacted again about the MKV situation, and we said that this was a crash, not an exploitable security issue.
We gave them the revision of the patch in which VLC had the crash fixed, and a proper build, but they kept saying it was "unpatched", without explaining anything...
They decided to publish their advisory, while a version fixing VLC was published (we publish nightly builds every night), a very simple workaround for VLC 2.0.7 existed (remove the libmkv_plugin.dll) and with a PoC that was crashing VLC but not exploiting it.
Moreover, they refused to hold the advisory until VLC 2.1.0 was out, and published it anyway.
You can try a VLC build in which it is fixed...
Final insults and attack
Finally, today they blog about us saying:
That VLC apparently doesn’t think vulnerabilities in third party libraries, for example FFmpeg (which is statically linked), are issues they would need to warn their users about, but only vulnerabilities in the “main” VLC code, is obviously not the right thing to do, and gives a false image on the security status of VLC.
And we don't statically link on all platforms. Moreover, why not sending the issue to FFmpeg?
There is a lot of code in VLC, and they are probably a lot of security issues in VLC, noone is denying that, but the way Secunia deals with this was outrageous and I think I have all the rights to be pissed and claim that they do not work "with vendors". It might be easier to attack a group of hobbyists than big companies.