It's sad that VLC checks updates over HTTP and HTTPS
Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
181–190 of 234 posts
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#182Slightly related to this: where can I find data sanitizers for common file formats (PDF, MP3 and so on)?
I strip all mp3 metadata using the 'id3mtag' tool[1].
id3 -d *.mp3 ; id3 -2 -d *.mp3
I don't do this for security - I just don't like mp3 metadata competing with metadata in the filename and most mp3 metadata is laughably bad anyway[2] so I just wipe it.
[1] /usr/ports/audio/id3mtag on FreeBSD
[2] Misspellings, First Last instead of Last, First, ALL CAPS ALL THE TIME and using special characters/unicode that always breaks car stereo implementations.
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#183Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#184Earlier quoted context omitted.
Not the OP, but valid responses range from "I have a life" to "it's not my project" to "I don't want to". Odd that you think criticism depends on contribution.
those are likely most of the same reasons these apps are not sandboxed (switching "not my project" with "I'm not payed work on this").
Those are valid reasons not to improve a project, but it doesn't make your project immune to criticism. If you're not going to take the time to make your project better, that's fine, but other people are still free to point out that your project isn't very good or that your project could be much better if you managed your time differently.
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#185Earlier quoted context omitted.
what counts as sanitizing? How do you know a file is malicious?
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.
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#186Earlier quoted context omitted.
those are likely most of the same reasons these apps are not sandboxed (switching "not my project" with "I'm not payed work on this").
Those are valid reasons not to improve a project, but it doesn't make your project immune to criticism. If you're not going to take the time to make your project better, that's fine, but other people are still free to point out that your project isn't very good or that your project could be much better if you managed your time differently.
Tepix's point was about entitlement, not criticism.
"There is no excuse for ___" definitely crosses the line from criticism to entitlement. :^)
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#187Wow, 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…
So far I did not know that there is anything in video subtitles, that needs interpretation. What is needed is not a sandbox, but simply code, which stops trying to do weird stuff with something as static as subtitles. They should be a timestamp for the time in the video where the text shall appear plus text itself nothing more. If it does not parse according to a specific format throw that stuff away and read the next line in a subtitles file or simply declare the whole file invalid and be done with it.
Don't try and start doing weird things with something like subtitles and we are fine.
Why does VLC or one of the other programs feel the need to do anything more than that, resulting in gaping security vulnerabilities? Is there any good justification? Or is this again about some overflow with unexpectedly long strings or something like that? (In such case it is the not so careful programming on VLC side that is the problem)
Furthermore the subtitles are often inside the video graphical data itself. I've actually never used a subtitles file. I tried a few times, but every single damn time they were off, and not only off but exponentially off, which made it impossible to get the correct text for all play positions in the video. If you ask me, so far all the subtitle files I tried for any movie suck anyway.
(This is ignoring any subtitle file specifications, which might exist.)
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#188Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#189Wow, 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…
So far I did not know that there is anything in video subtitles, that needs interpretation. What is needed is not a sandbox, but simply code, which stops trying to do weird stuff with something as static as subtitles. They should be a timestamp for the time in the video where the text shall appear plus text itself nothing more. If it does not parse according to a specific format throw that stuff away and read the nex…
> They should be a timestamp for the time in the video where the text shall appear plus text itself nothing more.
I think the option to have positioning information was a good idea.
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#190Earlier quoted context omitted.
No. Java doesn't have fearless concurrency, zero-cost abstractions or move semantics.
"Fearless concurrency" and "zero-cost abstractions" sound a lot like meaningless marketing terms.
Only to someone who hasn't experienced the earth-shattering enlightenment rust provides.