Bug#948108: unrar corrupts filenames given as arguments
Package: unrar Version: 1:5.6.6-2 Severity: normal Dear Maintainer, when passing certain (archive) filenames to unrar, unrar will corrupt them and not be able to open them. The peculiar way this corruption occurs hints at possible security issues. Example: strace -feexecve,stat perl -e 'system "unrar", "x", "x\x92.rar"' Outputs, among other things: [pid 9326] execve("/bin/unrar", ["unrar", "x", "x\222.rar"], 0x557679f0 /* 112 vars */) = 0 [pid 9326] stat("x\222.ra", 0x7ffef1d0) = -1 ENOENT (No such file or directory) Cannot open x�.ra (the later filename is written like this): [pid 9390] write(2, "x", 1x)= 1 [pid 9390] write(2, "\357\277\276", 3�) = 3 [pid 9390] write(2, "\356\202\222", 3) = 3 [pid 9390] write(2, ".", 1.)= 1 [pid 9390] write(2, "r", 1r)= 1 [pid 9390] write(2, "a", 1a)= 1 [pid 9390] write(2, "\nN", 2 So somehow the \x92 character gets replaced, but also the trailing "r" (from rar) is removed. This happened in a utf-8 based locale (en_DK.UTF-8), which is probably related. Obviously, unrar should not mangle filenames, as filenames are octet-strings, not locale-encoded. -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.4.7-050407-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages unrar depends on: ii libc6 2.28-10 ii libgcc1 1:9.2.1-15 ii libstdc++6 8.3.0-6 unrar recommends no packages. unrar suggests no packages. -- no debconf information
Bug#948108: unrar corrupts filenames given as arguments
Hi! For some reason I didn't see or receive the reply to this bug report. Anyway, thanks for the explanation, but I am not sure what to make of it - on the one hand, it confirms the bug (unrar incorrectly mangles filenames by trying to recode them), but on the other hand, it's still clearly a bug. And while not as bad as, say, a buffer overflow, this could still have security implications, as unrar will try to process a different file than what the user specified, which could result in unwanted information disclosure. I would agree that this is not a terribly likely scenario, but I don't see a reason why this bug shouldn't get fixed eventually, and I certainly wouldn't call it harmless - I lost some data due to this bug, as some perfectly fine archives were flagged as undecodable due to this spurious error and were deleted before I understood that this is just unrar being broken and not actually a problem in the archives themselves. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#948108: Fwd: Fwd: Bug#948108: unrar corrupts filenames given as arguments
-- Forwarded Message - From: Eugene Roshal Subject: Re: Fwd: Bug#948108: unrar corrupts filenames given as arguments Date: Jan 4 2020, at 8:35 am To: Martin Meredith Hello, RAR expects source parameters in local encoding, but converts them to wchar_t with CharToWide function and uses wchar_t almost everywhere internally. RAR has a feature allowing to archive and extract names not belonging to current locale, such as extended ASCII instead of UTF-8. When RAR CharToWide function notices names which cannot be correctly converted by mbsrtowcs, it calls CharToWideMap to perform per byte conversion and sets the special flag (0xFFFE noncharacter) to tell WideToChar to apply per byte decoding WideToCharMap to such name. While it is intended for names read from and saved to archive, here it is applied to command line parameter, resulting in 0xfffe flag and per byte conversion visible on the screen and producing this mangled name. Since source "x\x92.rar" is 7 bytes length, RAR allocates 7 bytes output buffer for converted wchar_t string. CharToWideMap output is longer than that because of special flag inclusion, so RAR successfully truncates output to buffer size. While such source parameter conversion is useless, it is harmless as well. Truncation is a good sign indicating that RAR cares about buffer size and prevents buffer overflow. Mangled name in output is result of garbage in input instead of expected local encoding. So no reason to worry in my opinion. > Obviously, unrar should not mangle filenames, as filenames are > octet-strings, not locale-encoded. Normally RAR expects locale-encoded names here. Eugene