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
Attachment:
signature.asc
Description: PGP signature