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

51–60 of 74 posts

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

#51

Post by meowface »

ComodoHacker wrote: post #50

Am I understanding correctly that the author has scored a bounty of $10K? If yes, where did it come from in this case?

https://google.github.io/kctf/vrp.html

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.

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

#52

Post by jcims »

jxf wrote: post #38

I get that the terms of the contest stipulated payout limitations, but $10,000 really seems like chump change for this bug. Bypasses all protecting, executed arbitrary code. That's worth a lot in the right hands.

Imagine all of the chumps out there having sex for free when they could make good money at it.

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

#53

Post by scottlamb »

staticassertion wrote: post #49
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…

The vulnerability would be buried. Greg is extremely, consistently reluctant to issue CVEs without security engineers bending over backwards.

> The vulnerability would be buried. Greg is extremely, consistently reluctant to issue CVEs without security engineers bending over backwards.

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.

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

#55

Post by fulafel »

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…

Nitpick: CVE's don't have severities, and it's somewhat arbitrary if a CVE ID number gets assigned for a bug or not. They are basically just handles so that if there is one, people can use it to differentiate which potential vulnerability they are talking about.

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.

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

#57

Post by devwastaken »

fulafel wrote: post #12

Manual 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.…

Obligatory could this have been done in rust and work the same without the vulnerability? Or are there some problems that make it unreasonable to do?

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

#58

Post by smoldesu »

devwastaken wrote: post #57
fulafel wrote: post #12

Manual 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.…

Obligatory could this have been done in rust and work the same without the vulnerability? Or are there some problems that make it unreasonable to do?

There are very few things C can do that Rust can't, but there are lots of things you probably shouldn't use Rust for: this being one of them. On a purely speculative level though? Sure, it's totally possible as long as you're willing to break out a few unsafe blocks.

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

#59

Post by staticassertion »

scottlamb wrote: post #53
staticassertion wrote: post #49

Earlier quoted context omitted.

The vulnerability would be buried. Greg is extremely, consistently reluctant to issue CVEs without security engineers bending over backwards.

> The vulnerability would be buried. Greg is extremely, consistently reluctant to issue CVEs without security engineers bending over backwards. 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.

LTS is a noble effort but leaves quite a lot to be desired, and doesn't really change the fact that Greg (and others) have multiple decades of history hiding vulns and pushing back on CVEs.

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

#60

Post by OneLessThing »

tremon wrote: post #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?

Did this line get removed from the blog post?
Post reply on HN