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

61–70 of 74 posts

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

#61

Post by steveklabnik »

smoldesu wrote: post #58
devwastaken wrote: post #57

Earlier quoted context omitted.

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.

Why is Rust a "shouldn't" here? (And usually, parsing doesn't require any unsafe blocks, though it's not 100% clear to me exactly if this would or would not require it if things were written in Rust. It also depends on how much is... it's not a simple yes or no, which is one reason why I am curious about your opinion.)

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

#62

Post by tremon »

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

Sorry, it's from [0] linked further down in the comments. I didn't notice that when posting, or I would have made my comment a reply to that post [1].

[0] https://github.com/google/security-research/security/advisor...

[1] https://news.ycombinator.com/item?id=27842381

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

#63

Post by TheDong »

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.

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

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?

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

#64

Post by TheDong »

instance wrote: post #10

Is it just me, or is this is super similar to Dirty Cow [0] in terms of severity? Insane find!! [0]: https://en.wikipedia.org/wiki/Dirty_COW

iiuc dirty cow did not require CAP_NET_ADMIN to be exploited, and this one does.

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)

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

#65

Post by ghoward »

pjmlp wrote: post #22
vsareto wrote: post #3

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

1 - access to source code 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

This is entirely reductive.

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.

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

#66

Post by agent327 »

pjmlp wrote: post #42
nine_k wrote: post #40

Earlier quoted context omitted.

Does C++ code even use memcpy these days? A honest question.

Surely. It is part of ISO C++, and not everyone agrees with C++ safe coding practices.

In practice it's much easier to use assignment or copy construction, thus avoiding the dangerous memcpy. Same goes for those memsets and bzero's beloved of C-programmers: just make the class do it for you; it always works, cannot be forgotten, cannot be done wrong, and is just much easier to begin with.

Or, if you have a C-struct you need to interface with, just declare it as 'foo myfoo = {0};'. That also zero's out the whole thing, and the compiler won't get the size wrong.

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

#67

Post by yjftsjthsd-h »

jeffbee wrote: post #47

Our regular reminder that the union of lifetimes of all known kernel exploits covers the entire history of Linux. There has never been a time during which your Linux systems were not vulnerable to takeover, somehow.

They're computers that are powered on, so yes, they have vulnerabilities. Do you have a point?

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

#68

Post by Seirdy »

steveklabnik wrote: post #61
smoldesu wrote: post #58

Earlier quoted context omitted.

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.

Why is Rust a "shouldn't" here? (And usually, parsing doesn't require any unsafe blocks, though it's not 100% clear to me exactly if this would or would not require it if things were written in Rust. It also depends on how much is... it's not a simple yes or no, which is one reason why I am curious about your opinion.)

I'd imagine that portability along with avoiding the need to add a significant dependency to the kernel's core toolchain (rustc, llvm) are two reasons. Rust's involvement in the kernel is mostly relegated to less-essential modules for a reason.

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

#69

Post by pjmlp »

ghoward wrote: post #65
pjmlp wrote: post #22

Earlier quoted context omitted.

1 - access to source code 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

This is entirely reductive. 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…

Has the code been fuzzed and subject to static analysis as well?

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

#70

Post by pjmlp »

agent327 wrote: post #66
pjmlp wrote: post #42

Earlier quoted context omitted.

Surely. It is part of ISO C++, and not everyone agrees with C++ safe coding practices.

In practice it's much easier to use assignment or copy construction, thus avoiding the dangerous memcpy. Same goes for those memsets and bzero's beloved of C-programmers: just make the class do it for you; it always works, cannot be forgotten, cannot be done wrong, and is just much easier to begin with. Or, if you have a C-struct you need to interface with, just declare it as 'foo myfoo = {0};'. That also zero's out…

I fully agree.
Post reply on HN