Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CVE-2021-22555: Turning \x00\x00 into 10000$

google.github.io

Post reply on HN
Print view View original

21–30 of 74 posts

Re: CVE-2021-22555: Turning \x00\x00 into 10000$

#21

Post by pjmlp »

joosters wrote: post #7

I wonder how these vulnerabilities would be treated if the researchers didn't bother to find an exploit for them? The description of the exploit is so detailed that it gives the impression that discovering the original vulnerability was fairly quick and simple, and the real work is in building a functioning exploit to wriggle through the discovered kernel flaw. If the researchers were to just stop once they discover…

It was, the first step to find out bugs in C (and C++) code always starts the same way "...inspired me to grep for memcpy() and memset() in the Netfilter code. This led me to some buggy code.".

Re: CVE-2021-22555: Turning \x00\x00 into 10000$

#24

Post by josefx »

vsareto wrote: post #3

I'll never not be impressed by the people who can find stuff like this

Open C source file, read five minutes, done. The existence of C style strings by itself already guarantees that any C code will be 50% memory access exploits. Sadly instead of adopting one of hundreds sane string types that have been around as long as C if not longer the C standards committee only did the the C equivalent of my_sql_real_escape_string by introducing dozens of overloads that let you specify a "string size" yourself, without any ability to ensure that the provided size is correct. The only good thing about that is that they cannot mess up anything else while they work on the C standard.

Re: CVE-2021-22555: Turning \x00\x00 into 10000$

#25

Post by rocqua »

fulafel wrote: post #16
bullen wrote: post #5

Vulnerabilities once you have access to the machine are not really worth spending time on because servers should rely on shell hardening and clients should not be trusted anyway. What we need is ways to avoid the kernel for networking memory, I figured Oracle would have realized this for Java by now but they are dragging their feet!

What do you mean by "shell hardening"? In general the shell is not really a security critical component that would give big payoffs to harden.

I presume he meant "defend the perimteter, and they never get execution, so there is no need to defend the inside against privilege escalation".

The opposing line of thought is defense in depth. The idea being that "a hard shell but soft and mushy on the inside" is a fragile setup and only needs one thing to go wrong.

Re: CVE-2021-22555: Turning \x00\x00 into 10000$

#26

Post by saagarjha »

rossmohax wrote: post #15

Would following steps prevent this exploits and if yes, why they were not implemented still? 1. When spraying, they make use of the fact that same arena is used for all struct of a similar sizes. This allows them to fill holes in arenas with arbitrary data, creating fake structs. Why not have arena per struct or at least per subsystem? 2. Have some secret tag stored before each struct allocated in the arena. When fre…

> 1. When spraying, they make use of the fact that same arena is used for all struct of a similar sizes. This allows them to fill holes in arenas with arbitrary data, creating fake structs. Why not have arena per struct or at least per subsystem?

This would help, but it's hard to do for C: there's no type information when you do a malloc. XNU has a lot of C++ code in it that just (iOS 15) got separated kalloc heaps, so it's certainly something that can be done, but I'm not sure if Linux can adopt this easily.

> 2. Have some secret tag stored before each struct allocated in the arena. When freeing , check that tag is still intact. This should detect if there was a write spanning multiple adjacent structs.

I'm not familiar with kernel allocator hardening, but the post mentions some kind of freelist protections. In general, you can detect some heap corruptions, but not all of them; the better you get the worse performance you have, usually.

> 3. I didn't quite understand how they managed to create malicious release function. They have control over buffer where they can write code, but memory page containing that buffer isn't executable, right?

No new code is introduced, the function pointer is pointed at a JOP chain.

Re: CVE-2021-22555: Turning \x00\x00 into 10000$

#28

Post by ghosty141 »

josefx wrote: post #24
vsareto wrote: post #3

I'll never not be impressed by the people who can find stuff like this

Open C source file, read five minutes, done. The existence of C style strings by itself already guarantees that any C code will be 50% memory access exploits. Sadly instead of adopting one of hundreds sane string types that have been around as long as C if not longer the C standards committee only did the the C equivalent of my_sql_real_escape_string by introducing dozens of overloads that let you specify a "string s…

>read five minutes, done.

I mean it's obviously harder... I agree with the point you're making but finding an exploit like this is way harder than just "reading the source for 5 minutes".

Re: CVE-2021-22555: Turning \x00\x00 into 10000$

#29

Post by jcims »

goodpoint wrote: post #23
vsareto wrote: post #3

I'll never not be impressed by the people who can find stuff like this

Find stuff and give it away for very little money. Such vuln could sell for much more.

The access I have at work is extremely valuable in that same market. Should I sell that too?
Post reply on HN