Mitja Kolsek <li...@acrossecurity.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/