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

211–220 of 234 posts

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

#211

Post by stordoff »

kutkloon7 wrote: post #46

The thing that most amazes my about Popcorn Time is how they find the subtitles. It seems to succeed even when I can't find subtitles myself. More related to the article, you would think that subtitles are literally the easiest file format in existence to safely handle. It's incredibly well-defined in terms of textual data and times.

> More related to the article, you would think that subtitles are literally the easiest file format in existence to safely handle. It's incredibly well-defined in terms of textual data and times.

Depends on the format. SSA for instance can have embedded font and image files, which presumably have much more complex decoders.

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

#212

Post by dang »

lawl wrote: post #201
dang wrote: post #200

Earlier quoted context omitted.

Please don't react to provocation by making the thread worse (a.k.a. please don't feed the trolls).

How are you so sure it's trolling? Someone from the Rust Team has defended such behavior as good marketing [0]. [0] https://lobste.rs/s/wq6eov/changes_i_would_make_go#c_ofxtj1

One is never 100% sure, but note that the first part ("Please don't react to provocation by making the thread worse") holds regardless.

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

#213

Post by fulafel »

jbk wrote: post #155
fulafel wrote: post #142

Earlier quoted context omitted.

You don't need special fast IPC. Even uncompressed video is fine over standard IPC.

Blurays are 60Mbps. Then with 40k60 + HDR, displaying is quite a lot of bandwidth.

A 10 year old PC carries 2.1 GiB/s (= 17 Gbps) over bog standard pipes without tuning or parallelism, as measured by "pv /dev/zero | cat > /dev/null". Uncompressed full HD is 1.5-3 Gbps. (Less actually, since codec output is going to be 4:2:2 or similar)

Yeah, you can come up with high bandwidth scenarios like stereo VR 144 Hz 4k HDR running on barely capable hardware. But 99% of users don't require such tricks and never see any upside from the performance-over-security compromise.

Even if you decide basic IPC is not fast enough, a shared memory buffer for raw frame data is reasonably secure too.

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

#214

Post by amptorn »

FranOntanaya wrote: post #78
kutkloon7 wrote: post #46

The thing that most amazes my about Popcorn Time is how they find the subtitles. It seems to succeed even when I can't find subtitles myself. More related to the article, you would think that subtitles are literally the easiest file format in existence to safely handle. It's incredibly well-defined in terms of textual data and times.

> literally the easiest file format in existence to safely handle. Well, which one of them. There's nearly a hundred different subtitle formats, and each one has a whole set of variants. Just Timed Text alone (XML) can have more layouts than one could count, specially since it's meant to be able to replicate technically all previous industry formats.

> it's meant to be able to replicate technically all previous industry formats

Even the DVD subtitle format, which is just a mostly transparent image overlaid on the picture? In XML?

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

#215

Post by legulere »

Animats wrote: post #173
OneLessThing wrote: post #126

I did security research on VLC on Windows a year or two ago. I may be remembering incorrectly, but last I recall every module was protected by ASLR. Which means that remote code execution is not likely because there is no scripting or network comms to dynamically create a valid ROP chain. I also didn't check for executable heaps at the time but given that all heaps are non executable (which they really shouldn't be e…

every module was protected by ASLR. Address space randomization is not "protection". It's a form of security by obscurity. The odds of an exploit working are reduced, at the expense of more crashes due to exploit failure. It helps developers ignore bugs, since they can no longer reproduce them.

Keeping the location secret is just like keeping the key secret in encryption. You also wouldn't call that security by obscurity.

Still you're perfectly right that ASLR does not provide perfect safety, but merely makes exploitation way harder.

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

#216

Post by Piskvorrr »

rsync wrote: post #185
Piskvorrr wrote: post #63

Earlier quoted context omitted.

Especially with PDFs, my "sanitization" can be your "stripped away all the fonts and functionality - might as well have given me a plain .TXT", and vice versa.

"might as well have given me a plain .TXT"" Yes, please - that sounds fantastic.

I agree - but it's 1.surprisingly complicated for a general solution (positioning and such), and 2.not really a solution for the usual end user (who might appreciate a JPEG instead)

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

#218

Post by airza »

mikeash wrote: post #137
airza wrote: post #107

Earlier quoted context omitted.

i've never seen a double increment exploited before- it's undefined behavior, but what is the typical route against that?

The double increment itself isn't undefined behavior. Note that the two increments were separated with a semicolon, making them separate statements. It's equivalent to pzs_text += 2;. The exploit would presumably involve structuring your data so that the excess increment skips over a terminator of some sort. If it's scanning until it hits a zero byte, and you get it to skip over the zero byte, then you have a buffer…

Ahh, that does make sense, i didn't see that.

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

#219

Post by OneLessThing »

Animats wrote: post #173
OneLessThing wrote: post #126

I did security research on VLC on Windows a year or two ago. I may be remembering incorrectly, but last I recall every module was protected by ASLR. Which means that remote code execution is not likely because there is no scripting or network comms to dynamically create a valid ROP chain. I also didn't check for executable heaps at the time but given that all heaps are non executable (which they really shouldn't be e…

every module was protected by ASLR. Address space randomization is not "protection". It's a form of security by obscurity. The odds of an exploit working are reduced, at the expense of more crashes due to exploit failure. It helps developers ignore bugs, since they can no longer reproduce them.

Total facepalm to this comment.

Does modern ASLR increase costs (time, difficulty, money, skill, etc.) necessary for exploitation and decrease benefits (privs, chances of success, etc.)? If yes, then it's a protection. Any security engineer will tell you unequivocally ASLR is a protection. And one of the most successful ones to date.

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

#220

Post by OneLessThing »

yegle wrote: post #172
OneLessThing wrote: post #126

I did security research on VLC on Windows a year or two ago. I may be remembering incorrectly, but last I recall every module was protected by ASLR. Which means that remote code execution is not likely because there is no scripting or network comms to dynamically create a valid ROP chain. I also didn't check for executable heaps at the time but given that all heaps are non executable (which they really shouldn't be e…

ROP: return oriented programming ASLR: Address space layer randomization Having ASLR is not bullet proof to remote code execution, e.g. iOS has ASLR for a long time and can still be jailbroken (which usually involves a code injection etc). The key is info leak, e.g. if you somehow can reliably find the memory location of open() syscall, the memory location of the whole libc can be inferred, and libc is usually large…

1) ASLR: address space layout randomization 2) Yeah libc is commonly ropped against (though you'd need to check with a linux guy) 3) Yes ASLR is a compiler option (/DYANMICBASE for windows). For windows a flag exists in the PE header, probably something similar in ELFs. When loaded the modules are fixed up so pointers and such are correct.
Post reply on HN