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
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 |
|
Fixes |
|
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.