lists.openwall.net   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  linux-cve-announce  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]
Message-ID: <E0FC0D44A7194F30974515450FCEC1B3@W340>
Date: Wed, 30 Dec 2015 14:59:46 +0100
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: <lists@...ossecurity.com>
Cc: fulldisclosure@...lists.org
Subject: Re: [FD] Executable installers are vulnerable^WEVIL (case
	15):F-SecureOnlineScanner.exe allows arbitrary (remote)
	codeexecution and escalation of privilege

Mitja Kolsek <lists@...ossecurity.com> 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:
> http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html

About 4 years earlier Microsoft published
<https://technet.microsoft.com/en-us/library/953818.aspx> in response
to <http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2540>,
and Will Dormann from CERT/CC published
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>
a little later.

I'd rather say that Microsoft didn't promote
<https://technet.microsoft.com/en-us/library/953818.aspx>,
<https://technet.microsoft.com/en-us/library/ms09-015.aspx>,
<https://support.microsoft.com/en-us/kb/959426> and
<http://blogs.technet.com/b/srd/archive/2009/04/14/ms09-014-addressing-the-safari-carpet-bomb-vulnerability.aspx>
well enough to all the Windows developers.

About a year later with <http://www.binaryplanting.com>,
<http://blogs.technet.com/b/srd/archive/2010/08/31/an-update-on-the-dll-preloading-remote-attack-vector.aspx>
and
<http://blogs.technet.com/b/srd/archive/2010/08/23/more-information-about-dll-preloading-remote-attack-vector.aspx>
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 <https://support.microsoft.com/en-us/kb/2533623> 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
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ