4 ms·

This is cool. I wonder how many of the bugs led to code execution? If you managed to execute code, what privileges do you have in Chrome? I hope that Chrome

by chubot 13y ago

This is cool. I wonder how many of the bugs led to code execution? If you managed to execute code, what privileges do you have in Chrome? I hope that Chrome was using OS sandboxing for video playing. After all, if they found 1000 bugs, there are probably a few more zero day's available. Does playing Flash video in Chrome/Firefox end up using ffmpeg? I'm not that knowledgeable about how video works, but there are probably at least two execution contexts: playing .mp4 natively in Chrome, or playing it via a Flash container.

nathancahill 13y ago
Playing .mp4's natively uses FFmpeg, but Flash video does not. Both plugins are sandboxed in a "privilege separation" environment that they mention in the post.
jbk 13y ago
> I wonder how many of the bugs led to code execution? Quite a few. We're often affected with VLC, and code execution is easy to get to. But with VLC, you're "only" in userland.
- tptacek 13y ago
  In other words, you're "only" dealing with a bug that would allow anything you downloaded from BitTorrent to own up your personal account on your computer. :) (I know you know that, I'm just spelling it out for people).
  - jbk 13y ago
    Yep, and that's quite dangerous. Especially since you can see often fake videos circulate around, that tell you to download a special software or codec to play them (with malware, of course). WMP also had a scripting/runtime system that could be abused greatly. Be careful what you download :)
- fulafel 13y ago
  Chrome is also in userland - and it has a sandboxing system. Assuming they're sandboxing ffmpeg, these bugs are more risky for VLC users than Chrome users. Plus, Chrome is more diligent with security updates and the auto-update mechanism is fully automatic. A sandboxing system provided by either ffmpeg or VLC would be a very good idea, though it would be some work... encoded data in, decoded frames out via shared memory. Negligible performance impact.
  - chubot 13y ago
    Yeah definitely. Really there is a gross violation of the principle of least privilege here. A video player is a great thing to sandbox because all it needs is a video output, very limited file access, and very limited gui input. It doesn't need to read all your files, open network connections, or start processes. Given that there are apparently thousands of bugs in the video parsing code, it seems like a no-brainer. Section 5.2 in this DJB paper talks about (portable) isolation of plain transformations. Video playing is already close to "pure" or could be made pure pretty easily. http://cr.yp.to/qmail/qmailsec-20071101.pdf http://cr.yp.to/qmail/qmailsec-20071101.pdf
    - jbk 13y ago
      > A video player is a great thing to sandbox because all it needs is a video output, very limited file access, and very limited gui input. It doesn't need to read all your files, open network connections, or start processes. Not sure if serious or sarcasm, to be honest, since this seems very far from what we see. A media player is not simple to sandbox, (as the MacOS X sandbox showed us for example), because: - you need to open files by yourself, without user interaction, to support playlists, - you need to open connections by yourself to support video protocol like RTSP, RTMP, RTP, - you need raw device access to support Webcams, Capture devices, DVDs, DVB tuners, - you need to access GPU buffers for direct rendering, and/or shaders to do fast filtering or just plain chroma-conversions, - you need to be able to access the audio output, at low-level, for libsync which is not always doable with the simplified APIs, - and I don't understand what you mean by "very limited gui input"; how is that less than other programs? Sure, it can be done, with performance costs but it's clearly not a "no-brainer".
- Thaxll 13y ago
  I'm sure some people are running VLC under root, still in userland but can be very dangerous.
  - feepk 13y ago
    This is one of the reasons why you have to use a wrapper for the VLC binary to execute it within a root environment. Said wrapper is usually in an extra package on Linux and not provided on Windows and OS X (it can be compiled manually of course). Like 10 people per year complain about not being able to run VLC as root, but then again, why should you?
  - Crito 13y ago
    I'm sure there are some people using telnet and using "password" as their root password. At a certain point it becomes more than reasonable to say "Well don't do that."
mutagen 13y ago
> I wonder how many of the bugs led to code execution? The linked blog article [1] suggests 10% - 20%: Our personal feeling is that between 10% and 20% of the problems could be considered easily exploitable security issues; however, the estimation has not been formally confirmed in any way. [1] http://j00ru.vexillium.org/?p=2211 http://j00ru.vexillium.org/?p=2211

by chubot 13y ago

nathancahill 13y ago

Playing .mp4's natively uses FFmpeg, but Flash video does not. Both plugins are sandboxed in a "privilege separation" environment that they mention in the post.

jbk 13y ago

> I wonder how many of the bugs led to code execution? Quite a few. We're often affected with VLC, and code execution is easy to get to. But with VLC, you're "only" in userland.

tptacek 13y ago
In other words, you're "only" dealing with a bug that would allow anything you downloaded from BitTorrent to own up your personal account on your computer. :) (I know you know that, I'm just spelling it out for people).
- jbk 13y ago
  Yep, and that's quite dangerous. Especially since you can see often fake videos circulate around, that tell you to download a special software or codec to play them (with malware, of course). WMP also had a scripting/runtime system that could be abused greatly. Be careful what you download :)
fulafel 13y ago
Chrome is also in userland - and it has a sandboxing system. Assuming they're sandboxing ffmpeg, these bugs are more risky for VLC users than Chrome users. Plus, Chrome is more diligent with security updates and the auto-update mechanism is fully automatic. A sandboxing system provided by either ffmpeg or VLC would be a very good idea, though it would be some work... encoded data in, decoded frames out via shared memory. Negligible performance impact.
- chubot 13y ago
  Yeah definitely. Really there is a gross violation of the principle of least privilege here. A video player is a great thing to sandbox because all it needs is a video output, very limited file access, and very limited gui input. It doesn't need to read all your files, open network connections, or start processes. Given that there are apparently thousands of bugs in the video parsing code, it seems like a no-brainer. Section 5.2 in this DJB paper talks about (portable) isolation of plain transformations. Video playing is already close to "pure" or could be made pure pretty easily. http://cr.yp.to/qmail/qmailsec-20071101.pdf http://cr.yp.to/qmail/qmailsec-20071101.pdf
  - jbk 13y ago
    > A video player is a great thing to sandbox because all it needs is a video output, very limited file access, and very limited gui input. It doesn't need to read all your files, open network connections, or start processes. Not sure if serious or sarcasm, to be honest, since this seems very far from what we see. A media player is not simple to sandbox, (as the MacOS X sandbox showed us for example), because: - you need to open files by yourself, without user interaction, to support playlists, - you need to open connections by yourself to support video protocol like RTSP, RTMP, RTP, - you need raw device access to support Webcams, Capture devices, DVDs, DVB tuners, - you need to access GPU buffers for direct rendering, and/or shaders to do fast filtering or just plain chroma-conversions, - you need to be able to access the audio output, at low-level, for libsync which is not always doable with the simplified APIs, - and I don't understand what you mean by "very limited gui input"; how is that less than other programs? Sure, it can be done, with performance costs but it's clearly not a "no-brainer".
Thaxll 13y ago
I'm sure some people are running VLC under root, still in userland but can be very dangerous.
- feepk 13y ago
  This is one of the reasons why you have to use a wrapper for the VLC binary to execute it within a root environment. Said wrapper is usually in an extra package on Linux and not provided on Windows and OS X (it can be compiled manually of course). Like 10 people per year complain about not being able to run VLC as root, but then again, why should you?
- Crito 13y ago
  I'm sure there are some people using telnet and using "password" as their root password. At a certain point it becomes more than reasonable to say "Well don't do that."

mutagen 13y ago

> I wonder how many of the bugs led to code execution? The linked blog article [1] suggests 10% - 20%: Our personal feeling is that between 10% and 20% of the problems could be considered easily exploitable security issues; however, the estimation has not been formally confirmed in any way. [1] http://j00ru.vexillium.org/?p=2211 http://j00ru.vexillium.org/?p=2211