| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0001-gpasswd-1-Fix-password-leak.patch | [PATCH] gpasswd(1): Fix password leak How to trigger this password leak? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When gpasswd(1) asks for the new password, it asks twice (as is usual for confirming the new password). Each of those 2 password prompts uses agetpass() to get the password. If the second agetpass() fails, the first password, which has been copied into the 'static' buffer 'pass' via STRFCPY(), wasn't being zeroed. agetpass() is defined in <./libmisc/agetpass.c> (around line 91), and can fail for any of the following reasons: - malloc(3) or readpassphrase(3) failure. These are going to be difficult to trigger. Maybe getting the system to the limits of memory utilization at that exact point, so that the next malloc(3) gets ENOMEM, and possibly even the OOM is triggered. About readpassphrase(3), ENFILE and EINTR seem the only plausible ones, and EINTR probably requires privilege or being the same user; but I wouldn't discard ENFILE so easily, if a process starts opening files. - The password is longer than PASS_MAX. The is plausible with physical access. However, at that point, a keylogger will be a much simpler attack. And, the attacker must be able to know when the second password is being introduced, which is not going to be easy. How to read the password after the leak? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Provoking the leak yourself at the right point by entering a very long password is easy, and inspecting the process stack at that point should be doable. Try to find some consistent patterns. Then, search for those patterns in free memory, right after the victim leaks their password. Once you get the leak, a program should read all the free memory searching for patterns that gpasswd(1) leaves nearby the leaked password. On 6/10/23 03:14, Seth Arnold wrote: > An attacker process wouldn't be able to use malloc(3) for this task. > There's a handful of tools available for userspace to allocate memory: > > - brk / sbrk > - mmap MAP_ANONYMOUS > - mmap /dev/zero > - mmap some other file > - shm_open > - shmget > > Most of these return only pages of zeros to a process. Using mmap of an > existing file, you can get some of the contents of the file demand-loaded > into the memory space on the first use. > > The MAP_UNINITIALIZED flag only works if the kernel was compiled with > CONFIG_MMAP_ALLOW_UNINITIALIZED. This is rare. > > malloc(3) doesn't zero memory, to our collective frustration, but all the > garbage in the allocations is from previous allocations in the current > process. It isn't leftover from other processes. > > The avenues available for reading the memory: > - /dev/mem and /dev/kmem (requires root, not available with Secure Boot) > - /proc/pid/mem (requires ptrace privileges, mediated by YAMA) > - ptrace (requires ptrace privileges, mediated by YAMA) > - causing memory to be swapped to disk, and then inspecting the swap > > These all require a certain amount of privileges. How to fix it? ~~~~~~~~~~~~~~ memzero(), which internally calls explicit_bzero(3), or whatever alternative the system provides with a slightly different name, will make sure that the buffer is zeroed in memory, and optimizations are not allowed to impede this zeroing. This is not really 100% effective, since compilers may place copies of the string somewhere hidden in the stack. Those copies won't get zeroed by explicit_bzero(3). However, that's arguably a compiler bug, since compilers should make everything possible to avoid optimizing strings that are later passed to explicit_bzero(3). But we all know that sometimes it's impossible to have perfect knowledge in the compiler, so this is plausible. Nevertheless, there's nothing we can do against such issues, except minimizing the time such passwords are stored in plain text. Security concerns ~~~~~~~~~~~~~~~~~ We believe this isn't easy to exploit. Nevertheless, and since the fix is trivial, this fix should probably be applied soon, and backported to all supported distributions, to prevent someone else having more imagination than us to find a way. Affected versions ~~~~~~~~~~~~~~~~~ All. Bug introduced in shadow 19990709. That's the second commit in the git history. |
Alejandro Colomar <alx@kernel.org> | no | 2023-06-10 | ||
| 0002-Added-control-character-check.patch | [PATCH] Added control character check Added control character check, returning -1 (to "err") if control characters are present. |
tomspiderlabs <128755403+tomspiderlabs@users.noreply.github.com> | no | 2023-03-23 | ||
| 0003-Overhaul-valid_field.patch | [PATCH] Overhaul valid_field() e5905c4b ("Added control character check") introduced checking for control characters but had the logic inverted, so it rejects all characters that are not control ones. Cast the character to `unsigned char` before passing to the character checking functions to avoid UB. Use strpbrk(3) for the illegal character test and return early. |
=?UTF-8?q?Christian=20G=C3=B6ttsche?= <cgzones@googlemail.com> | no | 2023-03-31 | ||
| 008_login_log_failure_in_FTMP | Notes: * I'm not sure login should add an entry in the FTMP file when PAM is used. (but nothing in /etc/login.defs indicates that the failure is not logged) |
no | ||||
| 401_cppw_src.dpatch | #! /bin/sh /usr/share/dpatch/dpatch-run ## 401_cppw_src.dpatch by Nicolas FRANCOIS <nicolas.francois@centraliens.net> ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: Add cppw / cpgr @DPATCH@ |
no | ||||
| 402_cppw_selinux | Fix: Status wrt upstream: cppw is not available upstream. The patch was made based on the 302_vim_selinux_support patch. It needs to be reviewed by an SE-Linux aware person. Depends on 401_cppw_src.dpatch =================================================================== |
no | ||||
| 429_login_FAILLOG_ENAB | compiled with PAM and when FAILLOG_ENAB is set to yes. And create the faillog file if it does not exist on postinst (as on Woody). preceding a successful login. |
no | ||||
| 463_login_delay_obeys_to_PAM | job to set a delay...or not Status wrt upstream: Forwarded but not applied yet |
no | ||||
| 501_commonio_group_shadow | no | |||||
| 502_debian_useradd_defaults | Keep using Debian's adduser defaults Upstream's bbf4b79bc49fd1826eb41f6629669ef0b647267b commit in 4.9 merged those values from upstream's default configuration file which is not shipped in Debian. This patch keeps the program's compiled in defaults in sync with the configuration files shipped in Debian (debian/default/useradd). |
Balint Reczey <balint@balintreczey.hu> | not-needed | debian upstream | ||
| 503_shadowconfig.8 | Status wrt upstream: The shadowconfig utility is debian specific. Its man page also (but it used to be distributed) =================================================================== |
no | ||||
| 505_useradd_recommend_adduser | Status wrt upstream: Debian specific patch. | no | ||||
| 506_relaxed_usernames | Status wrt upstream: Debian specific. Not to be used upstream Details: Allows any non-empty user/grounames that don't contain ':', ',' or '\n' characters and don't start with '-', '+', or '~'. This patch is more restrictive than original Karl's version. closes: #264879 Also closes: #377844 Comments from Karl Ramm (shadow 1:4.0.3-9, 20 Aug 2003 02:06:50 -0400): I can't come up with a good justification as to why characters other than ':'s and '\0's should be disallowed in group and usernames (other than '-' as the leading character). Thus, the maintenance tools don't anymore. closes: #79682, #166798, #171179 |
no | ||||
| 542_useradd-O_option | Status wrt upstream: not included as this is just specific backward compatibility for Debian |
no |