News for hackers. Stuff that matters.
Re:Firefox vs. rthreads by gpvos on Monday April 11, 2016 @09:38AM (#11471344)
The article mentions that vDSOs have negative security implications. After reading up on what a vDSO is, it is apparently (in Linux) a security fix on an earlier implementation called vsyscall. Can anyone enlighten me what security issues are left in the vDSO system?
Re:Firefox vs. rthreads by geofft on Monday April 11, 2016 @11:15AM (#11472047)
Right, I don't understand this and I couldn't find an explanation of why OpenBSD has rejected it, at least for gettimeofday(). I can imagine the following:

* The vDSO is mapped at a fixed address in every process, making return-to-libc-style attacks easy. This doesn't seem to be necessary, though, since it's a virtual dynamic shared object, and you can ASLR it just like you can ASLR any other dynamic library. Just tell the program where you put it.

* The vDSO (or at least the vsyscall page, not sure if this is still true) includes a syscall instruction, making it a juicy target for return-to-libc-style attacks. But for gettimeofday() you don't need that. Just include the instruction to read some dedicated read-only page from memory-mapped timer hardware, or run RDTSC, or whatever, and make your ABI such that it permits the vDSO call to fail and regular libc code might have to make a real syscall if it does. Or that the vDSO isn't guaranteed to be present, and is missing if hardware support is missing.

Any further information here?

Re:Firefox vs. rthreads by brandmeyer on Monday April 11, 2016 @11:37AM (#11472230)
The vDSO mapping is definitely randomized by ASLR on my system. You can confirm with 'ldd $(which ls)' on your system.
Re:Firefox vs. rthreads by exDM69 on Monday April 11, 2016 @09:55AM (#11471459)
I guess there are no known security issues but they are speculating that the vDSO mechanisms may have not-yet-discovered bugs in them.

The idea is just having a special page that is mapped as read-only in userspace and kernel writable. If it's correctly implemented, it should be safe.

Re:Firefox vs. rthreads by gpvos on Monday April 11, 2016 @12:00PM (#11472442)
I guess they just see every extra interface between kernel and userland as another attack surface and therefore to be avoided.