It's sad that VLC checks updates over HTTP and HTTPS
VLC updates are signed with asymetric encryption. HTTP or HTTPS does not change that.
HTTPS would increase user privacy by not leaking application details though.
Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
221–230 of 234 posts
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#222I 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.
>Address space randomization is not "protection". It's a form of security by obscurity.
This is somewhat akin to saying "Randomly generated passwords are not 'protection'. They are a form of security by obscurity."
If things are random enough that an attacker is significantly hampered in most cases, that's one measure of security, no?
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#223Earlier quoted context omitted.
"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)
(btw there's `pdftotext`, which is pretty good in most cases)
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#224Earlier quoted context omitted.
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.
>Address space randomization is not "protection". It's a form of security by obscurity. This is somewhat akin to saying "Randomly generated passwords are not 'protection'. They are a form of security by obscurity." If things are random enough that an attacker is significantly hampered in most cases, that's one measure of security, no?
It is going to vary quite a bit depending on the entropy of the ASLR implementation. Many have only had 8-12 bits of entropy to start with, and you sometimes don't need the full address. It is also important to note that services that crash typically restart, allowing retries (sometimes as many as you want). In this case, one might imagine trying to attack thousands of people: some of them will randomly work (and a lot of users are going to see VLC crash and will retry playing the file a number of times, increasing your probability).
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#225Earlier 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.
"fearless concurrency" is meaningless marketing, "zero-cost abstractions" is valid term
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#226This is interesting to me for reasons outside of anything to do with exploits or malware. A while back I had a bit of a brain fart while playing with my Hue bulbs: would there be a way to use the subtitle track for a video to encode time-controlled data that can be sent to/read by another application that sends these values to a set of Hue bulbs or similar devices for synchronized ambient lighting?
I figured that subtitles were an obvious place to start because you can download them in small files, play them back alongside a video, and they are designed to be "timed out" to synchronize with a video already.
I looked into it for a bit but never really found a way (within my abilities at least) to do anything like this from within a .srt file or similar. I'd be interested in hearing if anyone else has more info on how you might do more with that "framework" than displaying text on screen.
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#227Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#228Earlier quoted context omitted.
> Threads on Linux can have their own seccomp profiles. Not on Windwows or on macOS. > new thread that will read from the existing FD and only send you simple, time sorted messages over a shared IPC/pipe is not that crazy. Of course that does not solve anything, because your demuxer|decoders|output needs access to the FS, have access to kernel-mode and those are the dangerous parts.
> > Threads on Linux can have their own seccomp profiles. > Not on Windwows or on macOS. It's a shame, then, that Windows & macOS are holding back security improvements for software running on Linux. I understand (& even agree with!) your desire to have a sandboxing mechanism which runs acceptably on all supported systems; it's just sad that this security mechanism in the Linux kernel can't be taken advantage of in v…
Well, no. Because you can do it per-process. I don't see the reason of doing it per threads here.
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#229Earlier quoted context omitted.
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 n…
Knowing that today we still see bandwidth issues in VLC, even without IPC, I kind of doubt it.
Re: Malicious Subtitles Threaten Kodi, VLC and Popcorn Time Users
#230Earlier 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").
So open source always gets a free pass? "You should be doing X as what you're doing represents a security threat." "Well, submit a patch then neener neener." C'mon.
they don't, it's just that the statement "there is no reason for this software not to have a sandbox" is wrong, because, well, there are many reasons.
A correct statement might have been "there is no technical reason that prevents sandboxing, given a ton of work".