boringssl
oss-fuzz
Our great sponsors
boringssl | oss-fuzz | |
---|---|---|
10 | 31 | |
1,719 | 9,907 | |
3.4% | 4.4% | |
6.5 | 9.9 | |
5 days ago | 3 days ago | |
C | Shell | |
GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
boringssl
-
New vulnerabilities (CVE-2022-3602 and CVE-2022-3786) in OpenSSL, how they affect IoT and RTOS Devices.
I have nothing constructive to add except that OpenSSL has a long history of producing vulnerabilities so much so that Google has created their own fork publicly available here: https://boringssl.googlesource.com/boringssl/ (used in chromium, chrome, and android).
-
OpenSSL added new C parser code [...] without doing any basic security testing
> 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/
-
CVE-2022-3786 and CVE-2022-3602: X.509 Email Address Buffer Overflows
OpenSSL gets plenty of funding but we need to put more funding into TLS implementations that have a bigger focus on security and stability like boringssl, nss, go's tls, and rustls. It's 2022 and we have both languages better suited for this and tools to make existing languages safer and more robust, it's incredible to me that we aren't even more anxious over the current state of openssl.
-
BearSSL: A smaller SSL/TLS library
It was not built for chromium AFAIK
To quote: https://boringssl.googlesource.com/boringssl/
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.
- OpenSSL Security Advisory for CVE-2022-0778
-
I think a major issue with the rust ecosystem is that it's full of unexpected design decisions
Use Google's fork of OpenSSL which exists because Google likes to do it's own weird things sometimes. This doesn't say anything about "OpenSSL is considered dangerous", it says "This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you."
- Information and learning resources for cryptography newcomers
-
OpenSSL Security Advisory (14 December 2021)
And this is why projects like https://boringssl.googlesource.com/boringssl/ exist
-
U.S. Telecoms Are Going to Start Physically Removing Huawei Gear
The immediate effect of Heartbleed was the OpenBSD folk [1] and Google [2] forking OpenSSL.
There's a talk from Bob Beck of OpenBSD on pruning OpenSSL, it's pretty hilarious [3].
In that case open source was at least able to react appropriately, even if it didn't act preemptively.
[1]: https://www.libressl.org
[2]: https://boringssl.googlesource.com/boringssl/
[3]: https://www.youtube.com/watch?v=GnBbhXBDmwU
-
Cloudflare: Warp for Linux and Proxy Mode
I doubt the reference to Musk's brand is intentional. It's more likely that it's a reference/homage to BoringSSL (https://github.com/google/boringssl) and "boring tech" in general that is purposefully designed to be minimalist, simple to use, and narrow in scope.
oss-fuzz
- Xz: Disable ifunc to fix Issue 60259
-
Backdoor in upstream xz/liblzma leading to SSH server compromise
> because the ifunc code was breaking with all sorts of build options and obviously caused many problems with various sanitizers
for example, https://github.com/google/oss-fuzz/pull/10667
-
Ask HN: Any Good Fuzzer for gRPC?
Have you tried Googles grpc fuzzer?
https://github.com/google/oss-fuzz/blob/master/projects/grpc...
-
Pacemaker should be running open source software
https://www.fda.gov/medical-devices/digital-health-center-ex...
oss-fuzz: https://github.com/google/oss-fuzz :
> We support the libFuzzer, AFL++, and Honggfuzz fuzzing engines in combination with Sanitizers, as well as ClusterFuzz, a distributed fuzzer execution environment and reporting tool.
> Currently, OSS-Fuzz supports C/C++, Rust, Go, Python, Java/JVM, and JavaScript code. Other languages supported by LLVM may work too. OSS-Fuzz supports fuzzing x86_64 and i386 builds.
-
Fuzz Testing Is the Best Thing to Happen to Our Application Tests
I love fuzzing as a technique and use it quite regularly, but running AFL++ on even a single program occupies all threads of a high end AMD server for weeks. I'm running it locally so only paying for the electricity. If it was a cloud instance it would cost a small fortune. I think this is a reason it is not used more widely.
I will note that Google have a programme for doing fuzz testing on open source projects using computer from their cloud: https://google.github.io/oss-fuzz/
- Fixed Spelling Errors or Typos
- ELI5: How can downloading a pdf or word file give you a virus?
- OSS-Fuzz β continuous fuzzing for open source software
-
Mosh: An Interactive Remote Shell for Mobile Clients (2012) [pdf]
Yes, mosh has fuzz tests in oss-fuzz [1].
[1] https://github.com/google/oss-fuzz/tree/master/projects/mosh
-
Java Fuzzing with Jazzer compared to Symflower
We will explore how Jazzer is used to automatically generate malicious inputs for Java programs, and how it compares to Symflower, which can automatically generate unit tests to uncover bugs and errors in your code. With the help of Jazzer, many bugs - some of them even in the OpenJDK - were found already. Also, as of March 2021, Jazzer is officially part of OSS-Fuzz, Google's cloud fuzzing engine. It should be noted that Jazzer is a pure "bug detection" utility that finds reproducers for errors in user code. Symflower can do the same, but provides additional functionalities to boost developer productivity, like generating high coverage unit tests and providing test templates for the software developer or tester.
What are some alternatives?
OpenSSL - TLS/SSL and crypto library
AFLplusplus - The fuzzer afl++ is afl with community patches, qemu 5.1 upgrade, collision-free coverage, enhanced laf-intel & redqueen, AFLfast++ power schedules, MOpt mutators, unicorn_mode, and a lot more!
wolfssl - The wolfSSL library is a small, fast, portable implementation of TLS/SSL for embedded devices to the cloud. wolfSSL supports up to TLS 1.3!
fuzzilli - A JavaScript Engine Fuzzer
libsodium - A modern, portable, easy to use crypto library.
ffmpeg-libav-tutorial - FFmpeg libav tutorial - learn how media works from basic to transmuxing, transcoding and more. Translations: πΊπΈ π¨π³ π°π· πͺπΈ π»π³ π§π·
Tink - Tink is a multi-language, cross-platform, open source library that provides cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse.
libfuzzer - Thin interface for libFuzzer, an in-process, coverage-guided, evolutionary fuzzing engine.
webpki - WebPKI X.509 Certificate Validation in Rust
FFmpeg - Mirror of https://git.ffmpeg.org/ffmpeg.git
istlsfastyet.com - Is TLS fast yet? Yes, yes it is.
uafuzz - UAFuzz: Binary-level Directed Fuzzing for Use-After-Free Vulnerabilities