ANT-2026-45SRWS4Q · bearssl

heap-buffer-overflow high

Severity Claude high · Security research firm - · Maintainer -

REPORT

Anthropic's analysis, sealed at approval. Disclosure to the maintainer was performed by Calif.

ANT-2026-45SRWS4Q: BearSSL Missing Block-Alignment Check in cbc_check_length() → Unbounded Heap/Stack Write via 3DES-CBC

BearSSL's cbc_check_length() (ssl_rec_cbc.c:49-74) validates min/max bounds on incoming TLS record lengths but omits the block-alignment check its own comment documents. An attacker-controlled 2-byte wire length (e.g., 33 for 3DES) passes the check and is forwarded via cbc_decrypt() (line 124) to the block cipher's run() function, whose contract requires block-aligned input. In the des_ct backend — the only 3DES implementation, enabled in all full init profiles — and in aes_big/aes_small, the decrypt loop subtracts blocksize from a size_t until it wraps to ~2^64, producing an unbounded linear write past ibuf. A malicious client can force 3DES negotiation by offering only those suites, complete an unauthenticated handshake, and send one malformed record to crash the server, with plausible RCE when iobuf is stack-allocated as in BearSSL's own samples.

Target

Project: bearssl
Location: cbc_check_length() at src/ssl/ssl_rec_cbc.c:73

Technical Details

The return expression min_len <= rlen && rlen <= max_len accepts every integer in the range even though only block-aligned values are valid; the unaligned rlen then violates the documented precondition of bc.vtable->run() (bearssl_block.h:108 warns it 'may loop forever or overflow a buffer'). ASAN: "heap-buffer-overflow ... WRITE of size 1" in br_enc32be (inner.h:567) via br_aes_big_cbcdec_run — the size_t loop counter underflows past zero and the decrypt loop keeps writing blocks linearly past the allocation; the 3DES path through br_des_ct_cbcdec_run behaves identically and is the default-profile exploit path.

Crash trace:

==...==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x...
WRITE of size 1 at 0x... thread T0
    #0 ... in br_enc32be inner.h:567:9
    #1 ... in br_aes_big_decrypt .../aes_big_dec.c:250:2
    #2 ... in br_aes_big_cbcdec_run .../aes_big_cbcdec.c:50:3
    #3 ... in cbc_decrypt ssl_rec_cbc.c:124:2

Reproduction

  1. Connect to the BearSSL TLS server.
  2. Send ClientHello offering only 3DES-CBC cipher suites; server (full profile) accepts.
  3. Complete the TLS handshake normally.
  4. Send raw record header 17 03 03 00 21 followed by 33 arbitrary bytes.
  5. cbc_check_length(33) returns 1; cbc_decrypt forwards len=33 to br_des_ct_cbcdec_run.
  6. Loop underflows size_t and writes linearly past ibuf until SEGV (or over return address for stack iobuf).

[No reproducer or sanitizer output attached — request from security-cvd@anthropic.com if needed.]

Suggested Fix

Append && (rlen & (blen - 1)) == 0 to the return expression at src/ssl/ssl_rec_cbc.c:73 to enforce the block-alignment requirement already documented in the function comment and RFC 5246 §6.2.3.2.

Acknowledgement

This vulnerability was discovered by Claude, Anthropic's AI assistant, and triaged by the Anthropic security team in collaboration with Anthropic Research. Please direct questions to security-cvd@anthropic.com and reference ANT-2026-45SRWS4Q.

Reference: ANT-2026-45SRWS4Q
Anthropic CVD Policy: https://www.anthropic.com/coordinated-vulnerability-disclosure

SECURITY RESEARCH FIRM ANALYSIS

Triage and disclosure were performed by Calif.

Verdict
true positive
TIMELINE

Dates from discovery through public reveal.

  1. 2026-04-06 Sent to maintainer
  2. 2026-04-06 Patch released
  3. 2026-05-19 Reported to tracker
  4. 2026-05-28 Maintainer acknowledged
  5. 2026-08-17 Publicly revealed
PROVENANCE

SHA-3-512 hash:

34b666b1d995734b7cf604b442cd2a7974c02be34b0a27c810ffe0f5bd207428cbcc5934182c421cbab739f1ba49e0273945ef732f6c66eded011618348871ee

Committed 2026-05-28 08:09 PT

Revealed 2026-08-17 13:01 PT

Verify (download preimage.json)

Show preimage JSON 
{
  "ant_id": "ANT-2026-45SRWS4Q",
  "bug_class": "Heap Buffer Overflow",
  "claude_severity": "high",
  "commit_sha": null,
  "created_at": "2026-05-20T01:48:28+00:00",
  "description": "BearSSL's cbc_check_length() (ssl_rec_cbc.c:49-74) validates min/max bounds on incoming TLS record lengths but omits the block-alignment check its own comment documents. An attacker-controlled 2-byte wire length (e.g., 33 for 3DES) passes the check and is forwarded via cbc_decrypt() (line 124) to the block cipher's run() function, whose contract requires block-aligned input. In the des_ct backend — the only 3DES implementation, enabled in all *_full_* init profiles — and in aes_big/aes_small, the decrypt loop subtracts blocksize from a size_t until it wraps to ~2^64, producing an unbounded linear write past ibuf. A malicious client can force 3DES negotiation by offering only those suites, complete an unauthenticated handshake, and send one malformed record to crash the server, with plausible RCE when iobuf is stack-allocated as in BearSSL's own samples.",
  "discovered_at": "2026-03-28T00:00:00+00:00",
  "location": "cbc_check_length() at src/ssl/ssl_rec_cbc.c:73",
  "poc_sha256": null,
  "preimage_version": 1,
  "project": "bearssl",
  "reproduction": [
    "1. Connect to the BearSSL TLS server.",
    "2. Send ClientHello offering only 3DES-CBC cipher suites; server (full profile) accepts.",
    "3. Complete the TLS handshake normally.",
    "4. Send raw record header 17 03 03 00 21 followed by 33 arbitrary bytes.",
    "5. cbc_check_length(33) returns 1; cbc_decrypt forwards len=33 to br_des_ct_cbcdec_run.",
    "6. Loop underflows size_t and writes linearly past ibuf until SEGV (or over return address for stack iobuf)."
  ],
  "technical_details": "The return expression `min_len <= rlen && rlen <= max_len` accepts every integer in the range even though only block-aligned values are valid; the unaligned rlen then violates the documented precondition of bc.vtable->run() (bearssl_block.h:108 warns it 'may loop forever or overflow a buffer'). ASAN: \"heap-buffer-overflow ... WRITE of size 1\" in br_enc32be (inner.h:567) via br_aes_big_cbcdec_run — the size_t loop counter underflows past zero and the decrypt loop keeps writing blocks linearly past the allocation; the 3DES path through br_des_ct_cbcdec_run behaves identically and is the default-profile exploit path.",
  "title": "BearSSL Missing Block-Alignment Check in `cbc_check_length()` → Unbounded Heap/Stack Write via 3DES-CBC",
  "vendor_severity": null
}