Full Disclosure mailing list archives
Re: Partial pointer leaks
From: Robert Święcki <robert () swiecki net>
Date: Thu, 5 Mar 2015 10:42:15 -0800
2015-03-03 18:38 GMT-08:00 Christophe Hauser <christophe () cs 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/
Current thread:
- Partial pointer leaks Christophe Hauser (Mar 04)
- Re: Partial pointer leaks Robert Święcki (Mar 06)
- Re: Partial pointer leaks Christophe Hauser (Mar 07)
- Re: Partial pointer leaks Gil Besso (Mar 08)
- Re: Partial pointer leaks Christophe Hauser (Mar 07)
- Re: Partial pointer leaks Robert Święcki (Mar 06)