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.
despite dire warnings from Secunia that it could be exploitable, it most certainly is not.
", said so-and-so.
See how that is done?
C'mon Secunia, security isn't about bickering. You don't just throw proof-of-concept at someone and say "FIX IT FIX IT FIX IT" without buying them dinner first.
What kind of things are exploitable. If the above involves a SEH chain to be invoked on windows it can be exploited.
despite dire warnings from Secunia that it could be exploitable, it most certainly is not.
That depends entirely on what "exploit" means. If VLC is a core part of a media service, calling anything named "terminate" sounds like a recipe for a simple DoS. I don't think VLC is overpriced enough to serve in any critical roles (like, perhaps, a giant Times Square display), but it could easily be the magic under a layer of consultants' bills.
The easy assumption is that any time a program does something that wouldn't be expected, it's exploitable to cause some kind of annoyance. Whether that alone is enough to warrant a fix is a different matter.
You do not have a moral or legal right to do absolutely anything you want.
when I need to call std::terminate.
Silence is a state of mime.
"Kaveh Ghaemmaghami has discovered a vulnerability in VLC Media Player, which can be exploited by malicious people to potentially compromise a user's system."
"The vulnerability is caused due to a use-after-free error when releasing a picture object during decoding of video files. This can be exploited to reference an object's callback function pointer from already freed memory. Successful exploitation may allow execution of arbitrary code."
Well if it can be exploited to execute arbitrary code, why not exploit it to execute arbitrary code? Or shut up and stop talking garbage ("to reference an object's callback function pointer" What?? Is that supposed to sound technical while being gibberish?).
Put up or shut up and the argument becomes more regular and concrete like most exploits.
i.e. proof of concept, the thing that seems to be missing from Secunia's claim.
The so-called 'security' firms have just been building a business model around some accidents of history - buffer overflow, sql injections, etc...
When all of these go away, slowly but surely, computer intrusion as we know it will cease to exist and 'hacking into computers' will be a thing of the past.
I have read this quite concerned but am now finally relieved that my porn viewing will not be affected in the slightest.
Thank you for reporting on "stuff the matters".
A 'singular oddity' is an event that cannot be explained and only happens when you are alone.
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.
Threatens 'legal action'? What's up with that?
“He’s not deformed, he’s just drunk!”
Pretty weak troll. I'll give you 2,5 out of 5, if nothing else for your copy/pasta effort. Otherwise you'd probably get a 1.
They have always been correct.
(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*
He even brought out the cheese for the pasta when he mentioned Windows 8, you need to give him at least 3 out of 5. I almost fed him myself...
uhm...
my clients are removing Linux so quickly their computers are literally exploding
Sounds like a good reason not to remove Linux.
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.
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.
What if the library is statically linked (as it is on some platforms with VLC as I understand it)? Then it is distributed with the product.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
I've seen tagged "critical security" "buffer overflow bugs" for unchecked bounds strings... only exploitable being root...
My understanding is the libmkv terminate was the DoS portion. The SWF use-after-free would indeed be vulnerable, but is also within ffmpeg. While it would be nice - and in their best interests - if VLC fixed it upstream, it should have been reported as an ffmpeg issue imo.
For the last time, PIN Number and ATM Machine are redundancies!
Borland's Object Model in Delphi (& C++ Builder too) let you do that via "VCL's" (visual component libs) that compile right into your app - it['s much like doing classes work in say, VB or C++ from MS (& it has forms built right in if required etc.). By the way: YES, that is "VCL" not our subject program, "VLC" (stressing that here, right off the bat almost).
It's great when they ship with source - easier to control by far of course. Not as nice if they don't (some don't). Usually I've seen that MOST 3rd party folks, in freeware libs, ship with source though. Thank Goodness. I steer clear of them now, usually, if the time to take building the functionality of the lib isn't too extreme, then I build it/mimic it, myself. Just a matter of trade off time constraints. I am "big" personally, on "self-built code" for reasons of maintenance etc. (what happens if say, you go from 32-> 64-bit & can't port others' 3rd party libs too? You're stuck!) - it was what my 1st post here was about, in fact.
You're, odds are, going to HAVE to distribute any .DLL files too, since you noted distributed with product, though. If the OS doesn't have a native model of the same, with the SAME build/version # on it - you're in for hassles (placing YOURS in your appdir overrides those, & gets you around this, since 1st place in dll calling rules is the application's folder before any place else, like %WinDir%\system32)
APK
P.S.=> In my last reply however, I should have specified that regarding your point - that DLL-based API's were what I meant by "3rd party libs", specifically (vs. statically linked VCL's and yes, it is CLOSE to our subject spelling-wise, so nobody get too confused now, in VLC)... apk
Then who you are going to call?
So, the solution is simple. Fix the bug. Own the problem, take responsibility for it. After the bug is fix if someone wants to claim it isn't, offer $1,000,000 if they can tank you. If they collect, you were wrong. If they can't, they were wrong. It _is_ that simple.
I really hope you're trolling, because "for all intensive purposes" is a corruption of the phrase "for all intents and purposes". Using the "intensive" version is usually a sign that you're a dumbass.
(Only usually, though. Unlike many cases of mangled phrases, there are contexts where "intensive purposes" might actually make sense. In this one, however, "for all intents and purposes" is clearly correct.)
VLC distributes a single installer with a lot of things in it on, eg. windows, where on a linux system most of the parts would all be separate packages (fetched from source and compiled by your linux distribution and not by videolan), but the individual libraries are dynamically loaded as needed.
Statically linked would mean one rather large binary, and that's not how vlc works on any platform. It's a core engine with lots and lots of plugins, relying heavily on dynamic loading. So the terminology as used does not apply.
Bottom line, VLC does come with third party software libraries packed in its installer on platforms where it provides such a thing (windows, mac), but does not on others, that rely on source distribution.
Even so, the situation remains that if there is a problem in, say, ffmpeg, then pointing at vlc as the culprit is misleading, even dishonest, in badly counter-productive ways:
First, though vlc would be affected, they would kick over the problem to ffmpeg tout de suite. At most they'd patch it themselves, submit the patch to ffmpeg, and awaiting upstream upgrades patch the version of ffmpeg in the build tree -- but that only works for platforms for which they provide monolithic installers. Source distribution would be left out in the cold. Might as well work with ffmpeg directly to get the thing fixed, instead of getting into a shouting match with videolan.
Working with the group most directly responsible for the software that contains the problem is usance and best practice in the open source community. This is a bit different from the commercial stonewalling secunia is apparently used to.
Second, ffmpeg (and much of whatever else vlc uses) is used quite a lot more widely than just vlc, and so if you blame vlc then you're not just frustrating fixing the actual problem, you're leaving all those other users out in the cold, too.
Rarely understood, often vilified. Satire is the most dangerous form of literature.
It was a silly joke about the corruption of language, how the vernacular becomes the standard and the frequent error of those who jump on others supposed mistake.
Y'all get a nice big WOOOOSH!
Cwm, fjord-bank glyphs vext quiz
Spend manpower on fancy Metroized version, or ironing the real deal?