Reply To: ASLR (security)

Address Space Randomization has been primarily a defense against Return-Oriented programming exploits, which are impossible on a Mill. In the absence of any way for an exploit to execute arbitrary code, it’s not clear what data location randomization would buy you. We’re not claiming that an exploit cannot trick a Mill program (exploiters are clever), but we have no example that does in a well structured program.

For example, say the application has secret data, and also has an API that will print out non-secret data from a buffer. A buffer-overrun could alter the program pointer to the buffer to point to the secret data instead, and a following API request would then print out the secret. One might think that ASDRE would help in this case, but it’s actually unnecessary as well as insufficient.

Properly structured, the app would put all secrets in a service in a different turf from the application and the user API. The exploit could then smash whatever it wants in the app, without gaining any access to the secrets.

Consequently we (so far) feel that ASDR is a a snare, giving a false sense of protection, and should not be used. This is true both on Mills and other machines. It is perfectly possible to do the same separation on a conventional by using processes to isolate the secrets from the exploiter, and IPC to access the consequences of the protected information but not the protected info itself, just like a service on the Mill.

The reason it’s not often done that way is a matter of performance and coding ease; mutiprocess code on a conventional is difficult and slow, so ASDR is suggested as a half-hearted kludge alternative. Service code on a Mill is easy and fast, so there’s no need to pile ASDR on top of it.

We’re open to counter-examples 🙂