# DNSSECImpl.verifySignature compares strings incorrectly, allowing malicious zones to forge DNSSEC trust chain

DNSSECImpl.verifySignature used raw byte substring matching instead of label comparison, letting a signer name cover unrelated zones and potentially forge DNSSEC trust chains.

- Payout: Contest reward
- Severity: medium
- Program: ENS
- Credited: GimelSec
- Disclosed: 2022-12-13
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-07-ens-findings/issues/207
- Library page: https://bugbountylibrary.com/r/c4%3A2022-07-ens%3AM-05
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:misconfiguration vuln:signature-replay

**Target:** DNSSEC oracle smart contract (DNSSECImpl.sol verifySignature)
**Root cause:** The signer-name coverage check compares packed name bytes as a suffix substring rather than comparing DNS labels, so a signerName that is a byte-substring of the child name passes even when it is not a parent zone.
**Steps:**
1. Read `DNSSECImpl.verifySignature` lines 186-190: it checks `rrset.signerName.length <= name.length` and `rrset.signerName.equals(0, name, name.length - rrset.signerName.length)`.
2. Observe this is a raw byte-suffix comparison, not label-by-label.
3. Craft a signerName whose packed bytes are a suffix of the victim name's packed bytes, e.g. signerName `\x05xample\x03eth\x00` for name `\x07e\x05ample\x03eth\x00`.
4. Submit the forged RRSIG so verifySignature accepts the unrelated signer as covering the target zone.
**How found:** Code review of the RFC4034 3.1.7 name-coverage requirement against the implementation; noticed the check used byte-suffix string equality instead of label counts, then reasoned about packed-label encoding to construct a passing pair.
**Exploitation:** Attacker with a signed zone whose packed name is a byte-substring of a target name could have its RRSIG accepted as covering the target, forging a trust chain. In practice constrained: RFC 1035 limits labels to 63 octets and lowercase 'a' is 97, so no exploitable name pairs are believed to exist.
**Insight:** When a spec requires zone/label hierarchy, verify implementations compare DNS labels (length-prefixed) not raw byte suffixes; packed-label encoding means a substring match can cross label boundaries, so check whether encoding constraints (63-octet labels) actually make crafted pairs reachable before rating severity.