Hacker News Reader

Comment by OneLessThing | Hacker News Reader

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 executable in VLC) again I don't see how RCE is possible. Maybe there is some way to validate and therefore brute force addresses? I don't know. But there was no VLC POC and I'm sure they would have made one if they could have.

Use VLC it's the most secure media player I've seen.

View on HN

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 enough to construct a ROP chain. (I haven't work in security area for a long time so correct me if I'm wrong).

The researcher unable to provide a POC for vlc could simply mean it's hard due to ASLR, but it's not impossible.

Also: I believe ASLR is a compiler option (with a supported OS), it should be relatively easy for Kodi and Popcorn Time to start using ASLR.

Most of moderns RCE POCs lift off a scripting engine (VBS for Office, Javascript for browsers, ActiveX for Flash, etc..) in order to facilitate exploitation. The only ones which does not use a script engine are POC exploiting a "network" vuln (like SMB).

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-...

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.

That's also why we're perplexed at the supposedly code execution.

Also, the security researcher did not provide a demo for the VLC exploit. Their demo is only on Kodi and popcorntime.

But anyway, security issues means releases.

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.

> It helps developers ignore bugs, since they can no longer reproduce them.

Well, it would crash, so they can reproduce it, no?

In my experience, bugs are almost always easier to reproduce with address randomization. It's easier to see a process leave readable/writable memory than it is to see it overrun a buffer and only trash app code.

"Only" security by obscurity is the best we can get in the c/++ world without compiling for a virtual machine.

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.

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.

>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).

Off topic: I love VLC but can't get it to use hardware acceleration on my late 2015 mac. 4k 60fps @ 40mbps consume all CPU if I try to play a lower compression 150mbps video it studders and all my fans turn on. mpv and quicktime play the same videos with 15-20% CPU. The poor performance of VLC on my macOS makes it a no go for me.

Try 3.0, this is fixed.

Reply on news.ycombinator.com