> Is ASLR worth it or just some useless obfuscation we don't need to care
> about? I can't judge.
I may be completely wrong here, but as far as I know the main motivation
for ASLR were attacks like stack overflow in C. As far as I know, in
C it is trivial (actually a non-op) to take the address of anything:
functions, data structures, the stack, etc. So, if taking addresses were
really that big problem, ASLR would be dead before starting.
This isn't necessarily true.
I mean, if you're compiling and executing arbitrary untrusted C code, you're already doing something wrong to begin with. But disregarding that, even C code shouldn't be able to arbitrarily snoop on the memory space of OTHER processes. In a secure system, you wouldn't want a C program to be able to -- for example -- leak data from kernel structures, or probe the memory layout of a running service. Before ASLR, it was fairly simple to figure out a system's memory map after a clean, deterministic startup. ASLR means that even if you were able to get unauthorized privilege escalation in C code you still have more work to do before you can go start messing around in the kernel.
As I said, it's about defense in depth. Pointers are not themselves evil. Pointers to things that don't belong to you, on the other hand, are a foot in the door.
The whole idea of ASLR was to avoid knowing addresses *before* being
able to execute code in the machine. Once you can execute code, things
get pretty hard.
For instance, I could agree with a complain that an error message is
showing a memory address. That is something someone can provoke
and see from outside, without running its own code in the machine.
Attack-resistant sand boxes are hard and tricky (even with hardward
support!). The string library is particularly problematic, because
they provide the only functions that can be called even in an empty
environment, and these functions can greatly ease a DoD attack. (DoD
attacks in pure Lua can be stopped by debug hooks, but slow C functions
do not go through hooks.) Should we remove string methods too, in favor
of "better security"?
Of course not. Lua shouldn't be expected to remove a core piece of functionality just because of a security risk. That simply wouldn't make sense.
All anyone is seriously asking for is to provide engineers with the tools to create a secure environment when it's needed. I'm not going to presume to dictate the specific choices that should be made here; as I said before, this is outside of my use case and I'm only trying to prove information. I understand who cares about it, and I understand what the impact is from a security perspective, but there are various ways to handle it and I would rather leave the details to the people who know the system best.
/s/ Adam
