3 ms·

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 earlie

by gpvos 11y ago

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?

exDM69 11y ago
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.
- gpvos 11y ago
  I guess they just see every extra interface between kernel and userland as another attack surface and therefore to be avoided.
geofft 11y ago
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?
- brandmeyer 11y ago
  The vDSO mapping is definitely randomized by ASLR on my system. You can confirm with 'ldd $(which ls)' on your system.

by gpvos 11y ago

exDM69 11y ago

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.

gpvos 11y ago
I guess they just see every extra interface between kernel and userland as another attack surface and therefore to be avoided.

geofft 11y ago

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?

brandmeyer 11y ago
The vDSO mapping is definitely randomized by ASLR on my system. You can confirm with 'ldd $(which ls)' on your system.