full-disclosure

Open Source and information security mailing list archives

Date: Thu, 5 Mar 2015 10:42:15 -0800
From: Robert Święcki <robert@...ecki.net>
To: Christophe Hauser <christophe@...ucsb.edu>
Cc: fulldisclosure@...lists.org
Subject: Re: [FD] Partial pointer leaks

2015-03-03 18:38 GMT-08:00 Christophe Hauser <christophe@...ucsb.edu>:
> Hi everyone,
>
> I am posting this message in the hope to gather suggestions about
> potential past vulnerabilities of a specific kind (described below), or
> ideas about applications, libraries or APIs that might potentially be
> subject to it.
>
> As part of an academic project, I am looking for examples of partial,
> and eventually indirect pointer leaks in the wild. I am basically after
> leaks that only reveal several bits (but not all) of an address (heap,
> stack, function, anything). What I mean here by indirect is the fact
> that the leaked information might not look like an address (or be an
> address) by itself. It could for example be the result of some operation
> (arithmetic or whatnot) on an address.
>
> I am not looking for general information disclosure vulnerabilities such
> as buffer over-reads (that may only be triggered by some specific out of
> range parameters or input), but rather for pointer leaks as being the
> result of manipulation errors, or "dangerous use of pointers", or
> anything else resulting in data dependency between a pointer and an
> output variable of any given application. If this description reminds
> any past vulnerabilities to anyone, I would be very interested to hear
> about it.
>
> Otherwise, something that comes to mind is applications/APIs using
> pointers or addresses (or anything deriving from them) as identifiers,
> with or without obfuscation.  I read for example that INET_DIAG socket
> API in the Linux kernel is (or at least was) actually using addresses as
> handles[1]. Any other similar examples would be very interesting, both
> in user-space and kernel-space.

I'm not sure if that's what you look for, but certain perf operations
leak one or two addresses from the kernel space in the default Ubuntu
configuration. It's possible to write a short PoC, but it might take a
few mins, instead feel free to to compile and use
https://code.google.com/p/honggfuzz/source/checkout - which serves
other purpose, but uses perf as well. This behavior could be well by
design though, I haven't checked yet.

It will only work under newer Intel CPUs BTW.

$ ~/src/honggfuzz/honggfuzz -n1 -N1 -d4 -s -Dp -- /bin/true  | cut -f9
-d" " | grep ffffffff | sort | uniq
0xffffffff8178ad82
0xffffffff8178ba47

# Remove the last 4 bits here
$ sudo grep ffffffff8178ad8. /boot/System.map-3.16.0-31-generic
ffffffff8178ad85 t sysret_careful

$ sudo grep ffffffff8178ba47 /boot/System.map-3.16.0-31-generic
ffffffff8178ba47 T native_irq_return_iret

HTH

-- 
Robert Święcki

_______________________________________________
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