vulnerability in ffmpeg and libav

[hubi73]

For those who didn't know yet, there is a serious vulnerability in ffmpeg and libav.

http://www.csoonline.com/article/2375206/data-protection/twenty-year-old-vulnerability-in-lzo-finally-patched.html

regards hubi73

[Groucho2004]

How does a integer overflow bug in a compression library present a security risk?
Sounds like BS to me.

[hubi73]

@ Groucho2004

You must read the article completely.

quote: Furthermore, all users of FFmpeg, Libav, and projects that depend on them "should consider themselves at risk to remote code execution," Bailey adds.

[LoRd_MuldeR]

How does a integer overflow bug in a compression library present a security risk?

Just to give one example: If the overflow happens in some variable holding a memory address (pointer) and the program is going to write some data (e.g. the decompressed data) to that address subsequently, then the overflow could result in writing the data to some memory region where it never was supposed to go! Now, the attacker might be able to construct a "malicious" compressed stream that, during decompression, triggers the overflow and, eventually, writes the decompressed data into the memory region that is holding the executable code. At this point, injecting your own "malware" code into the program is straight forward. Again, this is only one example...

Now the question is: How does this effect FFmpeg and libavcodec in particular? What audio or video formats make use of the LZO compression? Currently I'm more concerned about, e.g., the use of LZO inside the Linux kernel ;)

[Groucho2004]

Just to give one example: If the overflow happens in some variable holding a memory address (pointer) and the program is going to write some data (e.g. the decompressed data) to that address subsequently, then the overflow could result in writing the data to some memory region where it never was supposed to go! Now, the attacker might be able to construct a "malicious" compressed stream that, during decompression, triggers the overflow and, eventually, writes the decompressed data into the memory region that is holding the executable code. At this point, injecting your own "malware" code into the program is straight forward...

Now the question is: How does this effect FFmpeg and libavcodec in particular? What audio or video formats make use of the LZO compression?
There's a lot of "might" and "could" in your reasoning. I might get struck by lightning 100 times tomorrow.
If I were a hacker, I would seek an easier way to mess around.

BTW, I run XP32, SP3, latest update is from 2010. I don't use AV software, only a manual malware and virus scan every few months just for fun. In 20 years of Internet usage I had one virus problem back in 2001. Restoring my Ghost image solved that problem in 5 minutes. All I have is a properly configured router and firewall.

[LoRd_MuldeR]

There's a lot of "might" and "could" in your reasoning. I might get struck by lightning 100 times tomorrow.
If I were a hacker, I would seek an easier way to mess around.

So your point is that security vulnerabilities shouldn't be fixed, until an exploit is known publicly, or what?

Security vulnerabilities in popular software, such as operating systems or web-browsers or PDF viewers, are discovered almost every day. That's why you need to install all those security updates all the time in order to keep your system secure. What do you think causes all these security vulnerabilities? It always starts with some "simple" programming mistake like an integer overflow or an array out of bounds access. But the effect can be disastrous! And this is certainly not some theoretical thing, it's very real! The time when exploits were written by nerdy "hackers" are long gone. Today the attacks are performed by well-organised groups of gangsters as well as intelligence agencies. The notorious "Hartbleed Bug" is the best example!

[Groucho2004]

So your point is that security vulnerabilities shouldn't be fixed, until an exploit is known publicly, or what?
No, I just object to the over-hyping that causes paranoia.

[LoRd_MuldeR]

No, I just object to the over-hyping that causes paranoia.

Surely, panicking is the wrong thing to do.

But ignoring the vulnerability or playing down the risk, like software developers tend to do with bugs discovered in their own code, is even worse!

As far as (potential) security vulnerabilities are concerned, the order of the day is: Better safe than sorry :sly:

So taking this seriously and fixing it in all affected projects (and there are quite lot), as soon as possible, is the only sensible thing to do...

[nhakobian]

Surely, panicking is the wrong thing to do.


This is so true on many, many levels.

I had a number of non-computer friends/family who came to me wondering if their home computers were going to get hacked because of heartbleed. I tried my best to explain the issue to them (to the best of my understanding; I am not a security expert), but some people misunderstand the definition of "serious" and "critical" when it comes to computer software.

Was it "serious?" Most definitely.

Did it require a "critical" update? Of course!

Should it cause a panic? No. People and companies should take it as something that needs to be solved immediately, and for the most part it seems as if this was done. Should this issue be taken seriously? Of course. Should people make sure they take the updates to their software when it is updated? Yes.

Should someone run around with their arms flailing saying, "We're all going to get hacked!!!" No, but it would definitely be entertaining to watch. Someone should start a new internet meme. :)

[clsid]

This has already been fixed in FFmpeg/libav a few days ago.

[foxyshadis]

This is more of a concern for video-hosting sites, where an attacker can upload a specially crafted file to either DoS or possibly hijack the site. Normally it would only result in a crash, but if the attacker can tune it to even just sometimes put the right data in the right place, it's now a hijack -- that's the theoretical to concrete process most vulnerabilities go through. ffmpeg/libav is a big enough target that someone's likely to take a swing at it.

It's also a concern for home users who download random files; fake torrents with malicious code in them are pretty widespread, and people who like to help others can be deceived. If you only play official releases, the chances are basically zero that you'd be affected by it even if you use ffmpeg for everything.

[huhn]

As this issue only affects 32-bit systems and also can only happen if
you use uncommonly huge buffer sizes where you have to decompress more
than 16 MiB (2^24 bytes) compressed bytes within a single function call,
the practical implications are limited.
http://www.oberhumer.com/opensource/lzo/lzonews.php

if this is true. there is no need to panic at all. there are a lot of "if" to run in it.

[therube]

This has already been fixed in FFmpeg/libav a few days ago.
Thanks for stating that :-).