Stories
Slash Boxes
Comments

SoylentNews is people

VLC: Vulnerability Not Found

posted by martyb on Thursday July 25 2019, @05:52PM   Printer-friendly
from the pics-or-it-didn't-happen dept.

takyon writes:

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.

Original Submission

 
This discussion has been archived. No new comments can be posted.
VLC: Vulnerability Not Found | Log In/Create an Account | Top | 35 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 2) by DannyB on Friday July 26 2019, @03:04PM

    by DannyB (5839) Subscriber Badge on Friday July 26 2019, @03:04PM (#871496) Journal

    Thank you! That is very interesting.

    Java runtime: fewer but larger files.

    NodeJS: many smaller files

    I suspect NodeJS cannot compete with Java on performance.

    The Java runtime runs java bytecode. It starts out interpreted. Continuous dynamic profiling identifies functions using disproportionate cpu. Those are immediately compiled to native code by the C1 compiler, and put on a list to soon be recompiled by the C2 compiler. C1 quickly compiles simple code. C2 spends time generating highly optimized code.

    C2 aggressively inlines code. C2 has a 'global view' of the entire running application unlike an ahead of time compiler, such as C, or Golang, etc.

    If a class is dynamically reloaded during runtime, causing some aggressively inlined code to become stale, then those functions are de-optimized back to being byte code interpreted again. If they still use disproportionate cpu they will get compiled again by C1 then C2.

    I was just reading about Vectorised Byte Operations in C2 [github.io].

    C2 is also able to use instructions specific to your actual processor model. Unlike an ahead of time compiler.

    --
    To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  
    Total Score:   2