Cap bit indices in the unsafe string-based X.509 extensions API

Without a limit, a short input can translate into a very large allocation,
which is upsetting the fuzzers. Set a limit of 256, which allows up to a
32-byte allocation. (The highest bit index of any type in RFC 5280 is
8, so this is plenty of buffer.)

We do not consider this function to be safe with untrusted inputs (even
without bugs, it is prone to string injection vulnerabilities), so DoS
is not truly a concern, but the limit is necessary to keep fuzzing
effective.

Update-Note: If anyone is using FORMAT:BITLIST to create very large BIT
STRINGs, this will break. This is unlikely and should be caught by
unit tests; if a project hits this outside of tests, that means they are
passing untrusted input into this function, which is a security
vulnerability in itself, and means they especially need this change to
avoid a DoS.

Bug: oss-fuzz:55603
Change-Id: Ie9ec0d35c7d67a568371dfa961867bf1404f7e2f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56785
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
2 files changed
tree: 7b9db8460625f796fd55348bf38d609dfec6a482
  1. .github/
  2. cmake/
  3. crypto/
  4. decrepit/
  5. fuzz/
  6. include/
  7. rust/
  8. ssl/
  9. third_party/
  10. tool/
  11. util/
  12. .clang-format
  13. .gitignore
  14. API-CONVENTIONS.md
  15. BREAKING-CHANGES.md
  16. BUILDING.md
  17. CMakeLists.txt
  18. codereview.settings
  19. CONTRIBUTING.md
  20. FUZZING.md
  21. go.mod
  22. go.sum
  23. INCORPORATING.md
  24. LICENSE
  25. PORTING.md
  26. README.md
  27. SANDBOXING.md
  28. sources.cmake
  29. STYLE.md
README.md

BoringSSL

BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.

Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.

BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.

Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.

Project links:

There are other files in this directory which might be helpful: