News for hackers. Stuff that matters.
Re:The DrK Attack: De-randomizing Kernel ASLR by JoshTriplett on Wednesday October 26, 2016 @11:22AM (#12797171)
Providing user control over page faults and using that for a security exploit reminds me of the classic UNIX tale of password checking. A version of UNIX had a privileged mechanism that would check a password (provided by pointer); it did so character-by-character. It also had a way for userspace processes to handle page faults themselves. So, put a password buffer across two pages, with the page boundary after the first character, and change the first character until you get a page fault. Repeat for each character of the password...
Re:The DrK Attack: De-randomizing Kernel ASLR by shenberg on Wednesday October 26, 2016 @01:10PM (#12798319)
The system mentioned is TENEX (not *nix) according to http://research.microsoft.com/en-us/um/people/blampson/33-Hi... (a great paper from '83 that was posted here recently. search for password to find the exact reference there)
Re:The DrK Attack: De-randomizing Kernel ASLR by JoshTriplett on Wednesday October 26, 2016 @01:34PM (#12798563)
Thanks for the correction. The version of the story I saw came from a systems programming book, which attributed it vaguely to some past UNIX system of yore. Glad to have a more accurate reference.
Re:The DrK Attack: De-randomizing Kernel ASLR by Aissen on Wednesday October 26, 2016 @12:00PM (#12797550)
It's nice because it allows a slow and controlled timing attack, but you don't need a page fault to do that, you can simply measure elapsed time with high resolution timers, perf or whatever you have on hand :-)
Re:The DrK Attack: De-randomizing Kernel ASLR by JoshTriplett on Wednesday October 26, 2016 @12:09PM (#12797638)
True, a privileged process having data-dependent execution time for secure data can lead to a variety of side-channel attacks.

For more complex cases than password validation, it would help if it were easier to write side-channel-resistant algorithms in something other than assembly. Even a C compiler, let alone something higher-level, can introduce side-channel leaks through optimization.

Re:The DrK Attack: De-randomizing Kernel ASLR by Animats on Wednesday October 26, 2016 @01:08PM (#12798298)
That wasn't UNIX. It was TOPS-20 on the DEC 36-bit machines.