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
29 lines
1.4 KiB
Markdown
29 lines
1.4 KiB
Markdown
---
|
|
synopsis: "Fix unsigned overflow leading to out-of-band write in the NAR parser"
|
|
cls: [5554]
|
|
category: "Fixes"
|
|
credits: [horrors, raito, edef, sandydoo]
|
|
issues: []
|
|
---
|
|
|
|
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.
|