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.
Thank you for being a friend
Traveled down the road and back again
Your heart is true, you're a pal and a cosmonaut.
And if you threw a party
Invited everyone you knew
You would see the biggest gift would be from me
And the card attached would say, thank you for being a friend.
I'm a faggot. Suck my dic Orson Scott Card!!!
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!”
This attitude towards security is why my clients are removing Linux so quickly their computers are literally exploding. Can you blame them? Who'd you trust? A bunch of amateurs working out of their bedrooms? A CORPORATION with shareholders and a fountain in their lobby? No contest!
No, Linus. This is the end. By the end of the week all of my clients will have switched to reliable Windows 8, with Norton and no further need for security. Good job buddy! That's 3 fewer installs of Linux. Fix VLC and then we'll talk. While the rest of you sit late in the office patching your systems, I'll be at home browsing some vore, with my free hand giving myself a well earned pat on the back.
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*
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.
Last year, right up into THIS year: FINALLY cleared! Myself, Mr. Steven Burn (hpHosts/malwarebytes), & Mr. Henry Hertz Hobbit (securemecca.org/hostsfile.net) went thru "false positives" findings by:
---
1.) McAfee
2.) Norton/Symantec
3.) Comodo
4.) Trend
5.) ArcaVir/ArcaBit
---
In the end?
* I had to prove them wrong, & did: EACH OF THEM REMOVED MY APP from their lists of "malware" per JOTTI online virus test etc./et al!
However: All that held back the release of this app:
---
APK Hosts File Engine 9.0++ 32/64-bit:
http://start64.com/index.php?option=com_content&view=article&id=5851:apk-hosts-file-engine-64bit-version&catid=26:64bit-security-software&Itemid=74
---
By a good 2-3 months in 2012 in fact! Pissed me off, because I KNEW I wrote good, solid, & NO VIRUS code in it! In the end?? Guess who came up RIGHT ("yours truly").
It also created some "mistrust" of me on the part of those gents above (part of the security community - their job IS to be 'paranoid' of apps, rightfully so, considering they & their sites are OFTEN attacked online (DDoS & such)). I had to earn it back & did - they looked into it, and it was EXACTLY what I told them it would be (enumerated next below):
E.G.-> 1st - They didn't understand a 64-bit executable compressor technique I used!
2nd - They called anything distributed in a WinRar SFX a "virus"... WTF!
I.E.-> Some of their STUPID "rules" are just that - stupid!
(My app's small enough & is a "portable app", that all it NEEDS is a WinRar SFX to distribute it (keeps size of distro down too, much tinier than installer programs create)).
APK
P.S.=> Guys, trust me (from someone that's been here before):
These guys @ these AntiVirus companies? Most are pretty good, know how to trace & kernel level debug disassemble for the truth of things - however, their "heuristics" go way overboard @ times in their programs! Unfortunately, they're not always right... case in point, above (and below too)...
... apk
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.
Ask Mr. Nir Sofer of NIRSOFT (writes tons of good small utilities for tons of purposes) - in fact, he & I had long discussions about this a few times via email. I really felt for him too, as I have BEEN there myself also.
or
Even Dr.Mark Russinovich of SysInternals/Microsoft fame, this question:
---
QUESTION: How many times THEY TOO have been thru what myself (and now VLC apparently) have in "false positives"...
---
This kind of crap? Happens... a LOT!
(Too much).
* HOWEVER/In the end: I wish VLC well though & GOOD LUCK (they'll get thru it, they're good coders, takes 1 to know one, lol)!
(They have a NICE program, really, really nice! Fact is - it's so nice, that I can't decide which I like better: VLC 64 bit or Media Player Classic 64-bit...)
APK
P.S.=> As to the gents I noted in my 1st reply? Hey:
Please, by all means - Feel free to write them also, to verify my statements earlier in my original post reply (Mr. Steven Burn of hpHosts/malwarebytes -> services@it-mate.co.uk ) or (Mr. Henry Hertz Hobbit of securemecca.org -> hhhobbit@securemecca.org ) - they WILL freely verify anything I said as truth, I am sure of it!
... apk
Per my original post -> http://it.slashdot.org/comments.pl?sid=3958509&cid=44241949 since I have been in VERY similar circumstances - I first point you to that!
(& what's there in that link for me? NOT a "1st" either - had it happen YEARS BEFORE in 2004, & CA never even notified me of it - I had to stumble upon it myself, and in the end? They 'downgraded' the "threat" in THAT app to ZERO... I passed all 21 of their removal questions too - should have been TOTALLY removed, but wasn't - these companies play a LOT of "dirty pool" just to show "we catch more" when in fact? They do not and offer FALSE POSITIVES as truth!).
Anyhow/anways (back on track on 3rd party lib use):
1 gent, Mr. Steven Burn (malwarebytes' hpHosts) - who helped me out TONS, in that situation in that link I posted above, asked me once:
"Why don't you just use SQLite?"
(Since a SELECT DISTINCT query does deduplication & sort easily enough)
My answer? "I like to be able to say 'I built this, myself, by hand, & it give me superior control over bugs..."
( & also since if ANY 'holes' show up in SQLite, guess who else "bites it" then?? Me.)
Besides: Dedups & Sorts are fairly simple to do (lol, except "HeapSort" imo), & even native tools like StringLists have this built into their Object methods AND can take added "custom sorts" as well if needed (so why bother use external libs?) - sometimes, they are - some are faster (DataStructures class anyone?) on sorted vs. unsorted sets, large vs. small sets, etc./et al!
* NO THANK YOU - AVOID 3rd party libs, IF/WHEN POSSIBLE: &, mainly because of what you're seeing here (and other things noted).
(I like to write single 'stand-alone' executables when & IF possible, minus calls to ANY libs outside of what the OS itself supplies in its API's, for that very reason alone as well as performance & to have a "single container" with no "extra moving parts" too!)
APK
P.S.=> Imo & experience (been coding since 1982, & professionally since late 1993) - You're truly/honestly FAR BETTER OFF taking the extra time to learn how to do things, yourself, in your OWN CODE! Almost every time, because of the above (& what you yourself note, as well as the article). You also have a LOT MORE CONTROL that way too, as far as fixes if they're required... apk
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...
FTFY
Cwm, fjord-bank glyphs vext quiz
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?