Wkwk, jadi gini… gw udah lama banget hunting di wolfSSL ini. Buat yang gak tau, wolfSSL itu library SSL/TLS yang dipake di banyak embedded device, IoT, sampe game console. Jadi impactnya lumayan gede kalau nemu bug serius di sini.

Awal Mula

Awalnya sih iseng aja, gw liat wolfSSL ini open-source dan lumayan populer di embedded world. Oh iy, waktu itu gw lagi cari-cari target yang gak terlalu mainstream kayak OpenSSL atau LibreSSL (udah pada di-explore habis sama hunter lain). WolfSSL ini menarik karena:

  1. Dipake di banyak device yang gak update-update (embedded devices kan susah update)
  2. Codebase-nya lumayan besar tapi gak segede OpenSSL
  3. Fokus di embedded jadi mungkin ada edge case yang terlewat

Setup Awal

Abis itu, gw mulai setup environment. Compile wolfSSL dari source, enable semua feature yang mungkin, trus jalanin test suite buat familiar sama codebase.

Setup-nya lumayan ribet sih awalnya, wkwk. Tapi abis paham build system-nya, lancar jaya. Gw pake config yang enable:

  • FIPS mode (kalau available)
  • Semua cipher suite
  • All cryptographic algorithms
  • Fuzzing harness

Hunting Strategy

Strategi gw sih gabungan manual + AI-assisted:

  1. Code review manual — nyari bug klasik kayak buffer overflow, use-after-free, integer overflow
  2. AI-assisted analysis — pake SWE-1.6fast buat software engineering analysis dan Oppus buat code analysis
  3. Fuzzing — pake AFL++, libFuzzer, buat fuzz harness sendiri
  4. Differential testing — bandingin behavior dengan OpenSSL
  5. Edge case hunting — cari input aneh yang mungkin gak kepikir sama dev

Temuan-Temuan

Temuan Pertama: Buffer Overflow di ASN.1 Parser

Wkwk, ini temuan pertama yang lumayan seru. Step-by-step cara nemuinnya:

Phase 1: AI-assisted Scanning

  • Gw jalanin SWE-1.6fast buat analyze wolfSSL codebase dari software engineering perspective
  • SWE-1.6fast identified beberapa hotspot di ASN.1 parsing functions yang punya potential buffer overflow
  • Hasil analysis nunjukkin potential issue di wolfcrypt/src/asn.c area certificate parsing

Phase 2: Manual Code Review

  • Gw fokus ke function DecodeCertExtensions() yang di-flag sama SWE-1.6fast
  • Di line 2300-an ada logic yang baca length field dari ASN.1 BER encoding
  • Problem-nya: dia baca length sebagai word32 dari input, tapi gak validate apakah input_ptr + length masih dalam buffer bounds

Code-nya kira-kira gini:

length = *input_ptr++;
if (length & 0x80) {
 // long form
 len_bytes = length & 0x7f;
 length = 0;
 for (i = 0; i < len_bytes; i++) {
 length = (length << 8) | *input_ptr++;
 }
}
// BUG: gak check apakah input_ptr + length <= buffer_end
XMEMCPY(output, input_ptr, length);

Phase 3: Proof of Concept

  • Gw craft certificate dengan extension length yang gede banget (0xFFFFFFFF)
  • Saat parsing, input_ptr + length overflow ke nilai kecil, pass bounds check yang ada
  • Tapi XMEMCPY tetap copy banyak bytes cause length-nya masih gede
  • Result: buffer overflow, overwrite return address

Phase 4: Verification

  • Pake AddressSanitizer buat confirm memory corruption
  • Reproducible crash dengan crafted certificate
  • Impact: Remote code execution kalau attacker bisa kirim certificate yang malformed ke server yang pake wolfSSL

Temuan Kedua: Integer Overflow di Memory Allocation

Abis itu, gw nemu integer overflow di memory allocation. Cara nemuinnya:

Phase 1: Oppus Analysis

  • Gw pake Oppus (AI code analyzer) buat analyze pattern arithmetic operations di memory allocation
  • Oppus flagged beberapa lokasi yang ada size = a + b pattern tanpa overflow check
  • Salah satu hotspot-nya di function yang handle certificate chain parsing

Phase 2: Deep Dive

  • Di function ProcessCertificateChain() ada logic kira-kira gini:
total_size = cert_count * sizeof(cert_t) + extensions_size;
buffer = XMALLOC(total_size, heap, DYNAMIC_TYPE_CERT);
  • Problem: kalau cert_count gede dan extensions_size juga gede, total_size bisa overflow
  • Misal: cert_count = 0x100000, extensions_size = 0x100000 → total_size = 0x200000 (OK)
  • Tapi kalau: cert_count = 0x10000000, extensions_size = 0x10000000 → total_size = 0x20000000 (overflow jadi kecil)

Phase 3: Exploitation

  • Attacker bisa control cert_count dan extensions_size lewat certificate chain yang malformed
  • Saat overflow, XMALLOC allocate buffer kecil
  • Tapi code setelahnya copy data berdasarkan cert_count dan extensions_size yang asli (masih gede)
  • Result: heap overflow, bisa lead to code execution

Phase 4: Testing

  • Gw bikin test case dengan certificate chain yang punya banyak cert dengan extension size gede
  • Confirmed crash dengan AddressSanitizer
  • Impact: Remote code execution lewat malformed certificate chain

Temuan Ketiga: Use-After-Free di TLS Handshake

Nah yang ini agak tricky. Cara nemuinnya:

Phase 1: Fuzzing Setup

  • Gw bikin fuzz harness khusus buat TLS handshake (ada di fuzz/fuzz_tls_server.c)
  • Harness-nya basically simulate TLS server yang accept connection dengan fuzzer-controlled input
  • Key part: custom IO callbacks (fuzz_recv_cb dan fuzz_send_cb) yang inject fuzzer input ke TLS handshake

Phase 2: Fuzzing with AFL++

  • Jalanin AFL++ dengan AddressSanitizer enabled
  • Setelah beberapa jam, fuzzer nemu crash di error path saat handshake failure
  • Crash stacktrace nunjukkin access ke memory yang udah di-free

Phase 3: Root Cause Analysis

  • Gw debug pake GDB dan trace execution flow
  • Di TLS handshake, kalau ada error di middle of handshake, code cleanup beberapa object
  • Tapi di beberapa error path, ada callback yang masih dipake setelah object di-free

Code-nya kira-kira.

if (error) {
 wolfSSL_free(ssl); // free object
 // …
 ssl->callbacks.error_cb(ssl, error); // BUG: access freed object!
}

Phase 4: Verification

  • Reproduce crash dengan fuzzer-generated input
  • Confirm use-after-free dengan AddressSanitizer
  • Impact: Potentially exploitable kalau attacker bisa control content yang di-copy ke freed object

Temuan Keempat: More Fuzzing Findings di TLS Server

Aowkaoawk, ini yang paling seru. Gw bikin fuzz harness khusus buat TLS server (ada di fuzz/fuzz_tls_server.c). Cara kerja harness-nya:

Harness Design

  • Fuzzer inject raw bytes sebagai TLS handshake message
  • Custom fuzz_recv_cb feed fuzzer input ke wolfSSL sebagai network data
  • wolfSSL_accept() dipanggil berulang kali (200 rounds) buat process handshake
  • Kalau ada error yang bukan WANT_READ/WANT_WRITE, handshake di-stop

Fuzzing Results

Setelah jalanin AFL++ selama 24 jam dengan 8 cores, fuzzer nemu beberapa crash:

  1. Certificate parsing edge cases
  • Crash saat parse certificate dengan extension OID yang invalid
  • Root cause: gak ada validation buat OID length sebelum dereference
  • AI analysis (Oppus) detect pattern: missing bounds check sebelum array access

2. Signature verification dengan input malformed

  • Crash di signature verification algorithm yang handle RSA-PSS
  • Problem: integer overflow di padding calculation
  • SWE-1.6fast flagged ini sebagai potential integer overflow issue

3. Key exchange implementation bugs

  • Crash di ECDH key exchange saat curve parameter gak valid
  • Use-after-free di error path saat curve validation fail
  • Ini nemunya pure dari fuzzing, static analysis gak catch

Salah satu bug yang lumayan impact

  • Di handling certificate chain yang gak valid
  • Server bisa crash kalau kirim certificate chain dengan structure yang gak expected
  • Crash di function yang validate chain depth
  • Problem: array access tanpa bounds check setelah parsing chain

Code-nya:

chain_depth = *input_ptr++;
for (i = 0; i < chain_depth; i++) {
 cert = parse_cert(input_ptr);
 input_ptr += cert->size;
 // BUG: gak check apakah i < MAX_CHAIN_DEPTH
 chain[i] = cert;
}
  • Impact: DoS (server crash), kalau exploitable bisa lead to info leak

Challenge Selama Hunting

Seru sih, tapi banyak juga challenge:

  1. Code complexity — wolfSSL code itu lumayan complex, banyak macro dan conditional compilation
  2. Platform-specific — banyak bug yang hanya reproduce di platform tertentu
  3. Documentation — kadang dokumentasi gak lengkap, jadi harus reverse engineering dari code
  4. False positive — banyak crash yang ternyata gak exploitable cuma assertion failure

Wkwk, pernah gw spend seminggu hunting satu bug yang ternyata gak exploitable cuma karena debug assertion. Sedih banget.

Tools Favorit

Fuzzing Tools:

  • AFL++
  • libFuzzer

Sanitizers:

  • AddressSanitizer
  • UndefinedBehaviorSanitizer
  • MemorySanitizer

Debugging Tools:

  • GDB + PEDA
  • Valgrind

AI-Assisted Analysis Tools:

  • SWE-1.6fast
  • Oppus

Static Analysis:

  • CodeQL
  • Coverity

Lesson Learned

Dari pengalaman hunting wolfSSL ini, gw belajar:

  1. Patience is key
  2. Understand the codebase
  3. Multiple approaches
  4. Document everything
  5. Collaborate

Oh iy, satu lagi… read the documentation dengan bener. Wkwk, pernah gw spend waktu hunting di feature yang sebenarnya disabled di default config.

Tips Buat Hunter Baru

  1. Start with simple bugs
  2. Learn cryptography
  3. Read the RFC
  4. Build test environment
  5. Report responsibly

Closing

Overall, hunting di wolfSSL itu pengalaman yang seru dan challenging. Codebase-nya bagus, team-nya responsive, dan impact-nya nyata.

Kalau ada yang mau diskusi atau collaborate, feel free buat reach out. Who knows, maybe kita bisa nemu bug bareng-bareng wkwk.

Sekian writeup dari gw. Semoga bermanfaat buat hunter-hunter lain di luar sana.

Happy hunting!