Exploitation tactics for heap over-reading?

Question

One of recent CVEs particularly 2019-13615 related to VLC media player, attracted my attention because of the developer reaction:

Any non-exploitable read overflow get CVSS of 9.8, like VLC is a server and you could do RCE and compromised the machine, while most of the time, the issue is a crash, often not exploitable, from a local file that the user HAS to open manually

My interest was never so high. As I understand the vulnerability and commit with the fix, I see it cannot actually be exploited for RCE.

Am I right?

Then why researchers in two (three?) unrelated organizations issued a CVE and assigned a CVSS score that is so high? I wonder, why other researchers have said that it cannot be exploited for an RCE on macOS.

Answer 1

The reason why CVSS scores are high, even though an issue is difficult to exploit, is because CVSS ignores the likelihood of some things.

For example, if an exploit requires the user to open a media file, it gets the attribute "User interaction required". An exploit that would require the user to ignore an explicit warning also gets the attribute "User interaction required".

Both of them are, however, not of the same likelihood. The likelihood that a user will attempt to open a media file with a media player is quite high. And several users will download media files from untrusted sources, giving the attack quite a large surface.

As far as exploitability goes, this requires some actual testing. Not every vulnerability is exploitable, but should still be fixed.

Answer 2

There are two distinct questions here:

1. How easy is it to trigger the vulnerability? In other words, how easy is it to make the program do something it isn't supposed to do?
2. How severe is the vulnerability? In other words, if you can trigger it, what can you do with it?

The answer to the first question is: very easy. VLC is a video player, and you can trigger the vulnerability with a video file. Just how hard is it to convince someone to watch a video? “Hey, look at these kittens!” And actually that's the hard way: the easy way is to embed the video in a web page. For a few dollars, buy some ad space, and the videos will play on websites such as Stack Exchange). VLC is available as a browser plugin (although only on older browsers, I think), so anyone whose browser is configured to play videos through VLC and whose version of VLC is vulnerable would be affected, even if they don't do anything to play the video.

Given that all it takes to trigger the vulnerability is to trigger a web page, exploitation is as easy as it gets. The reaction from the VLC developer on this aspect demonstrates a scary lack of understanding. (Their reaction on other topics, such as the fact that the vulnerability turned out not to be in VLC, is more understandable.)

The second question is how bad it can be if the vulnerability is triggered. I haven't analyzed the code, but it's a buffer overread, so the potential is limited. If I understand correctly, this is code that reads from a video, and that can cause data to be read past the end of the video in memory. The data is supposed to be from the video file, so it could be anything: the software shouldn't be assuming anything about the content anyway, so this can't be a way to inject bad data. The two bad things that can happen are a crash and an information leak.

A crash will happen if the read reaches a memory address that isn't mapped. (I'm assuming an operating system with memory protection; as far as I know, VLC only runs on such operating systems.) This is deterministic behavior: if the read reaches an unmapped address, the program will stop due to a segmentation fault or the Windows equivalent. So this could be a denial of service at most.

What would be more useful for the attacker is if there happens to be confidential data in memory right after the video, and the attacker is able to obtain information about this confidential data. This is possible in principle, but very difficult to achieve in practice. First, there has to be confidential data there in the first place, which would typically not be the case: VLC typically does not load any confidential data. If VLC is embedded as a plugin in some larger software such as a browser and runs in the same process (which as far as I know no browser has done for years), then in principle there could be confidential data. If VLC is displaying the video in a web page, for example, the attacker could run JavaScript to view the screen content. But once again, they wouldn't be seeing any confidential data unless the VLC process has access to such data, which is unlikely.

In conclusion, this particular vulnerability (which by the way isn't in VLC, but in some library that VLC uses) is easy to exploit, but the exploit doesn't have much potential for doing anything bad.