Date: Mon, 6 Sep 2021 21:07:30 +0200 From: Solar Designer <solar@...nwall.com> To: Jean Diogo <j@....com.br> Cc: oss-security@...ts.openwall.com Subject: Re: Possible memory leak on getspnam / getspnam_r Hi Jean, On Tue, Aug 24, 2021 at 08:14:02PM -0300, Jean Diogo wrote: > The function getspnam() and it's reentrant sister getspnam_r() do not clean > the content of allocated memory before returning to the user, resulting in > the leak of /etc/shadow content. In some cases this might be an issue. There's no reliable way for a program to ensure nothing sensitive is left in memory. However, the library can make a better effort to make it unlikely that password hashes would be left in memory. Like you suggested in another message (somehow detached from this thread), endspent() could be a place to zeroize any knowingly cached sensitive data, although it would only be usable that way by programs, not by higher-level libraries where thread-safety matters. > Let me put ProFTPd as an example: it's daemon starts as root, when it > receives a connection it forks, opens all the files that it'll need, then > it calls getspnam with the provided FTP user to validate the provided > password. Later on it setreuid(nobody) abandoning root privileges . Here > it doesn't matter whether it calls getspnam or getspnam_r, the malloced > buffer will remain on heap memory (and it's pointer in libc <buffer> and > <respbuf>, I suppose). So now the child process is running on a low > privileged user and has a copy of /etc/shadow on it's heap memory. > The vulnerability CVE-2020-9273  (an use-after-free on heap) allowed me > to get RCE on ProFTPd, in an exploit I created last year. Additionally, > thanks to getspnam caching it is possible to read the root cryptogram (and > other users). > > I'm not suggesting that ProFTPd architecture is correct . The problem is > that even if ProFTPd calls getspnam_r it has no mechanism to zero the cache > before forking, since internal pointers are not known to the user (read > developer). >  - It is a good programming practice to exec right after fork. An alternative programming practice is to fork() a child process for authentication, then let that child process (with sensitive data in it) terminate and have the service proceed to authenticated state (with nothing from /etc/shadow having ever been loaded into its memory). This is what I implemented in popa3d from the start, see its auth_shadow.c and DESIGN: startup as root | ----------------- |child |parent v v drop to user popa3d, still as root, handle the AUTHORIZATION wait for and state, write the results, - - > read the authentication and exit information | ----------------- |child |parent v v getspnam(3), crypt(3), wait for and check, write the result, - - > read the authentication and exit (to clean up) result | v drop to the authenticated user, handle the TRANSACTION state, possibly UPDATE the mailbox, and exit This is also what we have in pam_tcb, enabled with the "fork" option: fork Create child processes for accessing shadow files. Using this option one can be sure that after a call to pam_end(3) there is no sensitive data left in the process' address space. However, this option may confuse some of the more complicated applica- tions and it has some performance overhead. Maybe we should finally get pam_tcb into Linux-PAM, now that it no longer depends on custom glibc patches since libxcrypt finally provides our crypt_gensalt*() API. Maybe we can have it fully replace pam_unix in there, just like it had on Owl and ALT Linux 20 years ago. Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.