2 ms·
> If that's something that's still interesting to you, check out http://microcorruption.com http://microcorruption.com. I was very excited to see that for just
by haberman 13y ago
> If that's something that's still interesting to you, check out http://microcorruption.com http://microcorruption.com.
I was very excited to see that for just that reason. :) I think I peaked at #24 on the day it was announced, but I'm sure I've slipped quite a bit since then.
Fundamentals are important; agreed, but the difference between knowing the theory of buffer overflows and having actually exploited one is a huge to me. Now I can say that I have actually done that, thanks to you having packaged everything up so nicely on microcorruption.com, but even that isn't 100% of the experience I would like to have, because the environment is a lot different than what I program on day-to-day.
For example, I know that I shouldn't map any memory wx (and I explained this rule in my article about JITs: http://blog.reverberate.org/2012/12/hello-jit-world-joy-of-simple-jits.html http://blog.reverberate.org/2012/12/hello-jit-world-joy-of-s...), but I don't really know why. I don't actually know what an attack would look like where having wx memory around makes an exploit easier.
- pbsd 13y agoIf you can control what gets written to the wx memory, then all you have to do as an attacker is rewrite a function pointer or return address to that memory. Better yet, if you can rewrite a return address, you can "return" to a read call (or some fancier ROP chain) that will read the rest of your shellcode into the wx memory and execute it. In either case, having that kind of memory around can only make things easier for an attacker, while by itself not being exactly a vulnerability.