Hi Ben, all,
On 24/11/2024 20:48, Ben Hutchings wrote:
This isn't a security vulnerability. If an attacker can control
LD_LIBRARY_PATH for a user session then they can already cause
arbitrary code to be run as that user.
I may address this as an issue of robustness, but it's not going to
have a high priority.
I've just spent rather longer than I'd like tracking this down after
being bitten by it on some client systems.
The systems use an encrypted root file system unlocked at boot by clevis
with the TPM2 "pin". They're managed by Uyuni, whose venv-salt-minion
(the "Salt Bundle") ships its own Python and exports LD_LIBRARY_PATH
pointing at its bundled libraries so its interpreter can find them.
Every command the minion runs inherits that, including apt-get and
therefore every maintainer script.
When a kernel upgrade (re-)built the initramfs, copy_exec's ldd resolved
libffi.so.8 to the bundle's copy and installed it in the image as
/usr/lib/venv-salt-minion/lib/libffi.so.8. Nothing sets LD_LIBRARY_PATH
at boot, so tpm2_createprimary exits 127, clevis can't unseal the
keystore, and the machine sits at a passphrase prompt until somebody
unlocks it by typing the password at the console. Rebuilding the
initramfs by hand produces a correct image, which is what made it look
intermittent and sent me on a wild goose chase for several weeks.
I've worked around it for these systems by hacking the Uyuni
venv-salt-minion to unset LD_LIBRARY_PATH before it runs child
processes. The workaround in initramfs-tools looks straightforward, and
copy_exec already does exactly this for LD_PRELOAD:
for x in $(env --unset=LD_PRELOAD ldd "${src}" ...
https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/b6795cfe2545b18b30526deb7b609f74339bd6e0/hook-functions#L266
Presumably you'd just want to add "--unset=LD_LIBRARY_PATH" to that.
Please let me know if you'd like more info or a patch.
Cheers,
Chris
--
Chris Boot
[email protected]
