Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
There is, it'll build a few fuzzers hitting different areas[0]. The important function in many of those `.c` files is `FuzzerTestOneInput` which is effectively the entrypoint for a single fuzz test.
Taking a look at x509.c[1] which I believe is the most likely to be able to reach the punnycode parser. (I am not at all familiar with the codebase). You can see that the OpenSSL fuzzer is basically doing a holistic fuzz, that is its just invoking key entrypoints that in theory can exercise all the rest of the functionality with the correct inputs.
Hanno's fuzzer on the other hand, is explicitly only testing the `ossl_punnycode_decode` function[3].
Given the breadth of the fuzzer, I think its very possible OSS-Fuzz just didn't hit it.
[0] https://github.com/openssl/openssl/blob/master/fuzz/
[1] https://github.com/openssl/openssl/blob/master/fuzz/x509.c
[2] https://twitter.com/hanno/status/1587775675397726209/photo/2
> Large web companies like Google implement their own encryption stack anyway.
Google uses BoringSSL[1], which is another OpenSSL fork. I believe AWS uses a mix of OpenSSL and Boring SSL (someone can correct me!).
So it's "their own encryption stack," but that stack is at least originally comprised of OpenSSL's code. They've probably done an admirable job of refactoring it, but API and ABI constraints still apply (it's very hard to change the massive body of existing code that assumes OpenSSL's APIs).
[1]: https://boringssl.googlesource.com/boringssl/
I find it odd that Google's oss-fuzz didn't find this a long time ago.
https://github.com/google/oss-fuzz/blob/master/projects/open...