Reply To: ASLR (security)

The advantage of the Mill regarding return oriented programming is it increases the security of existing code. I’m not sure if by well structured you mean changed to take advantage of the Mill security model. Assuming you are interested in protecting users against poorly written code (after all if you’re not just tell the user to port to a language with bound checking) here is a counter-example of sorts:

In a login program I have a heap allocated struct containing a buffer for the user password followed by a function pointer pointing to what should be executed when a login attempt fails. The program fails to check for the user entering extremely long passwords, and the user knows where the login success function is usually located. They enter an extremely long password, overflowing the buffer and writing the address of the login success function into the function pointer that points to the code to execute on login failure. The program decides the user password is invalid, follows the function pointer, and grants the user access. If the location of the login success function is randomized, the attacker is thwarted.

Note that no return oriented programming or digging through stack rubble was needed. Returns are convenient on conventional architectures because they are a frequently occurring jump that can be influenced by corrupt data, but every C function pointer and every C++ vtable pointer can potentially be used as well. These attacks are harder to pull off because you don’t always have conveniently located buffers next to function pointers, and vtable pointers are usually at the front of objects, but there have been real vulnerabilities where the attacker relies on knowing two objects will be next to reach other on the heap and overflowing a buffer in the first to overwrite the vtable pointer in the second. A lot of the browser hacking competitions are won by people stringing together long sequences of this sort of gymnastics.