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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 1 May 2015 06:51:43 -0700
From: Tavis Ormandy <taviso@...xchg8b.com>
To: PIN <zero@...c.co>
Cc: "fulldisclosure@...lists.org" <fulldisclosure@...lists.org>
Subject: Re: [FD] #WorldPenguinDay or this cant be right, can it?

On 1 May 2015 at 00:11, PIN <zero@...c.co> wrote:
>> It sounds like you're asking "If I can learn an address, have I defeated
>> ASLR", and the answer is usually yes.
>
> Really? Because leaking a heap address in windows, openbsd, etc doesn't
> yield a full collapse of all loaded modules randomization given the
> preconditions; I'm asking that it's not just my box exhibiting this
> behavior- which is a long story why it must just be mine.

That wasn't what I said.

> Well, you are somewhat missing the gravity here. If this is generally
> reproducible, you don't need the address to leak, you just need a series of
> arithmetic operations to land you at a fixed offset within the target
> module. no read back requisite.

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.

> I'm fairly positive that no ASLR scheme is intended to entirely and totally
> collapse given a single address that you don't necessarily even need to
> know. Thus I find it hard to believe this is the case.

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.

That isn't usually the case though, so the scheme will usually be defeated.

>>You don't usually run untrusted python, > so
>> python's id() isn't a bug - but you do run untrusted JavaScript.
>
> Really? Because your employer does exactly that.

Creepy. I said "usually".

> The bigger question was the
> behavior, not python. It seems a practical extension of the spy in the
> sandbox stuff to potentially grab enough of an address to leverage this in
> javascript, although code is not yet forthcoming there. However giving the
> cache line and physical to virtual address scheme mappings, this seems
> likely.

Well, good luck.

Tavis.

-- 
-------------------------------------
taviso@...xchg8b.com | pgp encrypted mail preferred
-------------------------------------------------------

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ