201–210 of 234 posts
Earlier quoted context omitted.
Oh look, it's the Rust Evangelism Strike Force at work again.
Please don't react to provocation by making the thread worse (a.k.a. please don't feed the trolls).
[0] https://lobste.rs/s/wq6eov/changes_i_would_make_go#c_ofxtj1
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…
Scriptless 0day RCE is still possible in a ROP+ALSR world, but exploitation is a real bitch. Ex : https://scarybeastsecurity.blogspot.fr/2016/11/0day-exploit-...
Earlier quoted context omitted.
If only VLC had been re-written in rust this would never have happened. For shame.
We ban accounts for trolling, so please don't do that here. Also, you've posted many uncivil and/or unsubstantive comments. We ban accounts for that too, so please don't do that either.
It's sad that VLC checks updates over HTTP and HTTPS
HTTP or HTTPS does not change that.
Earlier quoted context omitted.
We ban accounts for trolling, so please don't do that here. Also, you've posted many uncivil and/or unsubstantive comments. We ban accounts for that too, so please don't do that either.
Thanks for the heads-up. I'll remember to use a throwaway next time.
Earlier 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").
C'mon.
Earlier quoted context omitted.
Not even multi-process. Threads on Linux can have their own seccomp profiles. You don't need to sandbox absolutely everything at the same time either. In this case opening the file in the main, unrestricted app and spawning a 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. Other points may be more tricky, and it's a good list of p…
> 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.
> 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 vlc.
Earlier 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.