2015-03-03 18:38 GMT-08:00 Christophe Hauser <christo...@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/