Bug#948108: unrar corrupts filenames given as arguments

[Marc Lehmann]

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

[Marc Lehmann]

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

[Martin Meredith]

-- 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