[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <6IEygEMfsHUuGqsMETy65yE8ZH-0RszEgc88HZHWraqXThJKtSL1DQK-MOoxqlx7FeYF_nqTx6Xhrlkr3JeJZSRfkXjzBQk0D9i5qAbVsOY=@proton.me>
Date: Sun, 15 Mar 2026 18:21:52 +0000
From: 0rbitingZer0@...ton.me
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Cc: "dalias@...c.org" <dalias@...c.org>
Subject: NSCD client getgr_a.c heap overflow + integer overflow
Hi,
During an independent source audit of musl 1.2.5 (current git master, v1.2.5-102-g1b76ff07) I found a heap overflow write in the NSCD group response parsing in src/passwd/getgr_a.c. I reported this to Rich privately, and he spotted an additional integer overflow in the same code path. He suggested moving the discussion here since no embargo is needed.
Rich's assessment of the security relevance:
> the only means of passing input to this interface is to be the
> owner of /var/run/nscd/socket, a privileged path that's already
> expected to have authority over user/group identities. However,
> if you're running the service there with root privileges dropped
> and perhaps some sandboxing to mitigate bugs in the nscd code
> that make it vulnerable to attacks from remote backends, bugs in
> musl's nscd client do enable an attacker to move from there to
> here. So I think it's security-relevant. Not as a direct vuln
> but as an unintended lateral movement vector.
And on the fix:
> The level of validation needed here was probably deemed low
> because the source of the data is privileged. But this should
> be fixed.
Here are the details.
1. Heap overflow write (lines 127-136):
The member pointer array is allocated based on GRMEMCNT (line 118):
char **tmp = realloc(*mem, (groupbuf[GRMEMCNT]+1)*sizeof(char*));
The loop at line 129 scans the member data for null bytes and writes a pointer for each one:
for (ptr = mem[0][0], i = 0; ptr != mem[0][0]+grlist_len; ptr++)
if (!*ptr) mem[0][++i] = ptr+1;
The count check at line 133 runs after the loop completes:
if (i != groupbuf[GRMEMCNT]) {
rv = EIO;
goto cleanup_f;
}
If the data contains more null bytes than GRMEMCNT declares, the loop writes past the allocated array before the check fires. The data shape is deliverable through the real NSCD protocol: GRMEMCNT controls how many name_len fields are read (line 80), grlist_len is their sum, and the actual data blob is fread'd at line 108. Null byte placement within the blob is fully attacker-controlled.
ASan confirms: heap-buffer-overflow WRITE of size 8, 0 bytes after a 16-byte region (GRMEMCNT=1, 2-slot array, 5 null-terminated strings in data).
2. Integer overflow (lines 113-114):
Rich noted:
> This and lines 113 and 114 above it already have a bug:
> integer overflow adding 1 without testing for overflow.
> Just adding 1U isn't a solution either because then a value
> of -1 would wrongly pass. There is just a need for more
> validation here.
Happy to post the PoC if useful.
0rbitingZer0
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
