{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
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?
But why you want to do that?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?
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.But why you want to do that?
No. It's a band-aid for sure, it doesn't fix security vulnerabilities, but it greatly reduces their impact.pointless technology
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....Performance brake
Without reading it, I can tell you one thing: Without ASLR, there is exactly NO "stack entropy", as it has a fixed place in virtual address space.
may be, never seenTo 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.
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?
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.the cpu must calculate this without performance loss ?
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.all applications support this ?
I don't know. But any implementation is "better" than doing nothing at all.how good is the freebsd implementation
Seriously? Why didn't MS-DOS support preemptive multitasking?is there any experience ?
if yes why it has not been implemented before ?
I really don't get this, sorryi should feel safe if anything is randomized
so it comes out where i don't need it
Maybe you start by explaining how you think it hurts? (Spoiler: it doesn't, except with broken software)
the cpu must calculate this without performance loss ?
wise-guy-mode: in fact, C doesn't mandate NULL to be numerical 0 at allIt would be like asking C to put NULL at not the 0 address.
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
wise-guy-mode: in fact, C doesn't mandate NULL to be numerical 0 at all
But I see your point
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.
Of course, the clown face was there for a reasonFair 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.
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 nowadaysAlso, a NULL at not-0 would also break with address randomization.
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.
They just use the stack pointer. Why do you think this should ever be a problem?and what about asm code on freebsd
pop and push opcodes with aslr
no problem ?