keithzg is a user on mastodon.club. You can follow them or interact with them if you have an account anywhere in the fediverse.
keithzg @keithzg

@gargron The answer is "using Ruby", obviously!

(sorry)

@keithzg The answer is malloc's overallocation default due to RedHat's preferences and malloc's failure to return free empty heaps as a performance precaution

This is why you don't get memory issues when using jemalloc instead of glibc's malloc

@gargron Yeah to be honest I did read through it and found it very interesting, especially how apparently patching a malloc_trim() call into Ruby 2.6 actually *improved performance* in addition to reducing memory consumption.

Also very interesting, as you point out, is the somewhat warping influence Red Hat has on the default state and configuration of the underlying software stack.

@saper

@gargron

Hey now, surely we can come together and all agree that Unix-style OSes are far better at this than Windows, for which similar situations tend to break down into "where did this memory go and who even requested it? Literally no way to ever tell, I guess just reboot periodically!"

@keithzg @Gargron I am not sure I know enough about Windows memory allocator here.

From what I see this is a remnant from brk()/sbrk()-style memory allocation, which is deeply rooted in UNIX history and memory segmentation.

Paging is clearly more difficult to manage.

@saper @Gargron @keithzg I wonder how this compares with the BSDs.

@brnrd @saper @Gargron @keithzg Yeah FreeBSD has had jemalloc for years. I wonder if #OpenBSD uses something similar?

@brynet @pertho @brnrd @saper @Gargron @keithzg openbsd's malloc does not have the problem of hanging on to memory pages, it's returns pages to the os pretty aggressively

@pertho @brnrd @saper @Gargron @keithzg

It's seems: no...
but if you read manpage about jemalloc and OpenBSD's malloc, it's seems there are similars functions on standard API.

As seen, history section:
"The reallocarray() function appeared in OpenBSD 5.6. The recallocarray() function appeared in OpenBSD 6.1. The freezero() function appeared in OpenBSD 6.2. The aligned_alloc() function appeared in OpenBSD 6.5."

jemalloc.net/jemalloc.3.html
man.openbsd.org/malloc

@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.

@lattera @brnrd @pertho @saper @Gargron @keithzg Will answer you later on (I am at FSiC2019 right now), the topic is passionate.

@lattera @brnrd @pertho @saper @Gargron @keithzg it prevents an attacker from easily pre-build a gadget amphabet before the ROP attack.

@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.

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

In pipacs' original ASLR paper, he states that ASLR can be defeated by information leaks. So that's a known issue, even from the beginning.

@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 When I used to discuss with RMS about my research a few years ago on the topic of the Stack, Buffer, Integer overflow familly, I still had not a clean fully operationnal solution, and the ones I had found were not solving ROP either. The discussion with RMS was centered on two things :

• How hard is it to have GCC handling a new instruction set necessary to implement my solutions ?

@lattera @brnrd @pertho @saper @Gargron @keithzg

• Where does this family of breaches where coming from ? RMS was saying it was compiler’s and C language architectures fault, while I was pushing the idea that it was a microprocessor architectual issue.

The fact that I found a solution that provenly solves overflow family and ROP just by slightly modifying the processor architecture, adding a few new blocks, and preserving

@lattera @brnrd @pertho @saper @Gargron @keithzg compatibility with existing instructions sets, making it usable without modifying compilers profiles for all know’ processors architectures, prooved that RMS was wrong in his understanding of the issue.

@lattera @brnrd @pertho @saper @Gargron @keithzg I have to check by the way if it works for JOP... I did not even checked this yet. But even if it is not, following the same design principles I used, it should not be a big deal.

Will be back later. I am exhausted after the FSiC 2019 conference. Need to sleep a little bit.

@lattera @brnrd @pertho @saper @Gargron @keithzg My return of experience with these researches is that when some issues are the consequence of the microprocessor architectural choices, trying to solve them by software at 100% is not always possible, and when possible, can be quite a mess, complex, or not solving it 100%.

I was prooven right with all the recent micropricessors architectural security breaches (About 30 published in 2

@lattera @brnrd @pertho @saper @Gargron @keithzg years) and only 1/3 of them patched 100% by microcode update or kernel patches, 2/3 of those Spectre, Meltdown, ASLR cache attacks, side channel cache attacks, etc... were declated unpatchable by microcode update or kernel software patch.

I consider that it is exactly the same for the overflow family and ROP. But by that time, nobody was daring to point finger at processors

@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

@lattera @brnrd @pertho @saper @Gargron @keithzg solution, that don’t fix those issues at 100% , represents ? I’m sure it’s way much more than 1000 lines of C code. By the way, I would be interested to know an approximate lines count.

Will be back later,

Kind regards,

Stman

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

Regarding RMS: I'm not that big a fan of him.

Regarding cache and micro-architectural attacks: ASLR wasn't meant to protect against them. As such, bypassing ASLR through them is moot point.

Regarding a hardware-based solution: have you looked at the CHERI project from the University of Cambridge? I really like the work they're doing, though I doubt it'll be impactful for another decade or two (or three).

@stman @lattera @brnrd @pertho @Gargron @keithzg amazed how one little remark sparked such a discussion! thanks! make sure you post a pointer here once you are ready...

@saper @lattera @brnrd @pertho @Gargron @keithzg Have you heard about cyber-geopolitics and its secret wars ? According to you, what game all military of the world are playing with technology and the current cyberspace ? An universal love story for global peace or a wacky race to find as much ways & tricks as possible to fuck their competitors & cyber-dominate them ?

@saper @lattera @brnrd @pertho @Gargron @keithzg In all this mess, there are still a very few crypto-anarchists like me who think evrrybody has the right to understand these secret wars, what strings each waring parties are pulling, etc...

@saper @lattera @brnrd @pertho @Gargron @keithzg To help other understanding these stupid games that lead nowhere except global war, I have been studying cyber-power genesis, in all know technological layers. My studies are aiming to represent the cyber-power model of the current cyberspace with all its technological layers.

@saper @lattera @brnrd @pertho @Gargron @keithzg My main discovery is that it’s the architectural choices, in all technological layers, that generate and caracterize cyber-powers.

Technological layers of a PC is architectured as a stack. According to you, what is the base if this stack, its first element ?

According to you, what is the element in this stack that generate most cyber-powers and the most important ones ?

@saper @lattera @brnrd @pertho @Gargron @keithzg The first elements if the stack (low level layers) , or the last ones (top level layers) ?

Once you give the right answers to these questions, you will understand my point better.

@lattera @brnrd @pertho @saper @Gargron @keithzg is ethics and honnesty in the technical debate. Kind regards, Frederic.

@lattera @brnrd @pertho @saper @Gargron @keithzg By the mean time I prepare my answer, I have a question for you to : According to you, why did these issues were not solved at 100% ? Knowing that it took me only 6 month of work to imagine my solution to all those issues at once, thinking out of the box, at processor architecture level.

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

Do you have a formal whitepaper in English for your solution? I'd be more than happy to read it. :)