full-disclosure - Re: [FD] #WorldPenguinDay or this cant be right, can it?

Open Source and information security mailing list archives

Date: Fri, 1 May 2015 10:08:40 -0400
From: PIN <zero@...c.co>
To: Tavis Ormandy <taviso@...xchg8b.com>
Cc: fulldisclosure@...lists.org
Subject: Re: [FD] #WorldPenguinDay or this cant be right, can it?

> 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

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives