Such vuln could sell for much more.
2 - grep for string, arrays and memory functions from C
3 - even if you are not a security expert, maybe you will be able to find out some possibilities
I have written a substantial enough C codebase used in the real world that uses C string handling functions. I did that because the codebase needed zero dependencies other than libc. Yet as far as anyone who's looked at the code can tell, there are no vulnerabilities because I learned how to use realloc() and grow the allocation if needed before calling the string handling functions. It's not hard; it's just busywork.
I kinda feel like you the other poster suggesting to just search source code learned basic buffer overflows from the 90s and called it a day
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".
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 the vulnerability, and immediately report it to the kernel security team, would it be treated with the same level of seriousness? Could a CVE with the same severity be issued, or would there be arguments over whether or not the bug is exploitable?
From https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-... I'd paraphrase his philosophy as kernel developers should fix bugs (without requiring they be security-related or worrying about CVE assignment), users should run a recent stable/long-term kernel.
There are some linked things (called CWE, CVSS, and probably more) that links to CVE IDs and there's some scoring but it's less widely used & more contested as a system.
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?
I'm not sure what happened in this case. The linked report does indeed have an associated reproducer.
[0] https://github.com/google/security-research/security/advisor...
Are there some tools that help this kind of thought process? Or do you have to use drawing primitives - rectangles, etc to do it?
I occasionally write it out even if its dead simple if else logic but nested.
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!
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.
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.
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.
I'm not sure you understand the actual severity of this exploit. I personally am not going out of my way to check if any of my servers are patched for this or verify my kernels are up to date.
This exploit doesn't impact me, or most people. Why? It requires CAP_NET_ADMIN to exploit that. Who has CAP_NET_ADMIN? root, root in a container, or a machine with unprivileged user namespaces.
Many kernels turn off unprivileged user namespaces still, and even with them enabled, it also requires running untrusted binaries on your machine.
This isn't remotely exploitable. I don't run untrusted binaries or containers on any of my machines. I feel pretty safe.
It also doesn't "bypass all protections". If you run a container where the user doesn't have CAP_NET_ADMIN, they won't be able to exploit this. If you turn off unprivileged user namespaces, an unprivileged user on the host won't be able to get CAP_NET_ADMIN to exploit this.
Why do you think this is worth a lot? What are "the right hands" and what could they do with this?
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?
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.
That's a massive difference since CAP_NET_ADMIN is somewhat rare (i.e. you can't get it from a random android app, but a random android app could have exploited dirty cow)
Looks like a Kubernetes-specific CTF sponsored by Google. And, yes, they won $10k, but donated it to charity, in which case Google matches the donation (https://g.co/vrp):
>We understand that some of you are not interested in money. We offer the option to donate your reward to an established charity. If you do so, we will double your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
So they won $20k for charity, essentially.
I can hardly imagine how much time and effort someone must put into these kinds of things.
https://github.com/google/security-research/security/advisor...
