Alleged critical VLC flaw is nothing to worry about -- and is nothing to do with VLC
There has been a degree of confusion over the last few days after news spread of a supposed vulnerability in the media player VLC. Despite being labelled by security experts as "critical", VLC's developers, VideoLAN, denied there was a problem at all.
And they were right. While there is a vulnerability, it was in a third-party library, not VLC itself. On top of this, it is nowhere near as severe as first suggested. Oh -- and it was fixed over a year ago. An older version of Ubuntu Linux was to blame for the confusion.
The problem actually exists in a third-party library called libebml, and the issue was addressed some time ago. The upshot is that if you have updated VLC within the last year, there is no risk whatsoever. VLC's developers are understandably upset at the suggestion that their software was insecure.
Also at Tom's Hardware, Boing Boing, and The Register.
(Score: 2) by sshelton76 on Friday July 26 2019, @06:09AM
Yes they are because the deps are compiled in. Look at golang static builds for instance. You can deploy what appears at first glance to be a service without any external dependencies, but then find out you're vulnerable because the day you compiled you roped in some package with a vulnerability some package you brought in, itself depended on something with a vulnerability.
In truth the best solution I've seen is the new NPM vulnerability scanner. It lets you know if your project depends on something vulnerable or if something you depend on depends on something vulnerable and the tool even offers advice on how to fix it.
So just building your services with NPM goes a long ways towards weeding out vulnerabilities since the scan is now enabled by default.
I build a lot of web facing services and used golang for years, but have been finding myself leaning harder into node lately, precisely for the tools.