[Full-disclosure] Defense in depth -- the Microsoft way (part 14): incomplete, misleading and dangerous documentation
Hi @ll, here's another (well-known, but undocumented) idiosyncrasy of Windows' CreateProcess*() functions with a nice side-effect:-P From http://msdn.microsoft.com/library/ms682425.aspx: | BOOL WINAPI CreateProcess( | _In_opt_ LPCTSTR lpApplicationName, | _Inout_opt_ LPTSTR lpCommandLine, ... | To run a batch file, you must start the command interpreter; set | lpApplicationName to cmd.exe and set lpCommandLine to the following | arguments: /c plus the name of the batch file. This is but wrong (and of course dangerous too: you should NEVER set lpApplicationName to an unqualified filename, but ALWAYS use the fully qualified pathname; see http://support.microsoft.com/kb/2269637 and http://support.microsoft.com/kb/2389418)! Now the REAL behaviour (of Windows NT4, Windows NT5.x, Windows NT6.x): CreateProcess(pathname.cmd, ...) CreateProcess(pathname.bat, ...) CreateProcess(NULL, pathname.cmd[ ...], ...) CreateProcess(NULL, pathname.bat[ ...], ...) (and of course CreateProcessAsUser(), CreateProcessWithLogonW() and CreateProcessWithTokenW() too) execute a rogue program CMD.EXE from the 'application directory' (i.e. the directory where the program that calls CreateProcess*() is located) instead of the expected %COMSPEC% alias %SystemRoot%\System32\cmd.exe, with the command line set to cmd /c \pathname.cmd\ resp. cmd /c pathname.cmd[ ...]. From http://msdn.microsoft.com/library/ms682425.aspx: | lpCommandLine [in, out, optional] ... | If the file name does not contain an extension, .exe is appended. ... | If the file name does not contain a directory path, the system | searches for the executable file in the following sequence: | 1. The directory from which the application loaded. | 2. The current directory for the parent process. | 3. The 32-bit Windows system directory. ... JFTR: ShellExecute*() calls CreateProcess*() to start pathname.bat and pathname.cmd, so Windows Explorer (and of course any other program calling ShellExecute*() too) start CMD.EXE from their 'application directory' or the 'current working directory' too.-( The 'application directory' of Windows Explorer is %SystemRoot%, and Windows Explorer sets the 'current working directory' to the path of the file to be opened. %SystemRoot%\System32\CMD.EXE is found via the documented search path ... until someone creates a CMD.EXE in %SystemRoot% or the 'current working directory' (i.e. the directory where filename.bat or filename.cmd is located). FIX (for ShellExecute*() and Windows Explorer): change the value of the default registry entries of [HKEY_CLASSES_ROOT\batfile] and [HKEY_CLASSES_ROOT\cmdfile] from @=%1 %* to @=expand:%SystemRoot%\\System32\\cmd.exe /C Call \%L\ %* or @=expand:\%COMSPEC%\ /C Call \%L\ %* Additionally, see http://support.microsoft.com/kb/905890 as well as http://msdn.microsoft.com/library/aa365527.aspx and set [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager] SafeProcessSearchMode=dword:0001 stay tuned Stefan Kanthak PS: when filename.bat or filename.cmd are started from Windows Explorer the console window of the new process shows the icon of the CMD.EXE found in the 'current working directory' (i.e. the directory where filename.bat or filename.cmd is located), not the icon of the command processor %SystemRoot%\System32\cmd.exe ... independent of the above mentioned fixes! But that's just another of Windows' many idiosyncrasies! Timeline: ~ 2013-10-23informed vendor 2013-10-24vendor replies: see http://msdn.microsoft.com/library/ff919712.aspx OUCH! 2013-10-24NO, this does NOT describe the behaviour of CreateProcess() or ShellExecute() for *.CMD and *.BAT 2013-10-24vendor replies: MSRC case 15734 opened ... 2013-11-18requested status from vendor 2013-11-24no answer, report published ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Defense in depth -- the Microsoft way (part 13): surprising and inconsistent behaviour, sloppy coding, sloppy QA, sloppy documentation
Hi @ll, the Win32 API is full of idiosyncrasies resp. surprising and inconsistent, poorly tested and documented behaviour. Just to pick one: NULL pointer as string argument. 0. lstrlen(NULL) lstrcat(NULL, ...) and lstrcat(..., NULL) lstrcmp(NULL, ...) and lstrcmp(..., NULL) lstrcmpi(NULL, ...) and lstrcmpi(..., NULL) lstrcpy(NULL, ...) and lstrcpy(..., NULL) lstrcpyn(NULL, ..., 0) and lstrcpy(..., NULL, ...) do not yield an exception, but treat their NULL arguments like an empty string (when used as source), resp. return NULL (when used as destination). 1. wsprintf(NULL, ...) and wvsprintf(NULL, ...) wsprintf(..., NULL, ...) and wvsprintf(..., NULL, ...) yield an access violation in USER32.DLL. 2. CommandLineToArgvW(NULL, ...) yields an access violation in SHELL32.DLL. 3. CreateProcess(NULL, NULL, ...) CreateProcessAsUser(..., NULL, NULL, ...) CreateProcessWithLogonW(..., ..., ..., ..., NULL, NULL, ...) CreateProcessWithTokenW(..., ..., NULL, NULL, ...) yield an access violation in KERNEL32.DLL. 4. GetFileAttributes(NULL) does not yield an exception, but treats the NULL argument like an empty string. 5. GetBinaryType(NULL, ...) does not yield an exception, but treats the NULL argument like an empty string. 6. MessageBox(..., NULL, ...) and MessageBox(..., ..., NULL, ...) do not yield an exception, but treat the NULL argument like an empty string. 7. FatalAppExit(0, NULL) does not yield an exception, but treats the NULL argument like an empty string. 8. GetCurrentDirectory(..., NULL) returns an error if the buffer size (the argument shown as ... here) is sufficient to hold the result, else the required buffer size. GetTempPath(..., NULL) GetSystemDirectory(NULL, ...) GetSystemWindowsDirectory(NULL, ...) GetSystemWow64Directory(NULL, ...) GetWindowsDirectory(NULL, ...) GetComputerName(NULL, ...) yield an access violation in NTDLL.DLL resp. KERNEL32.DLL if the buffer size is sufficient to hold the result, else the required buffer size. GetUserName(NULL, ...) GetComputerObjectName(..., NULL, ...) do not yield an access violation, but return an error with GetLastError() == ERROR_INSUFFICIENT_BUFFER. 9. GetUserName(NULL, NULL) GetComputerName(NULL, NULL) yield an access violation in KERNEL32.DLL. GetComputerNameEx(..., NULL, NULL) GetComputerObjectName(..., NULL, NULL) do not yield an access violation, but return an error with GetLastError() == ERROR_INVALID_PARAMETER. JFTR: only the documentation of the last function (see http://msdn.microsoft.com/en-us/library/ms724301.aspx) explicitly says about the value of the third argument If lpBuffer is NULL, this parameter must be zero. and checks this contraint properly. The expected behavior in all cases is but to return an error with GetLastError() == ERROR_INVALID_PARAMETER or similar. FIX: ALL interfaces of the Win32 API should^WMUST verify (ALL) their arguments properly before using them and return an appropriate, documented error code. stay tuned Stefan Kanthak ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 13): surprising and inconsistent behaviour, sloppy coding, sloppy QA, sloppy documentation
This may be a silly question, so I apologize in advance, but that would exactly be the advantage here? Using a NULL pointer is in most (if not all) those cases undocumented behavior to begin with. Unless I'm missing something, the problem is not so much with Win32 as it is with the C language in general... On Sun, Nov 3, 2013 at 4:30 PM, Stefan Kanthak stefan.kant...@nexgo.dewrote: Hi @ll, the Win32 API is full of idiosyncrasies resp. surprising and inconsistent, poorly tested and documented behaviour. Just to pick one: NULL pointer as string argument. 0. lstrlen(NULL) lstrcat(NULL, ...) and lstrcat(..., NULL) lstrcmp(NULL, ...) and lstrcmp(..., NULL) lstrcmpi(NULL, ...) and lstrcmpi(..., NULL) lstrcpy(NULL, ...) and lstrcpy(..., NULL) lstrcpyn(NULL, ..., 0) and lstrcpy(..., NULL, ...) do not yield an exception, but treat their NULL arguments like an empty string (when used as source), resp. return NULL (when used as destination). 1. wsprintf(NULL, ...) and wvsprintf(NULL, ...) wsprintf(..., NULL, ...) and wvsprintf(..., NULL, ...) yield an access violation in USER32.DLL. 2. CommandLineToArgvW(NULL, ...) yields an access violation in SHELL32.DLL. 3. CreateProcess(NULL, NULL, ...) CreateProcessAsUser(..., NULL, NULL, ...) CreateProcessWithLogonW(..., ..., ..., ..., NULL, NULL, ...) CreateProcessWithTokenW(..., ..., NULL, NULL, ...) yield an access violation in KERNEL32.DLL. 4. GetFileAttributes(NULL) does not yield an exception, but treats the NULL argument like an empty string. 5. GetBinaryType(NULL, ...) does not yield an exception, but treats the NULL argument like an empty string. 6. MessageBox(..., NULL, ...) and MessageBox(..., ..., NULL, ...) do not yield an exception, but treat the NULL argument like an empty string. 7. FatalAppExit(0, NULL) does not yield an exception, but treats the NULL argument like an empty string. 8. GetCurrentDirectory(..., NULL) returns an error if the buffer size (the argument shown as ... here) is sufficient to hold the result, else the required buffer size. GetTempPath(..., NULL) GetSystemDirectory(NULL, ...) GetSystemWindowsDirectory(NULL, ...) GetSystemWow64Directory(NULL, ...) GetWindowsDirectory(NULL, ...) GetComputerName(NULL, ...) yield an access violation in NTDLL.DLL resp. KERNEL32.DLL if the buffer size is sufficient to hold the result, else the required buffer size. GetUserName(NULL, ...) GetComputerObjectName(..., NULL, ...) do not yield an access violation, but return an error with GetLastError() == ERROR_INSUFFICIENT_BUFFER. 9. GetUserName(NULL, NULL) GetComputerName(NULL, NULL) yield an access violation in KERNEL32.DLL. GetComputerNameEx(..., NULL, NULL) GetComputerObjectName(..., NULL, NULL) do not yield an access violation, but return an error with GetLastError() == ERROR_INVALID_PARAMETER. JFTR: only the documentation of the last function (see http://msdn.microsoft.com/en-us/library/ms724301.aspx) explicitly says about the value of the third argument If lpBuffer is NULL, this parameter must be zero. and checks this contraint properly. The expected behavior in all cases is but to return an error with GetLastError() == ERROR_INVALID_PARAMETER or similar. FIX: ALL interfaces of the Win32 API should^WMUST verify (ALL) their arguments properly before using them and return an appropriate, documented error code. stay tuned Stefan Kanthak ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- “There's a reason we separate military and the police: one fights the enemy of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state tend to become the people.” ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 13): surprising and inconsistent behaviour, sloppy coding, sloppy QA, sloppy documentation
Mario Vilas mvi...@gmail.com wrote: This may be a silly question, so I apologize in advance, but that would exactly be the advantage here? Using a NULL pointer is in most (if not all) those cases undocumented behavior to begin with. Unless I'm missing something, the problem is not so much with Win32 as it is with the C language in general... For many of the Win32 functions I referenced here the behaviour of a NULL pointer is but documented: http://msdn.microsoft.com/en-us/library/ms647492.aspx | If lpString is NULL, the function returns 0. JFTR: I suspect that this is the reason why most of the other functions treat a NULL pointer as an empty string. http://msdn.microsoft.com/en-us/library/ms647487.aspx http://msdn.microsoft.com/en-us/library/ms647490.aspx http://msdn.microsoft.com/en-us/library/ms647491.aspx | When this function catches SEH errors, it returns NULL without null- | terminating the string and without notifying the caller of the error. http://msdn.microsoft.com/en-us/library/ms682425.aspx | BOOL WINAPI CreateProcess( | _In_opt_ LPCTSTR lpApplicationName, | _Inout_opt_ LPTSTR lpCommandLine, BOTH string arguments may be NULL! Idem for the other CreateProcess*() functions. http://msdn.microsoft.com/en-us/library/ms645505.aspx | The dialog box title. If this parameter is NULL, the default title is Error. http://msdn.microsoft.com/en-us/library/aa364934.aspx | To determine the required buffer size, set this parameter to NULL and the | nBufferLength parameter to 0. Most of the Get*() functions return the required buffer size when the size argument is 0 (or to small), but only http://msdn.microsoft.com/en-us/library/ms724301.aspx explicitly says: | If lpBuffer is NULL, this parameter must be zero. and checks this contraint properly. The problem is not the C language! The problem is the inconsistent (and sloppy) implemenation of similar functions of the Win32 API and their inconsistent and sloppy documentation. regards Stefan Kanthak On Sun, Nov 3, 2013 at 4:30 PM, Stefan Kanthak stefan.kant...@nexgo.dewrote: Hi @ll, the Win32 API is full of idiosyncrasies resp. surprising and inconsistent, poorly tested and documented behaviour. Just to pick one: NULL pointer as string argument. 0. lstrlen(NULL) lstrcat(NULL, ...) and lstrcat(..., NULL) lstrcmp(NULL, ...) and lstrcmp(..., NULL) lstrcmpi(NULL, ...) and lstrcmpi(..., NULL) lstrcpy(NULL, ...) and lstrcpy(..., NULL) lstrcpyn(NULL, ..., 0) and lstrcpy(..., NULL, ...) do not yield an exception, but treat their NULL arguments like an empty string (when used as source), resp. return NULL (when used as destination). 1. wsprintf(NULL, ...) and wvsprintf(NULL, ...) wsprintf(..., NULL, ...) and wvsprintf(..., NULL, ...) yield an access violation in USER32.DLL. 2. CommandLineToArgvW(NULL, ...) yields an access violation in SHELL32.DLL. 3. CreateProcess(NULL, NULL, ...) CreateProcessAsUser(..., NULL, NULL, ...) CreateProcessWithLogonW(..., ..., ..., ..., NULL, NULL, ...) CreateProcessWithTokenW(..., ..., NULL, NULL, ...) yield an access violation in KERNEL32.DLL. 4. GetFileAttributes(NULL) does not yield an exception, but treats the NULL argument like an empty string. 5. GetBinaryType(NULL, ...) does not yield an exception, but treats the NULL argument like an empty string. 6. MessageBox(..., NULL, ...) and MessageBox(..., ..., NULL, ...) do not yield an exception, but treat the NULL argument like an empty string. 7. FatalAppExit(0, NULL) does not yield an exception, but treats the NULL argument like an empty string. 8. GetCurrentDirectory(..., NULL) returns an error if the buffer size (the argument shown as ... here) is sufficient to hold the result, else the required buffer size. GetTempPath(..., NULL) GetSystemDirectory(NULL, ...) GetSystemWindowsDirectory(NULL, ...) GetSystemWow64Directory(NULL, ...) GetWindowsDirectory(NULL, ...) GetComputerName(NULL, ...) yield an access violation in NTDLL.DLL resp. KERNEL32.DLL if the buffer size is sufficient to hold the result, else the required buffer size. GetUserName(NULL, ...) GetComputerObjectName(..., NULL, ...) do not yield an access violation, but return an error with GetLastError() == ERROR_INSUFFICIENT_BUFFER. 9. GetUserName(NULL, NULL) GetComputerName(NULL, NULL) yield an access violation in KERNEL32.DLL. GetComputerNameEx(..., NULL, NULL) GetComputerObjectName(..., NULL, NULL) do not yield an access violation, but return an error with GetLastError() == ERROR_INVALID_PARAMETER. JFTR: only the documentation of the last function (see http://msdn.microsoft.com/en-us/library/ms724301.aspx) explicitly says about the value of the third argument If lpBuffer is NULL, this parameter
Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 9): erroneous documentation
I am truly shocked that seemingly, stuff like this needs to be said in the year of 2013. Completely right! I'd have supposed that things like these should be known by *anyone* doing anything even remotely similar to software development *at least* since the end of the 8.3 filename era 15 years ago. Again: completely right! Are you sure this is real and not a prank? o_O This is real: see https://support.microsoft.com/kb/2781197 alias http://technet.microsoft.com/security/bulletin/ms13-034 or http://seclists.org/fulldisclosure/2013/May/10 for exactly this stuff. And dont forget to read http://seclists.org/fulldisclosure/2013/Aug/75 as well as http://seclists.org/fulldisclosure/2013/May/14 Also see https://bugzilla.mozilla.org/show_bug.cgi?id=871084, https://bugzilla.mozilla.org/show_bug.cgi?id=786407 and https://bugzilla.mozilla.org/show_bug.cgi?id=868746 and notice especially how a Mozilla developer tries to weazel and ignore http://msdn.microsoft.com/ibrary/ms997548.aspx! JFTR: Windows is the ONLY system that covers such silly beginners errors due to the documented idiosyncrasy of CreateProcess() (see http://msdn.microsoft.com/library/ms682425.aspx). Finally take a look at the registry subkey [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall] of your own Windows installation (if you have one): you'll most probably find unquoted pathnames in UninstallString, for example: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\SumatraPDF] UninstallString=C:\\Program Files\\SumatraPDF\\uninstall.exe regards Stefan regards Pascal Ernster [ fullquote removed ] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Defense in depth -- the Microsoft way (part 9): erroneous documentation
Hi,
in http://seclists.org/fulldisclosure/2013/Aug/75 I documented
beginners errors (unquoted pathnames containing spaces) not only
in Microsoft products.
Microsofts developer documentation but shows these beginners errors
too (and is inconsistent, even in single topics).
Examples:
http://msdn.microsoft.com/library/cc144171.aspx
| HKEY_CLASSES_ROOT
| txtile
...
| Shell
...
| cmd2
...
| command
|(Default) = C:\Program Files\Windows
NT\Accessories\wordpad.exe %1
~~~ ~~
http://msdn.microsoft.com/library/bb165967.aspx
| [HKEY_CLASSES_ROOT\Applications\VSLauncher.exe\Shell\Open\Command]
| @=C:\\Program Files\\Common Files\\Microsoft Shared\\MSEnv\\VSLauncher.exe
\%1\
| [HKEY_CLASSES_ROOT\VisualStudio.csproj.8.0\shell\Open\Command]
| @=\C:\\Program Files\\Common Files\\Microsoft
Shared\\MSEnv\\VSLauncher.exe\ \%1\
http://msdn.microsoft.com/library/cc144083.aspx
| HKEY_LOCAL_MACHINE
| SOFTWARE
| Classes
| contoso-search
|shell
| open
| command
| (Default) =
%ProgramFiles%\Contoso\Search\contososearch.exe %1
~~~ ~~
http://msdn.microsoft.com/library/cc144154.aspx
| HKEY_LOCAL_MACHINE
| SOFTWARE
| Classes
| LitwarePlayer11.AssocFile
...
|shell
| open
| command
| (Default) = %ProgramFiles%\Litware\litware.exe
~~
http://msdn.microsoft.com/library/hh127450.aspx
| HKEY_CLASSES_ROOT
| CLSID
| {0052D9FC-6764-4D29-A66F-2F3BD9E2BB40}
| Shell
|Open
| Command
| (Default) = [REG_EXPAND_SZ] %ProgramFiles%\MyCorp\MyApp.exe
/Settings
~~~
http://msdn.microsoft.com/library/cc144188.aspx
| sh:task id={3B75A7AE-C4E4-4E5A-9420-7CECCDA75425}
|!-- This is a generated GUID, specific to this task link --
|sh:name@myTextResources.dll,-100/sh:name
|sh:keywords@myTextResources.dll,-101/sh:keywords
|sh:command%ProgramFiles%\Microsoft
Games\Solitaire\solitaire.exe/sh:command
~~
| /sh:task
Example with ambiguous/inconsistent use of quotes:
http://msdn.microsoft.com/en-us/library/aa767914.aspx
| HKEY_CLASSES_ROOT
| alert
| (Default) = URL:Alert Protocol
^ ^
| URL Protocol =
^^
| DefaultIcon
| (Default) = alert.exe,1
^ ^
| shell
| open
|command
| (Default) = C:\Program Files\Alert\alert.exe %1
Counterexamples:
http://msdn.microsoft.com/library/cc144175.aspx
http://msdn.microsoft.com/library/cc144101.aspx
| Note: If any element of the command string contains or might contain
| spaces, it must be enclosed in quotation marks. Otherwise, if the
| element contains a space, it will not parse correctly. For instance,
| My Program.exe starts the application properly. If you use
| My Program.exe without quotation marks, then the system attempts to
| launch My with Program.exe as its first command line argument. You
| should always use quotation marks with arguments such as %1 that are
| expanded to strings by the Shell, because you cannot be certain that
| the string will not contain a space.
http://msdn.microsoft.com/library/dd203067.aspx
http://msdn.microsoft.com/library/cc144109.aspx
regards
Stefan Kanthak
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 9): erroneous documentation
I am truly shocked that seemingly, stuff like this needs to be said in
the year of 2013. I'd have supposed that things like these should be
known by *anyone* doing anything even remotely similar to software
development *at least* since the end of the 8.3 filename era 15 years
ago. Are you sure this is real and not a prank? o_O
regards
Pascal Ernster
On 31.08.2013 12:58, Stefan Kanthak wrote:
Hi,
in http://seclists.org/fulldisclosure/2013/Aug/75 I documented
beginners errors (unquoted pathnames containing spaces) not only
in Microsoft products.
Microsofts developer documentation but shows these beginners errors
too (and is inconsistent, even in single topics).
Examples:
http://msdn.microsoft.com/library/cc144171.aspx
| HKEY_CLASSES_ROOT
| txtile
...
| Shell
...
| cmd2
...
| command
|(Default) = C:\Program Files\Windows
NT\Accessories\wordpad.exe %1
~~~ ~~
http://msdn.microsoft.com/library/bb165967.aspx
| [HKEY_CLASSES_ROOT\Applications\VSLauncher.exe\Shell\Open\Command]
| @=C:\\Program Files\\Common Files\\Microsoft Shared\\MSEnv\\VSLauncher.exe
\%1\
| [HKEY_CLASSES_ROOT\VisualStudio.csproj.8.0\shell\Open\Command]
| @=\C:\\Program Files\\Common Files\\Microsoft
Shared\\MSEnv\\VSLauncher.exe\ \%1\
http://msdn.microsoft.com/library/cc144083.aspx
| HKEY_LOCAL_MACHINE
| SOFTWARE
| Classes
| contoso-search
|shell
| open
| command
| (Default) =
%ProgramFiles%\Contoso\Search\contososearch.exe %1
~~~ ~~
http://msdn.microsoft.com/library/cc144154.aspx
| HKEY_LOCAL_MACHINE
| SOFTWARE
| Classes
| LitwarePlayer11.AssocFile
...
|shell
| open
| command
| (Default) = %ProgramFiles%\Litware\litware.exe
~~
http://msdn.microsoft.com/library/hh127450.aspx
| HKEY_CLASSES_ROOT
| CLSID
| {0052D9FC-6764-4D29-A66F-2F3BD9E2BB40}
| Shell
|Open
| Command
| (Default) = [REG_EXPAND_SZ]
%ProgramFiles%\MyCorp\MyApp.exe /Settings
~~~
http://msdn.microsoft.com/library/cc144188.aspx
| sh:task id={3B75A7AE-C4E4-4E5A-9420-7CECCDA75425}
|!-- This is a generated GUID, specific to this task link --
|sh:name@myTextResources.dll,-100/sh:name
|sh:keywords@myTextResources.dll,-101/sh:keywords
|sh:command%ProgramFiles%\Microsoft
Games\Solitaire\solitaire.exe/sh:command
~~
| /sh:task
Example with ambiguous/inconsistent use of quotes:
http://msdn.microsoft.com/en-us/library/aa767914.aspx
| HKEY_CLASSES_ROOT
| alert
| (Default) = URL:Alert Protocol
^ ^
| URL Protocol =
^^
| DefaultIcon
| (Default) = alert.exe,1
^ ^
| shell
| open
|command
| (Default) = C:\Program Files\Alert\alert.exe %1
Counterexamples:
http://msdn.microsoft.com/library/cc144175.aspx
http://msdn.microsoft.com/library/cc144101.aspx
| Note: If any element of the command string contains or might contain
| spaces, it must be enclosed in quotation marks. Otherwise, if the
| element contains a space, it will not parse correctly. For instance,
| My Program.exe starts the application properly. If you use
| My Program.exe without quotation marks, then the system attempts to
| launch My with Program.exe as its first command line argument. You
| should always use quotation marks with arguments such as %1 that are
| expanded to strings by the Shell, because you cannot be certain that
| the string will not contain a space.
http://msdn.microsoft.com/library/dd203067.aspx
http://msdn.microsoft.com/library/cc144109.aspx
regards
Stefan Kanthak
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 9): erroneous documentation
I'm on the same page as Pascal, what is the point of this? The part
that really stands out for me is how Microsoft is being singled out
here. If it's about their documentation, then it's not really about a
vulnerability. If it's NOT about their documentation, then you'd be
hard pressed to find a platform that _doesn't_ work this way.
On Sat, Aug 31, 2013 at 8:37 AM, hardfal...@hardfalcon.net wrote:
I am truly shocked that seemingly, stuff like this needs to be said in
the year of 2013. I'd have supposed that things like these should be
known by *anyone* doing anything even remotely similar to software
development *at least* since the end of the 8.3 filename era 15 years
ago. Are you sure this is real and not a prank? o_O
regards
Pascal Ernster
On 31.08.2013 12:58, Stefan Kanthak wrote:
Hi,
in http://seclists.org/fulldisclosure/2013/Aug/75 I documented
beginners errors (unquoted pathnames containing spaces) not only
in Microsoft products.
Microsofts developer documentation but shows these beginners errors
too (and is inconsistent, even in single topics).
Examples:
http://msdn.microsoft.com/library/cc144171.aspx
| HKEY_CLASSES_ROOT
| txtile
...
| Shell
...
| cmd2
...
| command
|(Default) = C:\Program Files\Windows
NT\Accessories\wordpad.exe %1
~~~ ~~
http://msdn.microsoft.com/library/bb165967.aspx
| [HKEY_CLASSES_ROOT\Applications\VSLauncher.exe\Shell\Open\Command]
| @=C:\\Program Files\\Common Files\\Microsoft
Shared\\MSEnv\\VSLauncher.exe \%1\
| [HKEY_CLASSES_ROOT\VisualStudio.csproj.8.0\shell\Open\Command]
| @=\C:\\Program Files\\Common Files\\Microsoft
Shared\\MSEnv\\VSLauncher.exe\ \%1\
http://msdn.microsoft.com/library/cc144083.aspx
| HKEY_LOCAL_MACHINE
| SOFTWARE
| Classes
| contoso-search
|shell
| open
| command
| (Default) =
%ProgramFiles%\Contoso\Search\contososearch.exe %1
~~~ ~~
http://msdn.microsoft.com/library/cc144154.aspx
| HKEY_LOCAL_MACHINE
| SOFTWARE
| Classes
| LitwarePlayer11.AssocFile
...
|shell
| open
| command
| (Default) = %ProgramFiles%\Litware\litware.exe
~~
http://msdn.microsoft.com/library/hh127450.aspx
| HKEY_CLASSES_ROOT
| CLSID
| {0052D9FC-6764-4D29-A66F-2F3BD9E2BB40}
| Shell
|Open
| Command
| (Default) = [REG_EXPAND_SZ]
%ProgramFiles%\MyCorp\MyApp.exe /Settings
~~~
http://msdn.microsoft.com/library/cc144188.aspx
| sh:task id={3B75A7AE-C4E4-4E5A-9420-7CECCDA75425}
|!-- This is a generated GUID, specific to this task link --
|sh:name@myTextResources.dll,-100/sh:name
|sh:keywords@myTextResources.dll,-101/sh:keywords
|sh:command%ProgramFiles%\Microsoft
Games\Solitaire\solitaire.exe/sh:command
~~
| /sh:task
Example with ambiguous/inconsistent use of quotes:
http://msdn.microsoft.com/en-us/library/aa767914.aspx
| HKEY_CLASSES_ROOT
| alert
| (Default) = URL:Alert Protocol
^ ^
| URL Protocol =
^^
| DefaultIcon
| (Default) = alert.exe,1
^ ^
| shell
| open
|command
| (Default) = C:\Program Files\Alert\alert.exe %1
Counterexamples:
http://msdn.microsoft.com/library/cc144175.aspx
http://msdn.microsoft.com/library/cc144101.aspx
| Note: If any element of the command string contains or might contain
| spaces, it must be enclosed in quotation marks. Otherwise, if the
| element contains a space, it will not parse correctly. For instance,
| My Program.exe starts the application properly. If you use
| My Program.exe without quotation marks, then the system attempts to
| launch My with Program.exe as its first command line argument. You
| should always use quotation marks with arguments such as %1 that are
| expanded to strings by the Shell, because you cannot be certain that
| the string will not contain a space.
http://msdn.microsoft.com/library/dd203067.aspx
http://msdn.microsoft.com/library/cc144109.aspx
regards
Stefan Kanthak
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Defense in depth -- the Microsoft way (part 8): execute everywhere!
Hi, since it's start about 20 years ago Windows NT supports (fine grained) ACLs, including the permission execute file. In their very finite wisdom Microsoft but decided back then to have this permission set on EVERY file a user creates (and assumes it is set on local and remote file systems which dont support ACLs). The result: on Windows, malware can run everywhere (and since CWD alias . is in the path, can be started everywhere)! These fundamental errors, combined with two other fundamental errors (NO ACLs on %SystemRoot% and %ProgramFiles% to prevent write access for non-administrative user accounts, and administrative rights for every user account) turned Windows NT into the same unsafe, insecure and vulnerable system its predecessors MS-DOS and Windows 3.x were and enabled miscreants to abuse internet-connected Windows systems to distribute SPAM, launch DDoS attacks, spread malware, etc. For a company that puts compatibility above all other criteria this decision might have looked reasonable ... BUT: it was NOT! Windows NT introduced the Win32-API, which is/was INCOMPATIBLE to the existing DOS- and Win16-API. To run existing applications written for the old APIs Windows NT introduced NTVDM (the Virtual DOS Machine) and WoW (the Windows on Windows subsystem); only these Windows NT components had to be made compatible (and unsafe enough to run old applications). There was ABSOLUTELY no need to sacrifice the safety and security of Windows NT and the Win32-API for the sake of compatibility: the Win32-API was new, no existing applications had to be supported! Then sloppy developers started to build their applications for the Win32-API of this unsafe/insecure environment ... and expected their unsuspecting victims^Wusers to have write access to %SystemRoot% and/or %ProgramFiles% to write their *.INI files, for example, or to run their crapware with administrative or power-user rights. JFTR: since many years Microsoft makes many (almost futile) attempts to mitigate the effect of their wrong design decision(s), for example: * http://support.microsoft.com/kb/269049 alias http://technet.microsoft.com/security/bulletin/ms00-052 * http://support.microsoft.com/kb/306850 * http://support.microsoft.com/kb/905890 * http://support.microsoft.com/kb/953818 alias http://technet.microsoft.com/security/advisory/953818 * http://support.microsoft.com/kb/959426 alias http://technet.microsoft.com/security/bulletin/ms09-015 * http://support.microsoft.com/kb/2264107 * http://support.microsoft.com/kb/2269637 alias http://technet.microsoft.com/security/advisory/2269637 PLUS the 28(!) security bulletins listed there but NEVER tackled the source of the problem! Instead they introduced things like the security theatre UAC: with Windows 8 the user account(s) created during setup still have administrative rights. And Windows 7 introduced the silent elevation for about 70 of Microsoft own programs... stay tuned Stefan Kanthak PS: if you want to mitigate the wrong design decision that every file is executable: add and propagate an inheritable-only deny ACE with execute file permission for the user group WORLD\Everyone alias S-1-1-0, (D;OIIO;WP;;;WD) in SDDL notation, at least for %USERPROFILE% and %ALLUSERSPROFILE% alias %ProgramData%. On Windows NT 6.x, consider to add another deny ACE which prevents the directories/objects owner from changing/removing that permission: (D;;WDAC;;;OW) in SDDL notation. Since this mitigation will stop Administrators and LocalSystem to run files in their user profiles (to be precise: in %TEMP% alias %USERPROFILE%\Local Settings\Application Data\TEMP resp. %USERPROFILE%\AppData\TEMP where self-extracting installers will typically unpack and execute their payload) you'll have to remove the user environment variables TEMP and TMP of these user accounts (setting the system environment variables TEMP and TMP which point to %SystemRoot%\TEMP into effect). See the script http://home.arcor.de/skanthak/download/~EXECUTE.INF for a POC (targetting Windows NT 5.x). It sets the deny ACE also on subordinate directories which are exempt from ACL inheritance, as well as some of the user-writable subdirectories of %SystemRoot% which dont host executable files. WARNING: unfortunately the (only) Microsoft utility which allows to add the specific ACEs, ICACLS.EXE, used in this script has but a serious bug; cf. http://seclists.org/fulldisclosure/2012/May/109 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 8): execute everywhere!
Hi Stefan, ... administrative rights for every user account Hmmm... XP/x64 appears to have a bug such that the second user also needs to be admin (perhaps XP/x86, too). XP does not recognize the first account as admin, so the second account cannot be limited (at least on my test box). Vista and above make the first user admin, but others users default to standard. Jeff On Sat, Aug 24, 2013 at 5:32 PM, Stefan Kanthak stefan.kant...@nexgo.de wrote: Hi, since it's start about 20 years ago Windows NT supports (fine grained) ACLs, including the permission execute file. In their very finite wisdom Microsoft but decided back then to have this permission set on EVERY file a user creates (and assumes it is set on local and remote file systems which dont support ACLs). The result: on Windows, malware can run everywhere (and since CWD alias . is in the path, can be started everywhere)! These fundamental errors, combined with two other fundamental errors (NO ACLs on %SystemRoot% and %ProgramFiles% to prevent write access for non-administrative user accounts, and administrative rights for every user account) turned Windows NT into the same unsafe, insecure and vulnerable system its predecessors MS-DOS and Windows 3.x were and enabled miscreants to abuse internet-connected Windows systems to distribute SPAM, launch DDoS attacks, spread malware, etc. For a company that puts compatibility above all other criteria this decision might have looked reasonable ... BUT: it was NOT! Windows NT introduced the Win32-API, which is/was INCOMPATIBLE to the existing DOS- and Win16-API. To run existing applications written for the old APIs Windows NT introduced NTVDM (the Virtual DOS Machine) and WoW (the Windows on Windows subsystem); only these Windows NT components had to be made compatible (and unsafe enough to run old applications). There was ABSOLUTELY no need to sacrifice the safety and security of Windows NT and the Win32-API for the sake of compatibility: the Win32-API was new, no existing applications had to be supported! Then sloppy developers started to build their applications for the Win32-API of this unsafe/insecure environment ... and expected their unsuspecting victims^Wusers to have write access to %SystemRoot% and/or %ProgramFiles% to write their *.INI files, for example, or to run their crapware with administrative or power-user rights. JFTR: since many years Microsoft makes many (almost futile) attempts to mitigate the effect of their wrong design decision(s), for example: * http://support.microsoft.com/kb/269049 alias http://technet.microsoft.com/security/bulletin/ms00-052 * http://support.microsoft.com/kb/306850 * http://support.microsoft.com/kb/905890 * http://support.microsoft.com/kb/953818 alias http://technet.microsoft.com/security/advisory/953818 * http://support.microsoft.com/kb/959426 alias http://technet.microsoft.com/security/bulletin/ms09-015 * http://support.microsoft.com/kb/2264107 * http://support.microsoft.com/kb/2269637 alias http://technet.microsoft.com/security/advisory/2269637 PLUS the 28(!) security bulletins listed there but NEVER tackled the source of the problem! Instead they introduced things like the security theatre UAC: with Windows 8 the user account(s) created during setup still have administrative rights. And Windows 7 introduced the silent elevation for about 70 of Microsoft own programs... stay tuned Stefan Kanthak PS: if you want to mitigate the wrong design decision that every file is executable: add and propagate an inheritable-only deny ACE with execute file permission for the user group WORLD\Everyone alias S-1-1-0, (D;OIIO;WP;;;WD) in SDDL notation, at least for %USERPROFILE% and %ALLUSERSPROFILE% alias %ProgramData%. On Windows NT 6.x, consider to add another deny ACE which prevents the directories/objects owner from changing/removing that permission: (D;;WDAC;;;OW) in SDDL notation. Since this mitigation will stop Administrators and LocalSystem to run files in their user profiles (to be precise: in %TEMP% alias %USERPROFILE%\Local Settings\Application Data\TEMP resp. %USERPROFILE%\AppData\TEMP where self-extracting installers will typically unpack and execute their payload) you'll have to remove the user environment variables TEMP and TMP of these user accounts (setting the system environment variables TEMP and TMP which point to %SystemRoot%\TEMP into effect). See the script http://home.arcor.de/skanthak/download/~EXECUTE.INF for a POC (targetting Windows NT 5.x). It sets the deny ACE also on subordinate directories which are exempt from ACL inheritance, as well as some of the user-writable subdirectories of %SystemRoot% which dont host executable files. WARNING: unfortunately the (only) Microsoft utility which allows to add the specific ACEs, ICACLS.EXE, used in
Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 8): execute everywhere!
Jeffrey Walton wrote: Hi Stefan, ... administrative rights for every user account This WAS the default for user accounts back then, and still IS the default for user accounts created during setup. Hmmm... XP/x64 appears to have a bug such that the second user also needs to be admin (perhaps XP/x86, too). XP does not recognize the first account as admin, so the second account cannot be limited (at least on my test box). 1. A normal (read: attended) setup of XP forces you to create at least one user account (besides the always created Administrator) during setup which gets administrative privileges. You can demote this user account on the command line with NET.EXE LOCALGROUP Administrators %USERNAME% /DELETE as well as interactive with MMC.EXE LUSRMGR.MSC and RUNDLL32.EXE NETPLWIZ.DLL,UsersRunDll alias CONTROL.EXE Userpasswords2. Only the dumbed down User Accounts control panel applet (run via CONTROL.EXE NUSRMGR.CPL alias MSHTA.EXE res://NUSRMGR.CPL/nusrmgr.hta) insists on having a second user account (besides the builtin Administrator) with administrative rights and does not allow to demote the second (superfluous) administrative account. JFTR: neither the dumbed down User Accounts control panel applet nor CONTROL.EXE Userpasswords2 show disabled accounts. 2. The out-of-box experience allows you to create up to 5 user accounts during setup, which all get administrative privileges. 3. An unattended setup of XP does NOT force you to create a (second) user account (besides the always created Administrator) at all, and allows you to disable the out-of-box experience too. 4. After setup the dumbed down User Accounts control panel applet defaults to create administrative accounts (and forces you to create an administrative account if there is only one, for example after unattended setup), while MMC.EXE LUSRMGR.MSC creates users, and CONTROL.EXE Userpasswords2 creates user accounts as power users (it shows a dialog with users, power users and administrators where power users is selected). The result: Jane Doe has administrative rights, via the user account created during attended setup or afterwards with Users Passwords and its default setting. Q.E.D. Vista and above make the first user admin, but others users default to standard. It's basically like XP: the (attended) setup forces you to create at least one user account which gets administrative privileges. The result: as long as John Doe uses his Windows PC with just the user account created during setup he is administrator. regards Stefan [ fullquote removed ] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Defense in depth -- the Microsoft way (part 7): executable files in data directories
Hi, with Windows XP (about 12 years ago) Microsoft started to develop a REALLY NASTY habit: they began to install executable files outside of %SystemRoot%\ and %ProgramFiles%\, in %ALLUSERSPROFILE%\ (since Windows Vista: %ProgramData%\) and even %USERPROFILE%\. Examples: * %ALLUSERSPROFILE%\DRM\INDIVBOX.KEY a DLL, installed there when a user runs the DRM individualisation process of Windows Media Player, see http://go.microsoft.com/fwlink/fwlink.ashx?linkid=34506 alias http://drmlicense.one.microsoft.com/Indivsite/en/indivit.asp?force=1 alias https://services.wmdrm.windowsmedia.com/Indivsite/en/indivit.asp?force=1 * %COMMONAPPDATA%\Microsoft\PlayReady\Cache\...\MSPRindiv01.key a DLL, used for Silverlight's PlayReady DRM * %APPDATA%\Microsoft\Virtual PC\VPCKeyboard.dll * %LOCALAPPDATA%\Microsoft\SkyDrive\... ... While this is a violation of Microsoft's own, about 18 years old Designed for Windows guidelines, it tears down the security boundary created with NTFS permissions/access rights and privilege separation: unprivileged users cant write to %SystemRoot%\ and %ProgramFiles%\ and below, so all executables installed there are protected against tampering by unprivileged users (and programs/malware running under unprivileged user accounts). Executables installed in %USERPROFILE% are but NOT protected against tampering and can undermine at least the users safety. Marcus J. Ranum was SOO right, back in 2007, when he wrote in Execution Control: Death to Antivirus (see http://www.ranum.com/security/computer_security/editorials/antivirus/index.html): | It makes sense; security never has been important in Windows. JFTR: unfortunately not only Microsoft shows this bad habit: crapware like the versions of Google Chrome or Google Drive that are offered to end users installs into %LOCALAPPDATA%\Google\Chrome\Application\..., %LOCALAPPDATA%\Google\Update\... and even subdirectories of %TEMP%, Dropbox installs into %APPDATA%\Dropbox\..., SoftMaker Office creates a DLL with the user registration data in %APPDATA%\SoftMaker (and fails MISERABLY if execution is denied there), Mozilla Firefox and Thunderbird download their updaters to %APPDATA%\Mozilla\... (and fail MISERABLY if execution is denied there), extensions like Mozilla Lightning install DLLs below %APPDATA%\Mozilla\... (and fail MISERABLY if execution is denied there), ... I recommend that the developers responsible for these crimes against computer safety and security learn the meaning of the word DATA before they are allowed to pester unsuspecting users with more of their (by the very design) unsafe and insecure programs. stay tuned Stefan Kanthak PS: it's getting worse^Wmore complicated (and as everybody with a sane mind knows: complexity reduces/ruins safety and security)! With Windows Vista Microsoft introduced user account control (really: they surrendered to all those incapable and incompetent developers who were and are unable and unwilling to write Windows software that runs without administrative rights, as requested in their own, then about 11 year old Designed for Windows guidelines) and UAC virtualization, which redirects write access failures (and after that, read accesses too) of legacy applications, i.e. 32-bit processes run by unprivileged interactive users (cf. http://technet.microsoft.com/magazine/4ce22051-1ff9-49c1-ab06-d97658e993e0 and http://msdn.microsoft.com/en-us/library/bb530410.aspx) below %SystemRoot%\, %ProgramFiles%\ and %ProgramData%\ to %LOCALAPPDATA%\VirtualStore\. | However, any file with an executable extension, including .exe, | .bat, .scr, .vbs, and others, is excluded from virtualization. The list of predefined executable extensions (as found within %SystemRoot%\System32\Drivers\LUAFV.SYS) is: .acm, .asa, .asp, .aspx, .ax, .bat, .cer, .chm, .clb, .cmd, .cnt, .cnv, .com, .cpl, .cpx, .crt, .dll, .drv, .exe, .fon, .grp, .hlp, .hta, .ime, .inf, .ins, .isp, .its, .js, .jse, .lnk, .msc, .msi, .msp, .mst, .mui, .nls, .ocx, .pal, .pcd, .pif, .reg, .scf, .scr, .sct, .shb, .shs, .sys, .tlb, .tsp, .url, .vb, .vbe, .vbs, .vsmacros, .ws, .wsc, .wsf and .wsh BUT: .key (see above) is missing! To modify this list, edit [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Luafv\Parameters] ExcludedExtensionsAdd=multi: ExcludedExtensionsRemove=multi: ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Defense in depth -- the Microsoft way (part 6): beginner's errors, QA sound asleep or out of sight!
Hi,
the installation of Microsofts much acclaimed security tool
EMET 3.0 (see http://www.microsoft.com/emet and
http://support.microsoft.com/kb/2458544) creates the following
VULNERABLE registry entry that runs a rogue program C:\PROGRA.EXE
(as well as C:\Program Files.exe on x64) in the security context
of the user logging on:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
EMET Notifier=C:\\Program Files\\EMET\\EMET_notifier.exe ; x86
EMET Notifier=C:\\Program Files (x86)\\EMET\\EMET_notifier.exe ; x64
JFTR: the vulnerability is caused by of one of Windows' documented
(see http://msdn.microsoft.com/library/ms682425.aspx) idiosyncrasies:
CreateProcess() does NOT fail on calls with arguments like
C:\Program Files\Common Files\Microsoft Shared\filename[.extension]
but tries to execute
C:\Progra.exe
C:\Program Files\Common.exe
C:\Program Files\Common Files\Microsoft.exe
C:\Program Files\Common Files\Microsoft Shared\filename[.extension]
in turn to cover BEGINNERS ERRORS of incapable developers who are
unable to handle long pathnames with embedded spaces properly.
Whoever decided to implement this idiosyncrasy some 20 years ago was
but incapable too and did not recognize the consequences of this
idiosyncrasy^Widiotic behaviour!
The same beginners error is (for example) present in all versions
of Microsoft Security Essentials before 4.2 and was just recently
fixed with https://support.microsoft.com/kb/2805304:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Microsoft
Security Client]
UninstallString=C:\\Program Files\\Microsoft Security Client\\Setup.exe /X
Some of Microsoft's developers (and of course their QA) apparently
dont know their companies own documentation;
cf. http://msdn.microsoft.com/library/ms997548.aspx:
| The path you supply to Uninstall-String must be the complete
| command line used to carry out your uninstall program.
JFTR: add/remove programs of current versions of Windows (XP SP2
and newer) mitigates this error and inserts missing quotes after
the first filename or filename.extension and in front of
the string. This kludge is but NOT documented!
https://support.microsoft.com/kb/2781197 resp.
https://support.microsoft.com/kb/2823482 alias
https://technet.microsoft.com/security/bulletin/ms13-034 fixed
another unquoted pathname in Windows Defender on Windows 8, while
https://support.microsoft.com/kb/2847927 alias
https://technet.microsoft.com/security/bulletin/ms13-058 fixed it
in Windows Defender on Windows 7 and Window Server 2008 R2, where
this beginners error allowed the execution of a rogue program
C:\PROGRA.EXE in the security context of LocalSystem.
On a fully patched Windows 7 x64 take a look at:
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{37efd44d-ef8d-41b1-940d-96973a50e9e0}\Shell\Open\Command]
@=expand:%ProgramFiles%\\Windows Sidebar\\sidebar.exe /showGadgets
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\DesktopBackground\Shell\Gadgets\command]
@=C:\\Program Files\\Windows Sidebar\\sidebar.exe /showGadgets
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\NetworkExplorerPlugins\urn:schemas-upnp-org:device:MediaServer:1\shell\Open
Media
Player\command]
@=expand:C:\\Program Files\\Windows Media Player\\wmplayer.exe
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Windows.gadget\shell\open\command]
@=expand:%ProgramFiles%\\Windows Sidebar\\Sidebar.exe
[HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Media\Windows Media
Player\shell\open\command]
@=expand:%ProgramFiles(x86)%\\Windows Media Player\\wmplayer.exe
[HKEY_LOCAL_MACHINE\SOFTWARE\Clients\StartMenuInternet\IEXPLORE.EXE\shell\open\command]
@=C:\\Program Files (x86)\\Internet Explorer\\iexplore.exe
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SideShow\Gadgets\{591248b9-ad35-47c2-b2fa-2d7c120adc79}]
StartCommand=expand:%programFiles%\\Windows Media
Player\\WMPSideShowGadget.exe
[HKEY_CURRENT_USER\Software\Microsoft\Keyboard\Native Media Players\WMP]
ExePath=C:\\Program Files\\Windows Media Player\\wmplayer.exe
On a fully patched Windows XP take a look at:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Multimedia\MPlayer2]
Player.Path=C:\\Program Files\\Windows Media Player\\mplayer2.exe
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Multimedia\WMPlayer]
Player.Path=C:\\Program Files\\Windows Media Player\\wmplayer.exe
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\wmplayer.exe\shell\open\command]
@=C:\\Program Files\\Windows Media Player\\wmplayer.exe /Open %L
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\wmplayer.exe\shell\play\command]
@=C:\\Program Files\\Windows Media Player\\wmplayer.exe /Play %L
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MSDASC\shell\open\command]
@=Rundll32.exe C:\\Program Files\\Common Files\\System\\OLE
DB\\oledb32.dll,OpenDSLFile %1
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MSInfo.Document\Shell\Open\Command]
@=C:\\Program Files\\Common Files\\Microsoft Shared\\MSInfo\\MSInfo32.exe
/msinfo_file %1
[Full-disclosure] Defense in depth -- the Microsoft way (part 5): sticky, persistent vulnerabilities
Hi, with Windows XP (about 12 years ago) Microsoft introduced the so-called side-by-side technology to overcome DLL hell. With side-by-side technology several versions of a DLL can be installed on a system at the same time, for global use by any application; the side-by-side store is located in the subdirectory WinSxS of the Windows directory. Applications, for example filename.exe, that need to use/load a side-by-side DLL have to provide a 'Manifest', either as resource linked into the application or as an external file named filename.manifest to let the loader locate the side-by-side DLL. Cf. http://msdn.microsoft.com/library/aa384082.aspx BUT... Microsoft NEVER purges OUTDATED and/or VULNERABLE DLLs from the side-by-side store, and Microsoft does NOT provide a utility to cleanup the mess^HDLL hell accumulated in the side-by-side store. The result: every application can request via 'Manifest' to load a VULNERABLE version of any DLL present in the side-by-side store, effectively circumventing ANY security patches installed for these DLLs. Cf. http://msdn.microsoft.com/library/aa375141.aspx. If you think now: but there is a publisher configuration (cf. http://msdn.microsoft.com/library/aa375680.aspx) that redirects old versions to the patched version: the publisher configuration is overridden by a per-application configuration, cf. http://msdn.microsoft.com/library/ee710783.aspx and http://msdn.microsoft.com/library/aa375667.aspx Common candidates to tinker with on Windows XP and 2003 are (see Start-Run CMD.EXE /K dir /S /B %SystemRoot%\WinSxS\*.DLL): - WINHTTP.DLL (installed 3 times on a fully patched 2003) - COMCTL32.DLL (installed 3 times on a fully patched XP, and 4 times on a fully patched 2003) - GDIPLUS.DLL (installed 4 times on a fully patched XP, and 3 times on a fully patched 2003) - MSVCRT.DLL MSVCIRT.DLL - MSVC?80.DLL - MSVC?90.DLL - MFC*.DLL - ATL*.DLL - VCOMP*.DLL Cf. http://msdn.microsoft.com/library/ms235624.aspx For Windows Vista and later: run the command given above and see yourself! stay tuned Stefan Kanthak PS: if you find any of these side-by-side DLLs in %ProgramFiles%, %ProgramFiles(x86)% or other locations: ask the developers/vendors who installed them there to take a REALLY THOROUGH look at http://support.microsoft.com/kb/835322! And don't forget to file bug reports against any product that installed OUTDATED and/or VULNERABLE DLLs! ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Defense in depth -- the Microsoft way (part 4)
Hi, Microsoft distributes (security critical) updates for Windows components and Microsoft products installed on user systems via Windows/Microsoft Update and installs them automatically. Except in some VERY common cases... For the incorporation of redistributable components like the MSVCRT, MFC, ATL etc. in MSI installer packages of other (including 3rd party) products Microsoft provides so-called MSI merge modules *.MSM with Visual Studio. This is primarily a convenience for the packager/developer and the user/consumer, since both dont have to handle the (typically larger) standalone redistributable packages of the included components from their main installer package. The files included in these MSI merge modules are installed in the same locations as their standalone redistributable packages do. But... Windows Update Agent doesnt detect vulnerable/outdated files installed via MSI merge modules: some of the meta-data which is written by the standalone redistributable packages is not written by the MSI merge modules and lets Windows Update Agent fail to detect them properly. The result: all Windows installations where * Microsoft products like Microsoft Security Essentials, Windows Defender, Forefront Security, Microsoft Office anything, Microsoft Sharepoint anything, Microsoft SQL Server anything, .NET Framework 2.0/3.0/3.5, which come with outdated and vulnerable MSI merge modules, are installed, * 3rd party products like Adobe Reader/Acrobat and numerous others of numerous other developers/companies, which come with outdated and vulnerable MSI merge modules, are installed, * the current version of the standalone redistributable packages of the resp. MSCVRT, MFC, ATL etc. are NOT installed, are (potentially) VULNERABLE! stay tuned Stefan Kanthak PS: if you want to check your own Windows installations: get FILEVER.EXE from http://www.microsoft.com/en-us/download/details.aspx?id=15326 (the download link in http://support.microsoft.com/kb/913111 points to an older version), start a command prompt and run the following commands: FILEVER.EXE /S %SystemRoot%\WinSxS\MSVC*.DLL FILEVER.EXE /S %SystemRoot%\WinSxS\MFC*.DLL FILEVER.EXE /S %SystemRoot%\WinSxS\ATL*.DLL FILEVER.EXE /S %SystemRoot%\WinSxS\MSDIA*.DLL FILEVER.EXE /S %SystemRoot%\WinSxS\VCOMP*.DLL FILEVER.EXE %SystemRoot%\System32\MSVC*.DLL FILEVER.EXE %SystemRoot%\System32\MFC*.DLL FILEVER.EXE %SystemRoot%\System32\ATL*.DLL FILEVER.EXE %SystemRoot%\System32\MSDIA*.DLL FILEVER.EXE %SystemRoot%\System32\VCOMP*.DLL FILEVER.EXE %SystemRoot%\SysNative\MSVC*.DLL(x64 only) FILEVER.EXE %SystemRoot%\SysNative\MFC*.DLL ... FILEVER.EXE %SystemRoot%\SysNative\ATL*.DLL ... FILEVER.EXE %SystemRoot%\SysNative\MSDIA*.DLL ... FILEVER.EXE %SystemRoot%\SysNative\VCOMP*.DLL ... If the output shows DLLs with version numbers less than listed in http://support.microsoft.com/kb/2565063 http://support.microsoft.com/kb/2467173 http://support.microsoft.com/kb/2538243 http://support.microsoft.com/kb/2538242 http://support.microsoft.com/kb/2465373 you should fetch the resp. redistributable packages and install them (as stated in the FAQ section of http://technet.microsoft.com/security/bulletin/ms11-025) Don't forget to file file bug reports against any product that installed the outdated DLLs. PPS: if you find any of these DLLs in %ProgramFiles%, %ProgramFiles(x86)% or other locations: remove them! Then ask the developers/vendors who installed them there to take a REALLY THOROUGH look at http://support.microsoft.com/kb/835322! And don't forget to file file bug reports against any product that installed OUTDATED DLLs there! ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Defense in depth -- the Microsoft way (part 3)
Hi @ll, many (if not most of the) Windows system utilities and system routines (including the kernel and its subsystems) as well as many user programs (including the shell Windows Explorer, Windows Media Player, Internet Explorer, Microsoft Office, etc.) load libraries/satellites at runtime via filenames read from registry or .INI entries (see examples 0 to 13 below). Unfortunately, MANY of the references (about 5500 in Windows 7 x64 SP1 and about 4700 in Windows 7 x86 SP1) to libraries/satellites are made just via their filename, without their (well-known!) fully qualified path. Every application/utility/system routine that uses one of these system routines/subsystems, but has not taken precautions against loading DLLs and/or satellites from CWD (see http://support.microsoft.com/kb/2264107 and http://support.microsoft.com/kb/2269637) is thus susceptible to binary planting attacks. The VERY simple fix/mitigation: ALWAYS use the (well-known!) fully qualified path to all the libraries/satellites you reference! JFTR: almost all of the registry entries listed in the examples below can be specified as (typically) %SystemRoot%\System32\library.dll with the REG_EXPAND_SZ data type. Timeline: 2004-08-23informed vendor about still unfixed principal security flaws due to unqualified filenames and Windows' EXE/DLL search/load order after release of SP2 for Windows XP JFTR: Microsoft started their trustworthy computing initiative in 2001, and XP SP2 was supposed to eliminate many of the errors Microsoft made in previous versions of NT. 2004-08-25vendor replies no vulnerabilities, but forwards report to product groups/teams 2004-09-02vendor still wont see vulnerabilities, asks for POC(s) 2008-05-30vendors publishes http://technet.microsoft.com/security/advisory/953818 2009-04-15vendor publishes http://support.microsoft.com/kb/959426 alias http://technet.microsoft.com/security/bulletin/ms09-015 plus http://technet.microsoft.com/security/bulletin/ms09-014 2010-08-23vendor publishes http://technet.microsoft.com/security/advisory/2269637 and updates it over and over again since then 2010-08-24asked vendor in response to advisory 2269637 what the product groups/teams had done in the past 6 years since my initial report to eliminate this attack vector 2010-09-04compiled an exhaustive list with the about 5500(!) unqualified filenames (and some more errors) in the registry of Windows 7 x64 and sent it to vendor; http://home.arcor.de/skanthak/download/W7_ERROR.INF and http://home.arcor.de/skanthak/download/W7_ISSUE.INF are the lists with major/minor errors found in the registry of Windows 7 x86 SP1 2010-09-11asked vendor when to expect results from report sent in 2004, and when to expect a properly/thoroughly engineered Windows with defense in depth REALLY applied [*] 2010-09-13vendor replied (to question from 2010-08-24): we have no feedback from the product teams 2011-09-13vendor publishes http://support.microsoft.com/kb/2570947 alias http://technet.microsoft.com/security/bulletin/ms11-071 2011-12-28vendor informs that the BSOD from example 3 was filed as a stability bug against Windows 8 2012-05-08vendor publisheshttp://support.microsoft.com/kb/2686509 alias http://technet.microsoft.com/security/bulletin/ms12-034 stay tuned Stefan [*] for (german) Windows XP Professional I provide the script http://home.arcor.de/skanthak/download/XP_FIXIT.INF that corrects the errors in the registry which remain after fixing the scripts \i386\DMREG.INF and \i386\HIVE*.INF and the errors in installed *.theme and generated DESKTOP.INI files which remain after fixing the \i386\*.TH_ files (usage instructions included in the script). PS: if you missed part 1 and/or part 2, see http://seclists.org/fulldisclosure/2013/May/107 and http://seclists.org/fulldisclosure/2013/Jun/6 Example 0: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layouts\] Layout File=KBDxyz.DLL Fixed with http://support.microsoft.com/kb/2686509 alias http://technet.microsoft.com/security/bulletin/ms12-034 JFTR: Microsoft started their trustworthy computing initiative in 2001; 11 years later they still have loads of silly security holes due to their sloppy attitude! Example 1: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] Shell=explorer.exe Userinit=userinit.exe Fixed with http://support.microsoft.com/kb/269049 alias http://technet.microsoft.com/security/bulletin/ms00-052 JFTR: the vulnerability with Userinit=userinit.exe was
[Full-disclosure] Defense in depth -- the Microsoft way
Hi @ll,
the Microsoft Installer creates for applications installed via an
.MSI the following uninstall information in the Windows registry
(see http://msdn.microsoft.com/library/aa372105.aspx):
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall]
UninstallString=MsiExec.Exe /X{GUID}
ModifyPath=MsiExec.Exe /I{GUID}
Note the unqualified path to the executable msiexec.exe.
On Windows installations without the SafeProcessSearchMode hotfix
(cf. http://support.microsoft.com/kb/905890) or with this safeguard
turned off (cf. http://msdn.microsoft.com/library/dd266735.aspx,
which refers to http://support.microsoft.com/kb/959426 alias MS09-015),
an executable msiexec.exe placed in the CWD or the users base
directory (addressed by %HOMEDRIVE%%HOMEPATH% and typically equal to
%USERPROFILE%) can be run instead of the intended executable
%SystemRoot%\System32\MsiExec.Exe.
The VERY simple fix (which eliminates this attack vector completely):
always use fully-qualified paths to the well-known executables.
JFTR: cf. http://seclists.org/fulldisclosure/2011/Sep/160
Stefan Kanthak
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
