[Sephr]

ASLR has been thoroughly broken through cache and memory subsystem timing attacks. It seems reasonable to leave breaking ASLR as an exercise for the reader in order to focus more on the core vulnerabilities being discussed.

> It is worth noting that for the sake of this exploit I assumed the attacker has knowledge of the memory layout of the executed program(3)

This is not the same as saying "this cannot be exploited with ASLR".

[staticassertion]

Ever since that paper was linked to on Ars everyone thinks ASLR is done for. ASLR was always vulnerable to cache timing attacks. ASLR can not protect you in the case that you can arbitrarily compute on the target machine - this is not new, this has never been the goal of ASLR. That paper was not the first to demonstrate this.

If you can not arbitrarily compute on the target machine ASLR is still completely useful. This is the case for tons of vulnerabilities, like basically anything that isn't a web browser with JS execution privileges.

[wahern]

  > If you can not arbitrarily compute data on the target
  > machine ASLR is still completely useful

Cache timing and other side channel attacks can be done remotely. RSA implementations have been broken via side channels across ethernet and even via thermal noise.

That said, that ASLR could theoretically be broken remotely hardly implies that ASLR isn't an effective mitigation.[1] If you can quantify the rate of leakage across the channel you could, for example, throttle requests to make an attack impractical. Just be careful about underestimating the rate of bit leakage, or forget that a few leaked bits can make practical a brute-force trial+error attack.

This is why, arguably, the new best practice in writing service daemons (see recent OpenBSD work) is to fork+exec when restarting a service, even when restarting it statefully; as opposed to just resetting internal process state. Also, daemons and daemon slaves should be periodically restarted automatically.

This can be difficult to do, especially if you want to avoid dropping existing, long-lived connections. But when writing new software it's not too bad, especially if you farm out sensitive work (e.g. key signing, complex object parsing) to subprocesses that can be spawned and reaped independently and at a faster rate.

[1] We shouldn't discount the distinction between targeted and untargeted attacks. Currently untargeted attacks don't typically rely on breaking ASLR via timing attacks, and even when they do we can expect that the _cost_ of mass scale timing attacks to be significantly greater. Basically, there's no reason to believe ASLR to be a completely useless mitigation against remote exploits; quite the contrary. Useless for local exploits? Maybe, especially considering that Linux and Windows kernels are so riddled with exploits.

[tedunangst]

It's not immediately clear, however, how one would conduct a cache timing attack against the package manager.

[Sephr]

Through bad antivirus code that inadvertently runs your code in a sandbox. There have been multiple vulnerabilities like this recently.

[tedunangst]

Sounds like we should design our package managers so that they don't run hostile code in a sandbox.