# The story of a fuzzing integration reward

LibreSSL's ASN.1 parser lacked negative-integer range checks, so a crafted INTEGER caused an out-of-bounds read in BN_bin2bn during printing.

- Payout: $10,000
- Severity: medium
- Program: Google
- Credited: Andrea Brancaleoni
- Disclosed: 2020-04-08
- Write-up quality: 6/10
- Original: https://blog.doyensec.com/2020/04/08/libressl-fuzzer.html
- Library page: https://bugbountylibrary.com/r/blog%3Ablog-doyensec-com-2020-04-08-libressl-fuzzer-html
- Tags: domain:oss impact:dos kind:research platform:research sev:medium tech:linux technique:fuzzing technique:source-review vuln:info-disclosure vuln:memory-corruption

**Target:** LibreSSL ASN.1 parser (ASN1_INTEGER_to_BN / BN_bin2bn) via OSS-Fuzz fuzzer
**Root cause:** ASN1_INTEGER_to_BN passed a negative-length/negative-value integer to BN_bin2bn without range checks, so the size used was not a positive integer, causing an uncontrolled over-read.
**Steps:**
1. Integrate LibreSSL into OSS-Fuzz using the OpenSSL fuzzers (asn1.c harness).
2. Fuzzer emits minimized testcase `0202 ff25` (ASN.1 INTEGER of length 2 with negative value).
3. Run testcase through ASN1_item_print -> asn1_print_integer_ctx -> i2s_ASN1_INTEGER -> ASN1_INTEGER_to_BN -> BN_bin2bn.
4. Observe ASan SEGV wild-addr-read at bn_lib.c:601.
**How found:** Ported OpenSSL's existing fuzzers to LibreSSL and ran them under OSS-Fuzz; the fuzzer produced a minimized crash testcase which was inspected with dumpasn1, revealing an INTEGER encoded as a negative value that LibreSSL failed to reject.
**Exploitation:** Not weaponized; the crash is a wild-address read reachable when printing/parsing attacker-supplied ASN.1 (e.g. X.509 data), potentially leaking memory in security-sensitive contexts.
**Insight:** When porting fuzzers to an API-compatible fork, target the code paths the fork rewrote or slimmed (here ASN.1 print/convert) rather than the shared code; malformed encodings that a stricter reference rejects are prime crash candidates.