> Sure, If code with knowledge of an address is willing to act as an > oracle, then ASLR is not useful. This is really just an indirect (and > unlikely) way of leaking an address though. We'll but keep in mind here that the knowledge we are talking about is based on the binary image as far as I can tell and knowledge of the order of mapping, which given the mechanisms in place for privilege separation or at least common forking a child is not that far of a stretch. "I am mapping X and there will be Y mappings with a total size of Z before me whose base address is A from the first/last loaded module" > > Well, if you know in advance which address to leak you can arrange for > it to be a useless one, it would usually have to be MMAP_FIXED and be > sanitized (think KUSER_SHARED_DATA on Windows or the vsyscall page on > Linux) so as not to weaken ASLR. Well but these addresses are not fixed, it's just that modules are being loaded in alphabetical order sans ld.so and the distance between them is not randomized. Is KUSER_SHARED_DATA still not randomized? Compare all of this with the openbsd allocator and it's output and loaded modules. I haven't looked at their kernel but I'm assuming they randomize mmap base, then in the allocator the use arc4 to further randomize the offset into the allocated memory. This would fix circumstances except for where a module has a long string of repeated instructions that could be utilized. Also It's not just the first mapping, it can be any malloc (or direct mmap) output that you how many and the size of those who came before you. This is actually not a stretch especially in post-auth server-side paradigms. > Well, good luck. Thanks. I seem to recall hearing that once before in relation to similar in another OS when I pointed it out, "creepy" I'll just get my hands on another linux box somewhere; if this pattern holds its actually a really big problem. Consider akin to (and this is somewhat of an imaginary stretch) call malloc mov rcx, [user] lea rbx, [rax+rcx] ; wrap call [rbx+vtableoff] ; actually lands in libc
Source: Gmail -> IFTTT-> Blogger
No comments:
Post a Comment