** Please note that this issue is confidential and no information should be
disclosed until it is made public, see "Whiteboard" for a date **
dstat includes the current working directory and the "profile"
subdirectory in the sys.path. This will lead to a compromise of an
account (execution of arbitrary code) if a user runs "dstat" in a
directory that is writable by an attacker (e.g. /tmp) and an attacker
places certain Python modules in the directory (e.g. getopt.py).
I have investigated the dstat history and found that at least versions
since SVN r3464 are vulnerable from this. Earlier, dstat determined the
absolute path of the dstat executable and only added its dirname.
However, versions before 3199 had today's logic of using '.' as the
path to import.
Created attachment 210507 [details]
Created attachment 210509 [details, diff]
Arch Security Liaisons, please test the attached ebuild and report it stable on this bug.
Target keywords : "amd64 hppa sparc x86"
CC'ing current Liaisons:
amd64 : keytoaster, chainsaw
hppa : jer
sparc : armin76, tcunha
x86 : fauli, maekke
HPPA is OK.
I have been running on amd64 with the patch for a while as well. so amd64 stable.
0.7.0 is released and contains the fix:
0.6.9-r1 is committed. This bug is now public.
A second CVE identifier has been assigned to the "same" vulnerability in old versions. So we get:
CVE-2009-4081 : r???? <-> r3199
CVE-2009-3894 : r3464 <-> r8040
Multiple untrusted search path vulnerabilities in dstat before 0.7.0
allow local users to gain privileges via a Trojan horse Python module
in (1) the current working directory or (2) a certain subdirectory of
the current working directory.
Untrusted search path vulnerability in dstat before r3199 allows
local users to gain privileges via a Trojan horse Python module in
the current working directory, a different vulnerability than