Solved Address Space Layout Randomization (ASLR)

Assembler also looks up symbols the same way C code does - adjusted for actual mapping location of the executable.

Unless you write things in a hex editor you should be fine.
 
OK thanks
zirias@ said:
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.
Click to expand...
 
MrX86 said:
i like to write in asm
Click to expand...
ASLR is not posing any obstacle with that. You are controlling the the code, you have many ways to determine your stack address if needed (as simple as use the %sp value).

ASLR is a mechanism to create obstacle for an exploit by introducing certain amount of entropy in virtual space of the process. It's not bulletproof (many bugs in programs pave a way to leak addresses and hence remove the entropy altogether), easily bruteforceable in 32b process but still make sense to use it. If can reduce the usability of the attack vector at really no performance hit.
 
MrX86 said:
the cpu must calculate this without performance loss ?
[...]
Click to expand...
The first mainstream OS that supported ASLR - Address space layout randomization - Wikipedia - by default was OpenBSD in 2003: ASLR - OpenBSD

Various studies conclude that performance penalties of ASLR—if at all measurable consistantly—are outweighed by its advantages:
  1. Performance and Entropy of Various ASLR Implementations by John Detter, Riccardo Mutschlechner - 2015 [pdf]
  2. How Much Does Memory Layout Impact Performance? A Wide Study by Augusto Born de Oliveira Jean-Christophe Petkovich
    Sebastian Fischmeister - 2014 [pdf]
From #1 (in 2015):
Overall, our findings and experiments supported our initial hypothesis that ASLR adds significant security with very
minimal performance impact. The addition of ASLR helps slow down attackers at a minimal cost, and thus, it is
definitely a feature that should be implemented in a secure operating system. FreeBSD’s main branch currently
does not have any support for ASLR. We believe that FreeBSD would gain a considerable amount of security by
adding ASLR support.
Click to expand...
 
Yep. The actual cost of ASLR is so small, it's most likely out of the "measurable" area. And it can be disabled per executable, IF necessary.

Just keep in mind that ASLR doesn't "solve" any security issue, it's more like a band aid: it "covers" vulnerabilities as it gives a good chance that actual exploits fail.

Also keep in mind that multiple "lines of defense" are good practice in (computer) security. ASLR is just one of them. Although it can't solve the problem, it mitigates the impact.
 
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...
Actually, I don't want to cater for buffer overflows, format-string attacks etc. on my computers. Neither do I want to afford crashing processes. I'd rather suggest these should be fixed.
In any case, converting the memory layout into proper white noise so nobody gets a clue on how things might actually interplay, since the end user does not have a "need to know" anyway, and meanwhile still having crashing processes, that does not seem to comply with either of two software quality levels.(*)

(*)
interplanetary: you trust your life on it
interstellar: you trust your grandchildren's life on it
(because that's what it all was about originally)
 
PMc, a mitigation avoids successful exploits of yet unknown flaws. To fix errors, they must be known first. This is no "either or", you do both of course. Repeating myself: Also keep in mind that multiple "lines of defense" are good practice in (computer) security.

Sure you can have a different opinion than most of the industry including security reasearchers. It just probably won't convince too many peole...
 
PMc said:
..., that does not seem to comply with either of two software quality levels.(*)

(*)
interplanetary: you trust your life on it
interstellar: you trust your grandchildren's life on it
(because that's what it all was about originally)
Click to expand...
I ask myself what the requiring ingredients might be to be able writing such lyrics?
Does that esoteric got some name?
 
question:

since when was or is ASLR enabled in FreeBSD for the 32bit x86
already enabled ?
 
MrX86
enabled features are published in the FreeBSD Release Notes.
I suggest start reading yourself.

Also note that "question:" is redundant with "?"
 
zirias@ said:
PMc, a mitigation avoids successful exploits of yet unknown flaws. To fix errors, they must be known first. This is no "either or", you do both of course. Repeating myself: Also keep in mind that multiple "lines of defense" are good practice in (computer) security.
Click to expand...
I think I get it: there is nothing gonna be fixed because there is not even known what should be fixed. Nevertheless there is security by obscurity needed as a "line of defence". Now, defence implies war, and, once upon a time we were hippies and we had figured that there is no point in making war.
So, what is happening now, is...
zirias@ said:
Sure you can have a different opinion than most of the industry including security reasearchers. It just probably won't convince too many peole...
Click to expand...

... we bring along so-called "researchers" who explain to us that we have to go to war. Okay so far, uncle Sam needs you - but, I wouldn't call that "engineering".
And another interesting part is, this works quite the same as the war against nature, or the war against Russia. (Only with these we know who makes the money.)
 
zirias@ said:
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.
Click to expand...
Not just stack entropy but shared library entropy. Shared libraries could be placed anywhere in the virtual address space when ASLR is enabled. Otherwise binaries are always loaded at the same virtual address.
 
  • Like
Reactions: mer
getopt said:
I ask myself what the requiring ingredients might be to be able writing such lyrics?
Does that esoteric got some name?
Click to expand...
Yeah. Somebody killed JFK. Otherwise we would have a Mars colony for twenty years already. But some people were wise enough to understand that waging war in all corners of this planet brings in a lot more money.
Which side are You on?
 
Ok, I'll skip over the "wat"-inducing weirdness ...

But one thing must be corrected: ASLR is not "security by obscurity".

The term "security by obscurity" is used for attempted mitigations by just "obscuring" things, in the hope the attacker won't understand. A super stupid example could be a password stored in javascript source, but rot13-"encrypted". Or running some insecure service, but just using a non-standard port for it. In a nutshell, the term is used for mitigations that just don't work because they can easily be circumvented once understood. So, a key property of "security by obscurity" is keeping the actual method "secret".

ASLR on the other hand is a mitigation that works. Any attacker can have a look at how it works and still not circumvent it. For the kind of attacks it mitigates, the attacker needs to know in advance where to e.g. overwrite things, where to jump to, etc. This is just impossible in presence of ASLR. And the great thing about it: in contrast to some other mitigations (like e.g. disabling hyperthreading to avoid side-channel attacks), it costs close to nothing.

cy@ of course there's more to it, this was just a direct response to something specifically mentioning "stack entropy" 😉
 
PMc said:
Yeah. Somebody killed JFK. Otherwise we would have a Mars colony for twenty years already.
Click to expand...
To come along with this where talk is about ASLR it must be induced by some ingredients that may got consumed overdosed.

If you need to talk on this further I suggest doing this in your garden if there is no keyboard around. :)
 
PMc said:
Actually, I don't want to cater for buffer overflows, format-string attacks etc. on my computers. Neither do I want to afford crashing processes. I'd rather suggest these should be fixed.
In any case, converting the memory layout into proper white noise so nobody gets a clue on how things might actually interplay, since the end user does not have a "need to know" anyway, and meanwhile still having crashing processes, that does not seem to comply with either of two software quality levels.(*)

(*)
interplanetary: you trust your life on it
interstellar: you trust your grandchildren's life on it
(because that's what it all was about originally)
Click to expand...
I don't understand a word you say

I guess you have deceived me in the forum
 
You must log in or register to reply here.
Back
Top