Comment by tgma
2 days ago
> I have personally found several fuckups in gRPC and protobuf code resulting in application crashes or risks of remote code execution.
Would be great if you report such remote code executions to the authors/Google. I am sure they handle CVEs etc. There has been a security audit like https://github.com/grpc/grpc/tree/master/doc/grpc_security_a...
> there aren't sanitizer builds nor fuzzing regime nor static analysis running against new commits last time I checked.
Are you making shit up as you go? I randomly picked a recently merged commit and this is the list of test suites ran on the pull request. As far as I recall, this has been the practice for at least 8 years+ (note the MSAN, ASAN, TSAN etc.)
I can see various fuzzers in the code base so that claim is also unsubstantiated https://github.com/grpc/grpc/tree/f5c26aec2904fddffb70471cbc...
Android (Internal CI) Kokoro build finished
Basic Tests C Windows Kokoro build finished
Basic Tests C# Linux Kokoro build finished
Basic Tests C# MacOS Kokoro build finished
Basic Tests C# Windows Kokoro build finished
Basic Tests C++ iOS Kokoro build finished
Basic Tests C/C++ Linux [Build Only] Kokoro build finished
Basic Tests ObjC Examples Kokoro build finished
Basic Tests ObjC iOS Kokoro build finished
Basic Tests PHP Linux Kokoro build finished
Basic Tests PHP MacOS Kokoro build finished
Basic Tests Python Linux Kokoro build finished
Basic Tests Python MacOS Kokoro build finished
Bazel Basic Tests for Python (Local) Kokoro build finished
Bazel Basic build for C/C++ Kokoro build finished
Bazel C/C++ Opt MacOS Kokoro build finished
Bazel RBE ASAN C/C++ Kokoro build finished
Bazel RBE Build Tests Kokoro build finished
Bazel RBE Debug C/C++ Kokoro build finished
Bazel RBE MSAN C/C++ Kokoro build finished
Bazel RBE Opt C/C++ Kokoro build finished
Bazel RBE TSAN C/C++ Kokoro build finished
Bazel RBE Thready-TSAN C/C++ Kokoro build finished
Bazel RBE UBSAN C/C++ Kokoro build finished
Bazel RBE Windows Opt C/C++ Kokoro build finished
Bloat Diff Kokoro build finished
Bloat Difference Bloat Difference
Clang Tidy (internal CI) Kokoro build finished
Distribution Tests C# Linux Kokoro build finished
Distribution Tests C# MacOS Kokoro build finished
Distribution Tests C# Windows Kokoro build finished
Distribution Tests Linux (standalone subset) Kokoro build finished
Distribution Tests PHP Linux Kokoro build finished
Distribution Tests PHP MacOS Kokoro build finished
Distribution Tests Python Linux Arm64 Kokoro build finished
Distribution Tests Ruby MacOS Kokoro build finished
Distribution Tests Windows (standalone subset) Kokoro build finished
EasyCLA EasyCLA check passed. You are authorized to contribute.
Grpc Examples Tests CPP Kokoro build finished
Memory Difference Memory Difference
Memory Usage Diff Kokoro build finished
Mergeable Mergeable Run has been Completed!
Migration Test MacOS Sonoma Kokoro build finished
ObjC Bazel Test Kokoro build finished
Portability Tests Linux [Build Only] (internal CI) Kokoro build finished
Portability Tests Windows [Build Only] (internal CI) Kokoro build finished
Sanity Checks (internal CI) Kokoro build finished
Tooling Tests Python Linux Kokoro build finished
Windows clang-cl with strict warnings [Build Only] Kokoro build finished
Interesting discussion. My current goal isn’t to replace gRPC but to offer a lighter option for simple real-time apps. I’ll keep following the thread; the security links are useful, thanks.
> 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.