Comment by inetknght
2 days ago
> Would be great if you report such remote code executions to the authors/Google. I am sure they handle CVEs etc.
I wasn't getting paid to fix their code, I have no interest in helping Google for free, and don't want to help Google.
> There has been a security audit like
A checkbox report from six years ago. That's ancient times at the pace that things are added to gRPC.
> Are you making shit up as you go?
No. This [0] repo I used to reproduce a stack smash issue before `main()`. I reported the issue here [1]. I don't get paid to fix Google's things and found a workaround for the purposes I needed.
[0]: https://github.com/keith-bennett-airmap/grpc-stacksmash
[1]: https://github.com/protocolbuffers/protobuf/issues/12732
> I can see various fuzzers in the code base so that claim is also unsubstantiated
Fuzzers are cool, but they don't cover the whole codebase.
> I wasn't getting paid to fix their code, I have no interest in helping Google for free, and don't want to help Google.
Extraordinary claims need extraordinary evidence. Software can be buggy, for sure, but as you yourself acknowledge, gRPC is widely deployed at many companies that do offer bug bounties. I won't be surprised if folks can occasionally find exploits in it, but if as you suggest it is so easily exploitable to get remote code execution, you in fact should be able to collect many $$$ from not just Google, but Apple, Microsoft, and many more companies who deploy gRPC services at scale. Hard to find a nicer attack target than a network facing library that you have a zero-day RCE for. (Protobuf is an even more popular target and used by virtually all Google services.)
https://bughunters.google.com
> No. This [0] repo I used to reproduce a stack smash issue before `main()`. I reported the issue here [1]. I don't get paid to fix Google's things and found a workaround for the purposes I needed.
As you have figured out yourself in the repo referred, the bug (not sure if exploitable or not) is from protobuf, a distinct library from gRPC, and appeared under certain compiler configurations. gRPC library does not even have a dependency on `libprotobuf`. It just happens to be the most popular format used jointly with gRPC. (It could be argued to be a bug in compiler conditions where abseil substitution of absl::string_view to std::string_view happens and is not fully compatible.)
Google also specifically pays for some open source project vulnerability reports (specifically covering Protobuf as an important target), so repeated claims of I am not getting paid otherwise I had dozens of exploits should be taken with a grain of salt and considered FUD: https://bughunters.google.com/about/rules/open-source/652133...
> Fuzzers are cool, but they don't cover the whole codebase.
You just went from the claim "they have no fuzzers or static analysis" to "fuzzers don't cover X". Of course, you cannot prove correctness by testing and fuzzing. Testing is not verification. Tests can only prove the existence of bugs, not their non-existence.
In any case, I would be really interested to see a comparable RPC stack that is close or more well-tested than gRPC...
> gRPC is widely deployed at many companies that do offer bug bounties
Ahh yeah, bug bounties. The things that are notoriously underpaid if paid at all. The things that require many hours/days/weeks of work for a "maybe" payoff.
I'm sorry but I don't like the risk of spending so much time for free or significantly discounted. My time is worth more than that.
If these companies really want to lean on shit software, then that's their business. But I neither support nor condone it.
> gRPC library does not even have a dependency on `libprotobuf`
I see this espoused a lot. Have you tried building gRPC? It requires protobuf to build...
> You just went from the claim "they have no fuzzers or static analysis" to "fuzzers don't cover X"
And it's amazing that both claims are true. You linked some page where some fuzzers were run. Nice! Those fuzzers aren't enabled in default tests. So `make test` doesn't run them. Moreover `make test` didn't find any issues and would take a while so I commented it out.
> I would be really interested to see a comparable RPC stack
This has been a call since forever. But "RPC" is very loosely defined.
Realistically, almost anything that can serialize to/from a file without relying on knowing the file size can be adapted to socket-based RPC. There's thousands of libraries which can do that.
> that is close or more well-tested than gRPC
I'd rather have an "RPC" whose design is both well-documented and clearly readable. That's definitely not gRPC. HTTP is fairly well-documented and many implementations are clearly readable. Message queues are too. Even databases are generally better documented and usable for RPC. Did you know that POSIX has a specification for RPC?
Good documentation and clearly readable means "well tested" comes with much lower costs.