This can be an attack surface: der::decode() silently accepts trailing bytes — signature bypass vector

[tynus2]

Hi rasn maintainers,

I'm reporting a (potential) security issue in rasn's der::decode() that affects all versions through 0.28.11.
(seems I cannot get a email addr, and now there is not private issues, so I can only report it here)

Summary

rasn::der::decode() does not verify that all input bytes are consumed after decoding. X.690 DER §8.1.1.1 mandates that a DER encoding is exactly one complete TLV with no trailing data. Currently, der::decode() delegates to T::decode() and returns the result without checking decoder.remaining():

// src/der.rs:6-11
pub fn decode<T: crate::Decode>(input: &[u8]) -> Result<T, crate::error::DecodeError> {
    T::decode(&mut crate::ber::de::Decoder::new(
        input,
        crate::ber::de::DecoderOptions::der(),
    ))
    // ← No check that all input was consumed
}

This means rasn::der::decode::<Null>(&[0x05, 0x00, 0xDE, 0xAD, 0xBE, 0xEF]) succeeds silently, accepting 4 trailing garbage bytes.

Security Impact

This bug is structurally identical to several assigned CVEs for the same class of issue:

CVE	Lib	CVSS	Bug
CVE-2018-16150	axTLS	High	Trailing bytes in PKCS#1 → Bleichenbacher forgery
CVE-2018-16151/16152	strongswan	High	Trailing bytes in ASN.1 → signature bypass
CVE-2014-1569	NSS	Critical	DER permissiveness enables data smuggling

Concrete attack scenarios:

1. Bleichenbacher-style signature forgery: If rasn is used to parse decrypted PKCS#1 v1.5 DigestInfo, trailing bytes after the ASN.1 structure are silently accepted. With RSA e=3, an attacker can forge signatures.
2. Two-parser chain bypass: If a strict DER parser signs/verifies bytes and rasn parses the same input, appended data is invisible to rasn but changes the byte representation — enabling signature verification bypass.
3. Round-trip divergence: decode(input) then encode(value) produces different bytes than the original, breaking certificate transparency logs, replay detection, and any system comparing raw DER encodings.

Reproduction

use rasn::der;
use rasn::types::Null;

let input = &[0x05, 0x00, 0xDE, 0xAD, 0xBE, 0xEF]; // NULL + trailing garbage
let result = der::decode::<Null>(input);
assert!(result.is_ok()); // BUG: should reject trailing bytes

Discovery

Found via source code audit during differential fuzzing

I saw you provide a interface for rasn-pkix, so I think this should be reported as a security issue.
Looking forward to your reply.

[XAMPPRocky]

Thank you for your issue! It seems like a straightforward fix, I'm currently away for a bit but I can review a PR and release a fix.

[Nicceboy]

Current behavior is clearly against the best practices, but I am not sure if I would classify it as security bug. This is general ASN.1 library and it does not verify or sign anything by itself. If cryptographic libraries use this under the hood and assume some behavior differently than this library actually works and then trusts it, that causes the bug. The security issue is in the code which glues the verification logic and ASN.1 parsing (as mentioned CVEs are).

The problem is that ASN.1 specification does not take a stand for errors or trailing data, and in DER it just says enforcing definite lengths. Because of the issues in the glue code of the dependents, general best practice has been to drop the trailing bytes in ASN.1 layer.

The same issue applies for most codecs here. There wasn't decode_with_remainder in past so it couldn't fail with trailing data as there was no really option for streaming. decode should have been likely made strict at that point where possible, but I think some codecs still miss it. Decode functions should be likely documented to mention the strictness after the change.

[tynus2]

Thanks for the thoughtful reply, and I'm glad we're aligned on the fix — making decode() strict is really the outcome that matters to me.

On the spec point: I agree X.690 is an encoding specification rather than a parser one, so it doesn't literally say "reject trailing bytes." I think strictness is still the right default because of the implicit API contract — decode<T>(&[u8]) -> T reads as "these bytes are the TLV encoding of a T," which feels different from the streaming contract of decode_with_remainder.

On the security framing: I take your point that rasn is a general-purpose codec and doesn't trust anything itself. The part I'd still gently flag is round-trip divergence — with current decode(), encode(decode(bytes)) can produce a shorter output than the input (e.g., 05 00 de ad be ef decodes to Null and re-encodes to 05 00). That property tends to bite downstream users in ways that are hard to predict from inside the library.

That said, how to classify and announce the fix is your call. Happy to help validate it against the PoC test vectors once it lands, and to update my writeup however you'd like it characterized.

Thanks again for taking the time to look at this.