Didn't see a link to the fix. Here it is: https://github.com/torvalds/linux/commit/b29c457a65114359601...
CVE-2021-22555: Turning \x00\x00 into 10000$
11–20 of 74 posts
Re: CVE-2021-22555: Turning \x00\x00 into 10000$
#12Manual parsing of complex binary formats (in this case a netfilter control protocol) in hand rolled C code in ring 0. An approach from the innocent 1990's.
Quipping aside, an interesting thing is that this kind of thing used to be callable by root only and even in the early days of putting things behind more fine grained capabilities, CAP_NET_ADMIN probably wasn't taken very seriously as representing untrusted users. Which begs the question of whether it would be more secure to keep these things root-only and make people do the hard and dangerous part of untrusted input handling in userspace, where it's also easier (and not forbidden by kernel coding style rules...) to use safer PLT techniques to do it.
Re: CVE-2021-22555: Turning \x00\x00 into 10000$
#13Vulnerabilities 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!
> Vulnerabilities once you have access to the machine are not really worth spending time on
That's absolute nonsense. There's so many platforms, Android/iOS, where applications are compartmentalized: local privilege escalation (LPE) vulnerabilities is what enables a rogue application (or remote code execution into one, such as a browser/chat), into full control of the device and its data. Sometimes LPEs are needed to achieve some level of persistence. In VMs, a guest LPE is frequently needed to interface (and exploit) directly the emulated/paravirtualized devices and VM-escape into the host OS.
Yes, it is a big deal.
Re: CVE-2021-22555: Turning \x00\x00 into 10000$
#14I 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…
Yep, this is a big problem. In general non experts are impressed by laboriously refined exploits, not vulnerability discoveries, and even on HN a lot of people get those 2 concepts and terms mixed upwhich muddies the issue even more.
Re: CVE-2021-22555: Turning \x00\x00 into 10000$
#15Would 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 freeing , check that tag is still intact. This should detect if there was a write spanning multiple adjacent structs.
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?
Re: CVE-2021-22555: Turning \x00\x00 into 10000$
#16Vulnerabilities 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.
Re: CVE-2021-22555: Turning \x00\x00 into 10000$
#17> CVE-2021-22555: Turning \x00\x00 into 10000$
Re: CVE-2021-22555: Turning \x00\x00 into 10000$
#18> While the vulnerability was found by code auditing, it was also detected once by https://syzkaller.appspot.com/bug?id=a53b68e5178eec469534aca..., however not with a reproducible C code.
This made me pause. I had naively assumed (well, actually, never thought about it) that fuzzing would always expose a clear and obvious error path, but apparently there's a lot of manual digging required to find the error mode?
Re: CVE-2021-22555: Turning \x00\x00 into 10000$
#19I 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 should be at least as profitable (per hour) to find and fix kernel out of bound writes as writing full exploits. The risk is you’re doing legwork for bad actors. Of course the exploit is published after the fix, but not all devices are fixed by that time.
Re: CVE-2021-22555: Turning \x00\x00 into 10000$
#20> While the vulnerability was found by code auditing, it was also detected once by https://syzkaller.appspot.com/bug?id=a53b68e5178eec469534aca... , however not with a reproducible C code. This made me pause. I had naively assumed (well, actually, never thought about it) that fuzzing would always expose a clear and obvious error path, but apparently there's a lot of manual digging required to find the error mode?
Perhaps the difference between merely observing a crash while fuzzing and being able to exploit it for RCE or whatever?