Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

blog.checkpoint.com

Post reply on HN
Print view View original

91–100 of 234 posts

Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

#91

Post by [deleted] »

Tepix wrote: post #80
captainmuon wrote: post #8

Wow, that is bad. I'm always amazed by such vectors in supposedly passive formats, like fonts, images, and so on. There is no excuse that these kind of applications are not completely sandboxed. All you need is some kind of DLL, raw data in, raw pixels out. In case of hardware accelerated codecs, raw pixels in, surface pointer in, nothing out. There is no need to be able to access the filesystem, etc.. To render subt…

"There is no excuse that these kind of applications are not completely sandboxed." Woah, what a sense of entitlement! What's your excuse for not having submitted a patch years ago?

[deleted]

Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

#92

Post by jbk »

Filligree wrote: post #88
jbk wrote: post #79

Earlier quoted context omitted.

That's exactly the point above. See my above comment.

I'm not sure, it sounds like you're saying we'd need to copy memory. The shared memory segment can be a GPU image buffer, so I don't think that's true.

See comment above with "the solution".

Either you need to have multi-process and correct IPC, or you need to copy.

Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

#93

Post by ackfoo »

Treat data as data. Taking the Subrip format as an example, everything starts out fine so long as there is good bounds checking on the purely textual data.

Then, however, some dipshit decides to extend the format by adding tags for things like bold, italics, underline etc. This is completely unnecessary for subtitles because the emphasis can be inferred from the dialogue. The unnecessary complexity increase the potential for vulnerabilities.

Then some total dickhead decides to add an HTML5 tag, for no reason whatsoever, and it all goes to hell.

This is illustrative of the problem with most software: the absence of a clear-headed benevolent dictator to say, "no; you are an idiot; we're not doing that."

Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

#94

Post by jbk »

johncolanduoni wrote: post #90
jbk wrote: post #83

Earlier quoted context omitted.

But you need to pass data from the access to the stream_filter, from the stream_filter to the demuxer, from the demuxer to several decoders, from the decoders to potentially a few video-filters and chroma-converters, and then finally to the output. Each of them need different access policies, and several of them require FS access. It is not easy. If it was, people would have done it already.

You can get most of the security people are asking for without that level of granularity. If the decoder is exploited and is able to attack the demuxer, that's still worlds better than the decoder being able to run with full user privileges. Do any of those components need unrestricted/unpredictable file access? Because if they don't you can just open the files in the main process that handles the UI and send them to…

But the issue is not only file access. File access is a small part of the main problem.

Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

#95

Post by johncolanduoni »

jbk wrote: post #85
johncolanduoni wrote: post #58

Earlier quoted context omitted.

> Probably do a multi-process media player, like Chrome is doing, with parsers and demuxers in a different process, and different ones for decoders and renderers. Knowing that you probably need to IPC several Gb/s between them. That's not actually how Chrome's renderer sandboxing works. Both Windows and OS X allow you to share a GPU-resident texture between processes (DXGI shared surfaces and IOSurface respectively),…

But you need to pass data from the access to the stream_filter, from the stream_filter to the demuxer, from the demuxer to several decoders, from the decoders to potentially a few video-filters and chroma-converters, and then finally to the output. Each of them need different access policies, and several of them require FS access. The last part is just one of the issues, very far from all of them. Seriously, stop thi…

I don't think nobody has thought about it, but since you were apparently unaware that there was an alternative to performing several GB/s of IPC for moving buffers around there's obviously some options that haven't been considered. The Chromium sandbox has to deal with every issue you've listed (it's even calibrated to run ffmpeg inside the sandbox, since that's something Chromium needs to do).

Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

#97

Post by jbk »

johncolanduoni wrote: post #95
jbk wrote: post #85

Earlier quoted context omitted.

But you need to pass data from the access to the stream_filter, from the stream_filter to the demuxer, from the demuxer to several decoders, from the decoders to potentially a few video-filters and chroma-converters, and then finally to the output. Each of them need different access policies, and several of them require FS access. The last part is just one of the issues, very far from all of them. Seriously, stop thi…

I don't think nobody has thought about it, but since you were apparently unaware that there was an alternative to performing several GB/s of IPC for moving buffers around there's obviously some options that haven't been considered. The Chromium sandbox has to deal with every issue you've listed (it's even calibrated to run ffmpeg inside the sandbox, since that's something Chromium needs to do).

> but since you were apparently unaware that there was an alternative

I will refrain from answering to such attacks. As you seem to know better, I'm waiting for your patches.

Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

#98

Post by FrozenVoid »

jbk wrote: post #22
captainmuon wrote: post #8

Wow, that is bad. I'm always amazed by such vectors in supposedly passive formats, like fonts, images, and so on. There is no excuse that these kind of applications are not completely sandboxed. All you need is some kind of DLL, raw data in, raw pixels out. In case of hardware accelerated codecs, raw pixels in, surface pointer in, nothing out. There is no need to be able to access the filesystem, etc.. To render subt…

Ha, the famous sandboxing remark. I wish it was that simple! So, let me share some light on the sandboxing for multimedia (I work on VLC). If you sandbox an application like VLC, in the current way of doing sandboxing, which we've done for macOS, WinRT/UWP, and snaps, you still need a lot of permissions. Namely: - you need to be able to open files without user interactions (no file picker), in order to open playlist,…

All this means Linux is misdesigned for user apps, forcing low-level code instead of proper APIs. Maybe stuffing everything into the kernel isn't a good idea after all? All these things are exploit attack surfaces.

Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

#99

Post by cbr »

ackfoo wrote: post #93

Treat data as data. Taking the Subrip format as an example, everything starts out fine so long as there is good bounds checking on the purely textual data. Then, however, some dipshit decides to extend the format by adding tags for things like bold, italics, underline etc. This is completely unnecessary for subtitles because the emphasis can be inferred from the dialogue. The unnecessary complexity increase the poten…

    This is completely unnecessary for subtitles because
    the emphasis can be inferred from the dialogue.
Seems useful for deaf people

Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users

#100

Post by Brockenstein »

jbverschoor wrote: post #64
jbk wrote: post #22

Earlier quoted context omitted.

Ha, the famous sandboxing remark. I wish it was that simple! So, let me share some light on the sandboxing for multimedia (I work on VLC). If you sandbox an application like VLC, in the current way of doing sandboxing, which we've done for macOS, WinRT/UWP, and snaps, you still need a lot of permissions. Namely: - you need to be able to open files without user interactions (no file picker), in order to open playlist,…

You actually don't NEED a lot of these things I'm perfectly fine with a default / embedded font. I don't have an optical drive A database can be in the local app storage. I'm fine opening a subtitle file myself. Why would I need IPC? Why would I need to unzip anything? If it's subtitle files, it can be done in-memory. Are you sure we need low-level audio? I don't have a remote, so I'd like it to be disabled by defaul…

Let's play, "why isn't my use case the only use case."
Post reply on HN