Hacker News new | ask | show | jobs
by phessler 3531 days ago
This would not be exploitable if ASLR was enabled.
3 comments

That is a big assumption to make in this case.

Firstly, the attacker has a level of control over the type of data that lies before the freed and wrongly coalesced block, and so they have a level of control over how the data they are overwriting will be interpreted. It might actually be possible to arrange that the data block is expected to contain dynamically generated executable code (e.g. output from JavaScript JIT compilation), and by replacing that with arbitrary position-independent code you immediately still have arbitrary code execution.

Secondly, this class of bug potentially also allows for information leakage. Block A precedes block B in memory, and B's header is overwritten. A is freed and merged with B. Now the attacker induces (A+B) to be allocated as a block type that lets them read out data, and then induces some data that includes addresses to be written to B by way of an update. The attacker then reads out (A+B), gaining information about the address space that they can then use for a successful exploit.

ASLR certainly can make attacks harder and some attacks impossible, but it is not safe to assume it gives you immunity from exploitation for this type of bug.

(I wrote the blog post)

ASLR was enabled. The attacker worked around it.

I wonder what was wrong in this post?

"Being exposed to djbdns I was never tempted at all to try c-ares. Not sure what I missed. It must have some other redeeming qualities besides this one. :) Learning to master nc and tcpclient before curl* had the same effect. I guess I am missing all the fun. *There are so many features, so much rarely used code, I'm not sure one could ever hope to fully understand all the implications." jingo 22 hours ago [dead] [-]