Files
lix/doc/manual/rl-next/unsigned-overflow-vuln.md
T
eldritch horrorsandRaito Bezarius 2f7d7444f1 libutil: fix nar parser buffer overflow
string data shares a buffer with the binary string length field. size
calculations for string read buffers always include the length field;
sufficiently large length fields can cause these calculations to wrap.
a malicious nar could use this for OOB writes in the daemon (as root).

since we use strings only as tags for archive members and for symlinks
with their OS-dependent length limits we can simply limit string size.
1 MiB should be sufficient for all symlinks, and tags are always tiny.

Change-Id: I89fb05f73c1dbeda45d91244aba4cd526a3d83e1
2026-05-04 19:00:19 +02:00

1.4 KiB

synopsis, cls, category, credits, issues
synopsis cls category credits issues
Fix unsigned overflow leading to out-of-band write in the NAR parser
5554
Fixes
horrors
raito
edef
sandydoo

The NAR parser contained an unsigned integer overflow that could be used by an attacker to write arbitrary data to an unknown memory location and possibly achieve code execution. A successful attack on the system-wide Lix daemon could lead to privilege escalation to root. Any process that involves NAR serialization could trigger this issue, including (but not limited to)

  • local user interaction, whether the users are trusted or untrusted
  • malicious substituters sending malformed NARs
  • remote builders sending malformed build results
  • remote daemons sending malformed inputs when requesting remote builds

Successful attacks using this bug require ASLR weakening of some sort, whether by architecture constraints (e.g. on 32 bit systems, where little randomization is possible) or system configuration (e.g. low ASLR entropy when loading libraries), and millions of attempts. Local attacks can be mounted in less than an hour. Remote builds typically require a fresh SSH connection for each build and are thus less susceptible. Only one attempt can be made by substituters for every build using substituters, they are thus not a likely vector for attacks.

At the time of writing, MITRE has not assigned this a CVE yet.