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

41–50 of 74 posts

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

#41

Post by fouc »

EvanAnderson wrote: post #37
airstrike wrote: post #35

Earlier quoted context omitted.

I actually appreciate seeing someone draw something complex out on paper because it shows they care enough to make sure they get it right.

The old Microsoft "Behind the Code" video series always asked their guests (Microsoft employees who distinguished themselves with technical accomplishments in their careers) to draw and explain their favorite data structure. I loved that bit of the shows. (If you haven't seen them I would highly recommend them.)

Nice, seems like they can be found here: https://www.youtube.com/user/MicrosoftResearch/search?query=...

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

#42

Post by pjmlp »

nine_k wrote: post #40
pjmlp wrote: post #21

Earlier quoted context omitted.

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

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.

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

#43

Post by pjmlp »

vsareto wrote: post #31
josefx wrote: post #24

Earlier quoted context omitted.

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…

You're not just finding functions, but also how to affect memory, bypass security controls, and many other things to get a stable exploit 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

In general and not talking about the Linux kernel, you would be surprised how much enterprise code, written is C, is susceptible to basic buffer overflows from the 90s.

Specially because the people that wrote it use basic C coding patterns and tooling from the 90s.

Or do you think the 70% comes all from highly technically hard code to exploit?

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

#44

Post by queuebert »

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.

Don't forget to subtract the cost of your criminal trial defense.

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

#45

Post by markjdb »

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?

It depends on the bug. syzkaller does an excellent job finding race conditions, but it can be difficult to generate a reliable reproducer for them. It often succeeds nonetheless. In other cases there can be a wide gap between the proximate and root causes of a crash. For instance some system call bug might corrupt memory in a way that only results in a crash some time later, when some asynchronous task runs, in which case it's also difficult to find a reproducer. Sanitizers can help identify such bugs earlier and so reduce the amount of manual analysis needed in the absence of a reproducer.

I'm not sure what happened in this case. The linked report does indeed have an associated reproducer.

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

#46

Post by jeffbee »

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.

memcpy is the only defined way to type pun in C++. Anyone intentionally avoiding it probably has UB instead.

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

#48

Post by pjmlp »

jeffbee wrote: post #46
pjmlp wrote: post #42

Earlier quoted context omitted.

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

memcpy is the only defined way to type pun in C++. Anyone intentionally avoiding it probably has UB instead.

Starting with C++20, std::bit_cast is also an option.

https://en.cppreference.com/w/cpp/numeric/bit_cast

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

#49

Post by staticassertion »

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.
Post reply on HN