Message-ID: <68C42880410B417EA93ABC7334EB938C@W340>
Date: Fri, 25 Dec 2015 02:33:20 +0100
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: <fulldisclosure@...lists.org>
Subject: Re: [FD] Executable installers are vulnerable^WEVIL (case 15):
	F-SecureOnlineScanner.exe allows arbitrary (remote) code
	execution and escalation of privilege

"Shawn McMahon" <syberghost@...il.com> wrote:

> On Wed, Dec 23, 2015 at 7:13 AM, Stefan Kanthak <stefan.kanthak@...go.de>
> wrote:
> 
>> Hi @ll,
>>
>> F-Secure's online virus scanner F-SecureOnlineScanner.exe, available
>> via <https://www.f-secure.com/en/web/home_global/online-scanner>,
>> loads and executes several rogue/bogus DLLs (UXTheme.dll, HNetCfg.dll,
>> RASAdHlp.dll, SetupAPI.dll, ClbCatQ.dll, XPSP2Res.dll, CryptNet.dll,
>> OLEAcc.dll etc.) eventually found in the directory it is started from
>> (the "application directory").
>>
> 
> How long are you going to keep whacking these moles before you admit that
> this is an OS problem, not an apps problem, and that Microsoft needs to fix
> it?

0. why was F-Secure able to fix their bugs in their program?

1. which of the DLLs are loaded by the OS, which are loaded by their program?

2. what's (not) wrong with
   a) the OS?
   b) <https://blogs.msdn.microsoft.com/oldnewthing/20101111-00/?p=12303>?
   c) ALL executable installers and self-extractors?
   d) <https://cwe.mitre.org/data/definitions/426.html> and
      <https://cwe.mitre.org/data/definitions/427.html>?
   e) <https://capec.mitre.org/data/definitions/471.html>?
   f) <https://cwe.mitre.org/data/definitions/377.html> and
      <https://cwe.mitre.org/data/definitions/379.html>?
   g) <https://msdn.microsoft.com/en-us/library/ms682586.aspx> and
      <https://msdn.microsoft.com/en-us/library/ff919712.aspx>?
   h) <https://support.microsoft.com/en-us/kb/2389418> and
      <https://support.microsoft.com/en-us/kb/2533623>?
   i) <https://support.microsoft.com/en-us/kb/2264107>?
   j) <https://msdn.microsoft.com/en-us/library/hh310515.aspx>?


Windows has the concept of the "application directory" from its
very beginning: an application with all its (private) DLLs and
other satellites is stored/installed/bundled in a directory.

Every developer/vendor who publishes an installation program but
doesn't take into account that he has ABSOLUTELY NO control over
the application directory and does NOT follow Microsoft's guidance
referenced above to prevent havoc acts grossly negligent.


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.


Microsoft CAN'T change the DLL search path order to exclude the
application directory without breaking MANY existing applications.

ONLY the developer of an application knows whether his application
is supposed to load DLLs from its application directory, the system
directory, the current working directory or any other directory from
the PATH.
He can and SHOULD respectively MUST use fully-qualified pathnames in
EVERY call to LoadLibrary(), CreateProcess() etc.
He can and SHOULD respectively MUST call SetDefaultDllDirectories()
and SetDllDirectory() with the appropriate arguments to exclude all
the directories his application is not supposed to load DLLs from from
the DLL search order, ESPECIALLY if he can't control the environment
where users start his application.


Developers/vendors who can't fix their installations programs SHOULD
respectively MUST withdraw them: they know their vulnerabilities!


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