Android mediaserver exploit – heap thermal vision | Hacker News Reader

Android mediaserver exploit – heap thermal vision

bits-please.blogspot.com

38 pointslaginimaineb7 comments

That's a really nice explanation of security topics. It concisely explains the tough stuff without being dumbed down or hand-waving away the complex bits. That's rare. A lot of exploit documentation has a "leet" feel to it, or at least a condescending and dismissive tone (particularly toward the developers of the software being exploited) that I find off-putting.

Also, nice map.

Thank you. Also, the map is mostly Thorin's, with only slight adaptations :)

Great write up. But does this mean that Google doesn't hold themselves to project zero's 90 days before disclosure? (Or have they realized that 90 days really isn't enough time?)

In this case, it seems so. However, I must say I've reported many vulnerabilities to Google since and they've all been handled within that time-frame.

Is there a reason you didn't publicly disclose after 90 days? (I'd argue that the criticality of the vulnerability would justify a 7-day timeframe). The one problem with the way the security community deals with large vulnerabilities is that the researchers don't stick to their guns regarding responsible disclosure. I would prefer to know that I have to do <XYZ> to minimise the impact rather than find out that I was vulnerable for more than 5 months. Hell, I'd be happy to stop using my smartphone for a week if it meant the problem would be solved faster.

Is there any chance that ASLR would put libcamera_client.so in a lower memory location than get_input_buffer_size so you couldn't increment the pointer to reach it?

That's a great question! I didn't cover this in the blog post, but there is a primitive identical to the increment-by-one presented there, which allows me to decrement-by-one as well (I've gone into more detail in the exploit code: https://github.com/laginimaineb/cve-2014-7920-7921)

Reply on news.ycombinator.com