Solved Address Space Layout Randomization (ASLR)

Put all that have value 1 in /etc/sysctl.conf with value 0:

Code: 
{beastie} @ FreeBaSeD-T430 > /home/beastie
 → sysctl -a | grep aslr
kern.elf32.aslr.stack: 1
kern.elf32.aslr.honor_sbrk: 0
kern.elf32.aslr.pie_enable: 1
kern.elf32.aslr.enable: 1
kern.elf64.aslr.stack: 1
kern.elf64.aslr.honor_sbrk: 0
kern.elf64.aslr.pie_enable: 1
kern.elf64.aslr.enable: 1
vm.aslr_restarts: 12732

edit.: But why you want to do that?
 
BobSlacker said:
Put all that have value 1 in /etc/sysctl.conf with value 0:

Code: 
{beastie} @ FreeBaSeD-T430 > /home/beastie
 → sysctl -a | grep aslr
kern.elf32.aslr.stack: 1
kern.elf32.aslr.honor_sbrk: 0
kern.elf32.aslr.pie_enable: 1
kern.elf32.aslr.enable: 1
kern.elf64.aslr.stack: 1
kern.elf64.aslr.honor_sbrk: 0
kern.elf64.aslr.pie_enable: 1
kern.elf64.aslr.enable: 1
vm.aslr_restarts: 12732

edit.: But why you want to do that?
Click to expand...
BobSlacker said:
Put all that have value 1 in /etc/sysctl.conf with value 0:

Code: 
{beastie} @ FreeBaSeD-T430 > /home/beastie
 → sysctl -a | grep aslr
kern.elf32.aslr.stack: 1
kern.elf32.aslr.honor_sbrk: 0
kern.elf32.aslr.pie_enable: 1
kern.elf32.aslr.enable: 1
kern.elf64.aslr.stack: 1
kern.elf64.aslr.honor_sbrk: 0
kern.elf64.aslr.pie_enable: 1
kern.elf64.aslr.enable: 1
vm.aslr_restarts: 12732

edit.: But why you want to do that?
Click to expand...
But why you want to do that?

pointless technology

Performance brake
 
MrX86 said:
But why you want to do that?
Click to expand...
To spoil exploitability of "typical" bugs like buffer overflows, format-string attacks, etc. They will still happen and crash processes, but to actively exploit them (e.g. to escalate privileges), you typically need to know where to overwrite stuff, ASLR avoids that.
MrX86 said:
pointless technology
Click to expand...
No. It's a band-aid for sure, it doesn't fix security vulnerabilities, but it greatly reduces their impact.
MrX86 said:
Performance brake
Click to expand...
How do you get that idea? I really don't know how the actual addresses used in some virtual address space should ever affect performance....
 
  • Like
Reactions: cy@
ASLR implementation

can help

but I don't need that everywhere

it depends on the use of the system
 
Maybe you start by explaining how you think it hurts? (Spoiler: it doesn't, except with broken software)
 
zirias@ said:
To spoil exploitability of "typical" bugs like buffer overflows, format-string attacks, etc. They will still happen and crash processes, but to actively exploit them (e.g. to escalate privileges), you typically need to know where to overwrite stuff, ASLR avoids that.
Click to expand...
may be, never seen
to this I need this for a not internet based
server
 
the cpu must calculate this without performance loss ?
all applications support this ?

how good is the freebsd implementation

is there any experience ?

if yes why it has not been implemented before ?

i should feel safe if anything is randomized

so it comes out where i don't need it
 
BobSlacker said:
Put all that have value 1 in /etc/sysctl.conf with value 0:

Code: 
{beastie} @ FreeBaSeD-T430 > /home/beastie
 → sysctl -a | grep aslr
kern.elf32.aslr.stack: 1
kern.elf32.aslr.honor_sbrk: 0
kern.elf32.aslr.pie_enable: 1
kern.elf32.aslr.enable: 1
kern.elf64.aslr.stack: 1
kern.elf64.aslr.honor_sbrk: 0
kern.elf64.aslr.pie_enable: 1
kern.elf64.aslr.enable: 1
vm.aslr_restarts: 12732

edit.: But why you want to do that?
Click to expand...


now:

kern.elf32.aslr.stack: 0
kern.elf32.aslr.honor_sbrk: 0
kern.elf32.aslr.pie_enable: 0
kern.elf32.aslr.enable: 0
kern.elf64.aslr.stack: 0
kern.elf64.aslr.honor_sbrk: 0
kern.elf64.aslr.pie_enable: 0
kern.elf64.aslr.enable: 0
vm.aslr_restarts: 0


Thanks Bob....
 
MrX86 said:
the cpu must calculate this without performance loss ?
Click to expand...
ASLR means all segments, shared libs, stack, heap are loaded to random addresses. This is done once at startup (maybe, not sure about that, also with new page mappings, although this could create practical problems when e.g. a growing array needs contiguous addresses...). In any case, getting some random number from the entropy pool of the OS does not exactly consume performance. Really. Have fun trying to even measure it.

MrX86 said:
all applications support this ?
Click to expand...
No. Some make broken assumptions. There are ELF annotations to disable ASLR for specific applications for that reason. Still, applications NOT supporting it are technically broken.

MrX86 said:
how good is the freebsd implementation
Click to expand...
I don't know. But any implementation is "better" than doing nothing at all.

MrX86 said:
is there any experience ?

if yes why it has not been implemented before ?
Click to expand...
Seriously? Why didn't MS-DOS support preemptive multitasking?

MrX86 said:
i should feel safe if anything is randomized

so it comes out where i don't need it
Click to expand...
I really don't get this, sorry :oops:
 
zirias@ said:
Maybe you start by explaining how you think it hurts? (Spoiler: it doesn't, except with broken software)
Click to expand...

I wouldn't say broken. For example, CMUCL and old versions of SBCL (both Common Lisp implementations) had the heap fixed in a specific address at startup, and relied on no previous mapping from starting the binary clashing with it.

The reason for this is the NIL symbol, which is like C's NULL, but a real object with contents, so it cannot live at address 0 (because you can't write there at application startup). But if you put it on a variable address then every test (if ...) would take longer. It would be like asking C to put NULL at not the 0 address. Indirection, pulling in multiple words, trashing one more L1 cache line etc. pp. collapse of the known universe.

SBCL went with fixing this at a performance penalty. Dunno about CMUCL, but if they didn't then they need to have ASLR off.
 
MrX86 said:
the cpu must calculate this without performance loss ?
Click to expand...

There is no performance penalty at the system or CPU side. In rare cases such as I outlined it disables speed hacks in userland.

Linux tested the concept for us long enough, and it had applications sort themselves out long ago.
 
zirias@ said:
ASLR means all segments, shared libs, stack, heap are loaded to random addresses. This is done once at startup (maybe, not sure about that, also with new page mappings, although this could create practical problems when e.g. a growing array needs contiguous addresses...). In any case, getting some random number from the entropy pool of the OS does not exactly consume performance. Really. Have fun trying to even measure it.


No. Some make broken assumptions. There are ELF annotations to disable ASLR for specific applications for that reason. Still, applications NOT supporting it are technically broken.


I don't know. But any implementation is "better" than doing nothing at all.


Seriously? Why didn't MS-DOS support preemptive multitasking?


I really don't get this, sorry :oops:
Click to expand...

thank you for your feedback they take the time to check my criticism.
 
zirias@ said:
wise-guy-mode: in fact, C doesn't mandate NULL to be numerical 0 at all 🤡

But I see your point 😉
Click to expand...

Fair point, but NULL will always be constant, compiled into a C program, not adjusted every time at startup (like SBCL now does). So you don't need the indirection at every runtime access.

Also, a NULL at not-0 would also break with address randomization.
 
cracauer@ said:
There is no performance penalty at the system or CPU side. In rare cases such as I outlined it disables speed hacks in userland.

Linux tested the concept for us long enough, and it had applications sort themselves out long ago.
Click to expand...

is correct
 
cracauer@ said:
Fair point, but NULL will always be constant, compiled into a C program, not adjusted every time at startup (like SBCL now does). So you don't need the indirection at every runtime access.
Click to expand...
Of course, the clown face was there for a reason 😉

cracauer@ said:
Also, a NULL at not-0 would also break with address randomization.
Click to expand...
And of course again. NULL at some different address only makes sense on "bare metal" without virtual memory ... not sure it's a thing anywhere nowadays 😉

(edit: now really wondering what devel/cc65 is doing. At least on a C64, address 0 is pretty meaningful, it's the data direction register for the integrated processor port. But any other address of the 16bit address space can be used as well. Maybe I should check their code how they solved that ...)
 
and what about asm code on freebsd

pop and push opcodes with aslr

no problem ?
cracauer@ said:
Fair point, but NULL will always be constant, compiled into a C program, not adjusted every time at startup (like SBCL now does). So you don't need the indirection at every runtime access.

Also, a NULL at not-0 would also break with address randomization.
Click to expand...
 
stack pointer also ends up in random

i have no experience with that


I don't know, I'm asking if anything is known
 
MrX86 the language doesn't matter much here. What matters is "virtual memory", the address space your program sees is entirely virtual and "mapped" to physical addresses by the operating system (which also means, you have to request memory you want to use from the OS first).

When the stack is placed at a random address, of course the OS sets the stack pointer accordingly on context switch. As long as your code doesn't do weird stuff (like, loading the stack pointer with fixed values assuming a fixed layout), it will work.
 
You must log in or register to reply here.
Back
Top