lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 30 Dec 2015 14:59:46 +0100
From: "Stefan Kanthak" <>
To: <>
Subject: Re: [FD] Executable installers are vulnerable^WEVIL (case
	15):F-SecureOnlineScanner.exe allows arbitrary (remote)
	codeexecution and escalation of privilege

Mitja Kolsek <> wrote:

> Hi Stefan and all,
>> See the "CWDIllegalInDllSearchPath" setting introduced with KB2264107
>> about 5 years ago, after ACROS finally got enough attention for the
>> vulnerability first published as CVE-2000-0854 (that was 15 years ago,
>> but the vulnerability is still present in ALL installation programs):
>> there were^Ware applications that relied^Wy on loading DLLs from the
>> CWD, so Microsoft CAN'T exclude CWD from the PATH.
>> Microsoft can only offer support to exclude the CWD from the DLL search
>> order: developers can call SetDllDirectory(""), administrators can add
>> the global setting "CWDIllegalInDllSearchPath" or add this setting for
>> individual programs.
> While we finally did get CVE-2000-0854 the overdue attention, we apparently
> didn't promote this enough:

About 4 years earlier Microsoft published
<> in response
to <>,
and Will Dormann from CERT/CC published
a little later.

I'd rather say that Microsoft didn't promote
<> and
well enough to all the Windows developers.

About a year later with <>,
both Microsoft and the Windows developers unfortunately focused on
the remote attack vector, but lost sight of the local attack vector
respectively the blended threat from "drive-by downloads" combined
with "DLL hijacking".

OTOH in 2011 Microsoft introduced SetDefaultDllDirectories()
with <> which but
seems largely unknown to almost all developers of executable
installers and self-extractors.

JFTR: until now I only found one executable installer that was not
      susceptible to DLL hijacking. It but uses an unsafe temp
      directory, so: ALL executable installers are vulnerable!

stay tuned
Stefan Kanthak

Sent through the Full Disclosure mailing list
Web Archives & RSS:

Powered by blists - more mailing lists