@brnrd @pertho @saper @Gargron @keithzg

And jemalloc is starting to become friendlier to ASLR. So jemalloc + HardenedBSD = I'm in love!

I'd love to see the heap implementation be interchangeable at world compile time, like the work you (sp1l) did for #HardenedBSD with #LibreSSL.

I would like to see #OpenBSD's malloc imported in HardenedBSD along with Daniel Micay's HardenedMalloc.

#FreeBSD #infosec

@lattera @brnrd @pertho @saper @Gargron @keithzg ASLR is what we call in french « usine Γ  gazΒ Β», is an outdated concept, and not even fully protecting against ROP. Like canaries & NX bit in PMMU don’t protect 100% against stack and buffer overflows. I have found a simple 100% operationnal solution stopping these 3 problems just by slitghly modifying any microprocessor architecture. I also consider PMMU a outdated concept.

@stman @brnrd @pertho @saper @Gargron @keithzg

PaX ASLR and PaX NOEXEC changed forever how exploits are written. Now you must chain multiple vulnerabilities together to gain code execution. They can fully kill certain vulnerabilities and attackers must now pay much closer attention to both control and data flow.

@stman @brnrd @pertho @saper @Gargron @keithzg

The overarching goal of security is to raise the economic cost of a successful and reliable attack.

PaX ASLR and PaX NOExEC do that and with minuscule overhead on the part of the defender.

So, I wouldn't even come close to saying ASLR is an outdated concept.

@stman @brnrd @pertho @saper @Gargron @keithzg

Those who claim "ASLR is dead!" either:

1. Don't understand just how much ASLR (and its companion, NOEXEC) have changed exploitation.
2. Have an ulterior motive, a snakeoil sales pitch.
3. Don't actively do exploit dev.
4. Have bought the false narratives of university researchers simply looking for more grant money.
5. Don't fully understand what ASLR is meant to protect against.

@stman @brnrd @pertho @saper @Gargron @keithzg

Wouldn't that require access to the binary along with its dependent shared libraries or local access? ASLR isn't meant to protect such cases.

@stman @brnrd @pertho @saper @Gargron @keithzg

I just recognized that I might have sounded a bit harsh. I apologize if I did.

I just get annoyed with the "ASLR is dead" fallacy. It does exactly what it was meant to do. I think the non-exploit dev (just regular tech folks) have put ASLR on a pedestal it doesn't deserve, which has now caused a general "ASLR is dead" line of thinking.

ASLR remains strong for what it was designed and architected to do: protect purely remote attacks.

@lattera @brnrd @pertho @saper @Gargron @keithzg I should have phrased my point differently. As it is a complex matter, and as I want to have an honnest discussion with you, let me prepare a text or an audio file explaining my point. To me these concepts are outdated, we can do better, way much better. Will be back to you this evening at tomorrow at last, to precisely explain my point. The only rule I’m asking you for this discussion

@stman @brnrd @pertho @saper @Gargron @keithzg Sure. Textual medium is preferred for me.

I agree we can do better. PaX RAP is the best solution. However, it requires a GPLv3 toolchain, is patented, and RAP with the paid grsecurity patch kills all forms of ROP, JOP, etc.

The rest of the non-Windows world will likely use llvm's CFI and SafeStack to above and beyond ASLR. Which is what we're doing in HardenedBSD. :)


@lattera @brnrd @pertho @saper @Gargron @keithzg architectures.

Now I think that the lesson is learned.

By the way, the implementation of my solution for a 68k clone on FPGA (representing about 10000 to 20000 lines of VHDL code) should fit in about 500 lines of additionnal VHDL code, 1000 lines max, according to me. This is what I call a simple and efficient solution. How many lines of C code does all those software equivalent

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!