Package: locales Version: 2.24-3 Severity: normal File: /usr/sbin/locale-gen Tags: security
While stracing localedef, I noticed this behavior: open("i18n", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/i18n/locales/i18n", O_RDONLY) = 4 There's no chdir; this reads from files in the cwd where locale-gen is run. The original intended use case for localedef was probably to run it in your home directory to generate locales there, so this behavior didn't matter. With locale-gen running it as root, that innocious behavior becomes a potential security hole. So, if root runs locale-gen in eg, /tmp or a user's home directory, it will read files controlled by another user. This could be used to try to exploit localedef and get a shell, or it could be used to feed in valid format but incorrect locale data and mess up the system locales. It may also be possible to exploit this when apt is upgrading locales. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-rc5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.59 ii libc-bin 2.24-3 ii libc-l10n 2.24-3 locales recommends no packages. locales suggests no packages. -- debconf information: * locales/locales_to_be_generated: de_DE.UTF-8 UTF-8, en_CA.UTF-8 UTF-8, en_US ISO-8859-1, en_US.UTF-8 UTF-8, es_ES.UTF-8 UTF-8, et_EE.UTF-8 UTF-8, fr_FR.UTF-8 UTF-8, ru_RU.UTF-8 UTF-8 * locales/default_environment_locale: None -- see shy jo
signature.asc
Description: PGP signature