Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account

[Stefan Kanthak]

Michael Cramer mike.cra...@outlook.com wrote:

I think you're arguing semantics here.

Of course.

 Of course the specifics of how a particular program is executed
 will be different between command line and GUI-based OS'.

Really?
Is there any need for this difference you state?
BTW: what is the difference?

 Both provide the ability for non-privileged users to launch processes
 with specific, temporary Administrative access rather than their
 account having always-on Administrative access.

But only Windows' system call CreateProcess*() has the COMPLETELY
BRAINDEAD behaviour to guess or probe which executable to run!

 Whether or not a user is going to click yes to everything is completely
 irrelevant to the technical details at hand. It could be argued that
 training a user to type 'sudo' on every command could have the same effects.
 Just because *YOU* understand the difference doesn't mean there aren't
 1000 Linux users out there typing sudo for literally everything simply
 because that's how they were taught to type commands in the terminal.

You miss the point, completely.
It's not about sudo or RUNAS.EXE or UAC, its about the braindead behaviour
of CreateProcess*().

This is the culprit. Nothing else.

Without its braindead behaviour every developer or his QA would stumble
over unquoted paths the very instant they are used and poorly written
programs with such beginners errors would not be delivered to hundreds
of millions of unsuspecting users putting them at risk to run a rogue
C:\Program.exe

 
 
 RE: 0.
 
 
 http://www.dwheeler.com/essays/filenames-in-shell.html
 
 
 This was brought up on the FD mailing list towards the end of June
 (http://seclists.org/fulldisclosure/2014/Jun/140) in which discussion
 on how the Linux shell has its own quirks regarding path names and
 potential security issues. It's disingenuous to single out Windows with
 its path name handling in this context without addressing this issue
 across the board. Simply put, these types of issues are universally
 understood across many operating systems to be in the realm of
 applications themselves and NOT a fault of the platform.

Its but the fault of the platform!
CreateProcess*() is just the system call, and its the ONLY system
call available to start another process, used by ShellExecute*(),
the service manager etc. pp.

 So again, to sit here and single out Windows for its quirky pathname
 behavior is just picking fights here.

See above: you completely miss the point!

 In short, yes, Windows has a function that takes input and launches a
 path which COULD lead to unexpected behavior when passing the argument
 without quotes. But arguing that this should be on Microsoft to resolve
 within Windows just points me back towards the aforementioned link which
 says such problems should also be resolved at the OS layer for them as well.

See above: CreateProcess*() is the OS layer here!

 To address your Windows auto-elevated processes. Yes, this is the default
 configuration when these processes are signed binaries from a specific
 Microsoft certificate. However, for the security conscious folks you can
 easily turn UAC up to the maximum level which will require elevation on
 the secure desktop for all applications, including these processes. This
 was the default configuration in Windows Vista when it was released, but
 enough people complained about it that Microsoft reduced the # of UAC
 prompts in Windows 7 with the above resolution.

Yes. An that's another completely braindead decision.
Instead of fixing their own buggy programs they built one more crappy
workaround.

 All user accounts in Ubuntu are created with the ability to use sudo
 automatically without further configuration from the root account.

All exec*() calls not only on Ubuntu DONT show the braindead behaviour
of Windows CreateProcess*().

regards
Stefan

 Sent from my Surface Pro 3
 
 
 
 
 
 From: Stefan Kanthak
 Sent: ?Monday?, ?July? ?28?, ?2014 ?10?:?43
 To: Michael Cramer, Gynvael Coldwind
 Cc: fulldisclosure, Brandon Perry, bugtraq@securityfocus.com
 
 
 
 
 
 Michael Cramer mike.cra...@outlook.com wrote:
 
 sudo make-me-a-sandwich.py
 
 
 How is this different from any other temporary, per-process elevation system?
 
 0. neither sudo nor make-me-a-sandwich.py nor the OS where these programs
   typically run have a CreateProcess*() system call which guesses which
   executable it should run in case of a command line with embedded spaces.
 
   Do you expect that your command line executes sudo make-me-a-sandwich.py
   in the absence of a file sudo or sudo.exe?
 
 
 1. if you omit sudo from the command line, there is no elevation, not even
   an attempt for an elevation.
 
   On Windows, you dont need to use sudo, you just open for example
   REGEDIT.EXE or make-me-a-sandwich.reg: if you do this in a standard
   user account REGEDIT.EXE will run with standard user rights, without
   any prompt for elevation. But if you do this in an administrator account

Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account

[Stefan Kanthak]

Gynvael Coldwind wrote:

 So reading the links you provided I semi-agree with you. I think the
 problem boils down to this part of your initial e-mail:
 
 PS: yes, it needs administrative privileges to write C:\Program.exe.
BUT: all the user account(s) created during Windows setup have
administrative privileges.
 
 My point was (and it still stands) that if you have admin access, this
 isn't a privilege escalation, as there is no escalation part here.

Correct.
If only Microsoft would educate its users to exercise STRICT user
separation and use different accounts for administration and daily work.

This is where and why UAC chimes in (which answers your question below):
Joe Average uses the administrative account created during Windows setup,
but UAC strips the administrator rights.
Microsoft sells UAC as Joe Average works with standard user rights
or Joe Average is not an administrator any more, neglecting that Joe
will happily approve almost every request for administrative rights (or
isnt asked at all when one of the about 70 Windows executables which are
exempt from the elevation prompt are auto-elevated).

 The links you provided use different wording, e.g.
 (http://blogs.technet.com/b/srd/archive/2013/07/09/assessing-risk-for-the-july-2013-security-updates.aspx):
 To exploit the vulnerability addressed by this update, attacker must
 have permission to create a new file at the root of the system drive.
 (C:\malicious.exe)
 
 This makes of course more sense, though as I did mention above, it
 does seem to require deliberate action from the administrator to
 actually allow a non-admin user the WD (add file to directory)
 privilege on C:\, which is rather rare I would say.

Correct.
This argument holds as long as strict user separation is exercised.
But with UAC, Joe Average is both user and administrator, and isnt
really aware of his split personality.

 That being said, after thinking about it again I do see your point,
 which I interpret at: even if an administrator grants all users WD/AD
 on C:\, there should be no reason for him to worry, as there is no
 reason to suspect files placed in C:\ are going to auto-execute on
 certain events*.
 * let's leave autoexec.bat/config.sys out of this, as that branch of
 Windows is long dead and supported only FAT anyway
 
 So let me change my initial e-mail to: Congratz on finding the bug :)
 
 (BTW not sure why did you bring UAC into the discussion - did I miss
 something? or was it just an argument you've heard before and wanted
 to reply to it preventively?)
 
 Cheers!

regards
Stefan


 On Fri, Jul 25, 2014 at 2:50 PM, Stefan Kanthak stefan.kant...@nexgo.de 
 wrote:
 Gynvael Coldwind wrote:

 Well it was discussed a couple of times recently on FD that this is a bug,
 but it's not a privilege escalation.
 If you are admin (and you did mention that it's a prerequisite) you can
 execute code as other users anyway - so there's no *escalation* here.

 Therefore it's not a security bug (unless you are using a super old version
 of Windows with incorrect ACLs on c:\, which sounds like a bug in itself),
 just a normal bug.
 Not sure if FD is the right place for non-security bugs tbh.

 If these bugs were no security bugs: why does Microsoft then publish fixes
 for (at least some of) them via MSRC bulletins and Windows Update?

 See https://technet.microsoft.com/library/security/ms13-058.aspx
 or https://technet.microsoft.com/library/security/ms13-034.aspx

 Or pulls drivers whose setup routines show these bugs from Windows Update?

 See http://seclists.org/fulldisclosure/2014/May/40


 Also try to see these bugs as a blended threat:

 * during Windows setup Microsoft still creates all user accounts as
   administrators.

 * Microsoft sells its unsuspecting users UAC as a security feature, but does
   NOT inform them (or at least does not inform Joe Average) that UAC is not
   a security boundary and they should better use a restricted^Wstandard user
   account instead of the administrator account created during setup.

 * Joe Average will happily give consent to any program which presents an UAC
   prompt to him: he wants to get his work done, and this UAC prompt is just
   an annoyance. BTW: when Windows asks him for consent, this must be right?

 regards
 Stefan

 Cheers,
 On 25 Jul 2014 00:46, Stefan Kanthak stefan.kant...@nexgo.de wrote:

 Brandon Perry wrote:

  So, I am very curious how you are finding these? Have you automated this
 or
  is it manual hand work?

 All my Windows installations have
 http://home.arcor.de/skanthak/download/SENTINEL.EXE and
 http://home.arcor.de/skanthak/download/SENTINEL.DLL preinstalled as
 C:\Program.exe and C:\Program.dll, so I'm notified when some poorly written
 program tries to execute them.
 The sentinels call MessageBox() with MB_SERVICE_NOTIFICATION, so the
 messages are recorded in the event log too where I can find them later.

 I also preinstall an APPINIT.DLL https://support.microsoft.com/kb/197571
 which

Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account

[Stefan Kanthak]

Hi @ll,

the import function of Windows Mail executes a rogue program C:\Program.exe
with the credentials of another account, resulting in a privilege escalation!

1. Fetch http://home.arcor.de/skanthak/download/SENTINEL.EXE and save it as
   C:\Program.exe

2. Start Windows Mail (part of Windows Vista and Windows Server 2008)

3. On the File menu, click Identities

4. On the entry page of the wizard click [ Continue  ]

5. Select (*) Import identities of other Windows account and click [ Continue 
 ]

6. Enter account name and password of any Windows account

7. See the message from C:\Program.exe when Windows Mail runs the UNQUOTED
   command line C:\Program Files\Windows Mail\WinMail.Exe /identcatalog


From http://msdn.microsoft.com/library/cc144175.aspx
or 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.


From http://msdn.microsoft.com/en-us/ms682425.aspx:

| Security Remarks
|
| The lpApplicationName parameter can be NULL, and the executable name
| must be the first white space-delimited string in lpCommandLine.
| If the executable or path name has a space in it, there is a risk that
| a different executable could be run because of the way the function
| parses spaces. Avoid the following example, because the function
| attempts to run Program.exe, if it exists, instead of MyApp.exe.
...
| If a malicious user were to create an application called Program.exe
| on a system, any program that incorrectly calls CreateProcess using
| the Program Files directory will run this application instead of the
| intended application.
|
| To avoid this problem, do not pass NULL for lpApplicationName.
| If you do pass NULL for lpApplicationName, use quotation marks around
| the executable path in lpCommandLine, as shown in the example below.


Long filenames were introduced 20 years ago, but M$FTs developers still
can't handle them properly, and their QA is unable to detect such silly
and trivial to spot bugs!


regards
Stefan Kanthak

PS: yes, it needs administrative privileges to write C:\Program.exe.
BUT: all the user account(s) created during Windows setup have
administrative privileges.

PPS: NO, the user account control is NO security boundary!

 http://support.microsoft.com/kb/2526083

| Same-desktop Elevation in UAC is not a security boundary and can be hijacked
| by unprivileged software that runs on the same desktop. Same-desktop
| Elevation should be considered a convenience feature, and from a security
| perspective, Protected Administrator should be considered the equivalent
| of Administrator.

iTunes 11.2.2 for Windows: completely outdated and vulnerable 3rd party libraries

[Stefan Kanthak]

Hi @ll,

Apples current iTunes 11.2.2 for Windows comes with the following
COMPLETELY outdated and vulnerable 3rd party libraries (as part of
AppleApplicationSupport.msi):

* libeay32.dll and ssleay32.dll 0.9.8d

  are more than SEVEN years old and have at least 27 unfixed CVEs!
  the current version is 0.9.8za, see http://www.openssl.org/news/


* libcurl.dll 7.16.2

  is more than SEVEN years old and has at least 18 unfixed CVEs!
  the current version is 7.37.0;
  see http://curl.haxx.se/docs/security.html
  for the fixed vulnerabilities!


* libxml2.dll 2.6.0.0

  is more than TEN years old and has at least 17 unfixed CVEs!
  the current version is 2.9.1, for the latest vulnerability see
  CVE-2013-0339


* icuuc40.dll, icuin40.dll, icudt49.dll, libicuuc.dll and libicuin.dll 49.1.1

  have at least 4 unfixed CVEs: CVE-2013-2419, CVE-2013-2383, CVE-2013-2384,
  CVE-2013-1569


Until Apples developers start to develop a sense for safety and security:
stay away from their (Windows) software!


regards
Stefan Kanthak


Timeline:
~

2014-06-06informed vendor

2014-06-06vendor sent automated response

... no more reaction

2014-07-03requested status

... no answer

2014-07-07report published

Defense in depth -- the Microsoft way (part 15): unquoted arguments in 120 (of 462) command lines

[Stefan Kanthak]

\WPDContextMenu.Url\Shell\Open\Command]
@=expand:\\%SystemRoot%\\system32\\rundll32.exe\ 
\%SystemRoot%\\system32\\ieframe.dll\,OpenURL %l

[HKEY_CLASSES_ROOT\WSFFile\Shell\Edit\Command]
@=expand:\\%SystemRoot%\\system32\\Notepad.exe\ %1

[HKEY_CLASSES_ROOT\WSFFile\Shell\Print\Command]
@=expand:\\%SystemRoot%\\system32\\Notepad.exe\ /p %1

[HKEY_CLASSES_ROOT\xhtmlfile\shell\open\command]
@=\C:\\Program Files\\Internet Explorer\\iexplore.exe\ %1

[HKEY_CLASSES_ROOT\xhtmlfile\shell\opennew\command]
@=\C:\\Program Files\\Internet Explorer\\iexplore.exe\ %1

[HKEY_CLASSES_ROOT\xmlfile\shell\Open\command]
@=\C:\\Program Files\\Internet Explorer\\iexplore.exe\ %1

[HKEY_CLASSES_ROOT\xslfile\shell\Open\command]
@=\C:\\Program Files\\Internet Explorer\\iexplore.exe\ %1

[HKEY_CLASSES_ROOT\zapfile\shell\open\command]
@=expand:%SystemRoot%\\system32\\NOTEPAD.EXE %1

[HKEY_CLASSES_ROOT\zapfile\shell\print\command]
@=expand:%SystemRoot%\\system32\\NOTEPAD.EXE /p %1

[HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\Hotmail\Protocols\mailto\shell\open\command]
@=expand:%SystemRoot%\\system32\\rundll32.exe \%ProgramFiles%\\Internet 
Explorer\\hmmapi.dll\,MailToProtocolHandler %1


OUCH!
120 command lines (out of 462, ie 25.9%) have an unquoted argument.


Cf. 
https://blog.mozilla.org/security/2007/07/10/security-issue-in-url-protocol-handling-on-windows/,
http://blogs.msdn.com/b/david_leblanc/archive/2007/07/24/security-dependencies.aspx
http://weblogs.mozillazine.org/asa/archives/2007/07/its-just-too-ha.html
https://technet.microsoft.com/library/security/ms07-061

Quotes bite, but missing quotes bite too^Wmore!


regards
Stefan Kanthak


PS: the following command lines with unquoted pathnames execute C:\Program.exe:

[HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Media\Windows Media 
Player\shell\open\command]
@=expand:%ProgramFiles%\\Windows Media Player\\wmplayer.exe

[HKEY_LOCAL_MACHINE\SOFTWARE\Clients\StartMenuInternet\IEXPLORE.EXE\shell\open\command]
@=C:\\Program Files\\Internet Explorer\\iexplore.exe

[HKEY_CLASSES_ROOT\CLSID\{D8559EB9-20C0-410E-BEDA-7ED416AECC2A}\Shell\Open\Command]
@=expand:%ProgramFiles%\\Windows Defender\\MSASCui.exe

That's the FOURTH time Windows Defender resp. Microsoft Security Essentials
comes with an unquoted pathname in the command line, cf.
https://technet.microsoft.com/library/security/ms13-058
https://technet.microsoft.com/library/security/ms13-034
http://seclists.org/fulldisclosure/2013/May/10

Beginners error: Hewlett-Packards driver software executes rogue binary C:\Program.exe

[Stefan Kanthak]

Hi @ll,

several programs of the current Windows 7 driver software for the
HP OfficeJet 6700 multifunction device execute a rogue program
C:\Program.exe


The evidence (an excerpt from the SAFER log, cf.
http://technet.microsoft.com/en-us/library/bb457006.aspx or
https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/safer_trouble.mspx):


HPScanDisco.exe (PID = 3980) identified C:\Program.exe as Unrestricted using 
default rule, Guid =
{11015445-d282-4f86-96a2-9e485f593302}
FaxApplications.exe (PID = 3148) identified C:\Program.exe as Unrestricted 
using default rule, Guid =
{11015445-d282-4f86-96a2-9e485f593302}
ScanToPCActivationApp.exe (PID = 2944) identified C:\Program.exe as 
Unrestricted using default rule, Guid =
{11015445-d282-4f86-96a2-9e485f593302}


In every instance these programs try to execute
C:\Program Files\HP\HP Officejet 6700\Bin\HPNetworkCommunicatorCom.exe


The vulnerability is the result of calling Windows' CreateProcess*()
with an unquoted command line containing spaces!

Cf. http://msdn.microsoft.com/library/cc144175.aspx or
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.


HP: would you mind to hire just a few people for a little bit of QA?
And some more to teach beginner courses on (Windows) programming to
your developers?

Long filenames containing spaces are used in Windows for 20 years
now and your developers still dont get them right?


regards
Stefan Kanthak


JFTR: the driver for the HP OfficeJet 6700 is not the only one from HP
  with such a trivial to detect bug and vulnerability.


Timeline:
~

2014-04-14sent vulnerability report to vendor

2014-04-14vendor replies: forwarded to responsible division, will
  keep you informed

...

2014-05-17request status

2014-05-19vendor replies: no information from the lab

2014-05-20vendor replies:
  after looking at this problem and discussing it previously
  with Microsoft MSRC, we have decided that this unquoted
  registry string is not a security issue.
  ...
  We are not going to be issuing a patch or security bulletin
  for this issue.

JFTR: the vulnerable pathname is NOT in the registry, but in the code!

2014-05-20report published

Buggy insecure security software executes rogue binary during installation and uninstallation

[Stefan Kanthak]

Hi @ll,

the $*#§ware by the name of McAfee Security Scanner Plus that Adobe dares
to push to unsuspecting users of Microsoft Windows trying to get flash player
from their main distribution page hxxp://get.adobe.com/flashplayer/ was
developed, packaged and tested by people who obviously never heard of long
filenames which may contain spaces.

From http://msdn.microsoft.com/library/cc144175.aspx
or 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.


When the unsuspecting Joe Average clicks the Install now button on the
above mentioned download page, but forgets to deselect the optional offer
McAfee Security Scanner Plus before, a file named
install_flashplayer13x32_mssa_aaa_aih.exe
is downloaded to directory C:\Users\Joe Average\Downloads.

Following the instructions displayed after the download, Joe Average opens
the download directory and double clicks
install_flashplayer13x32_mssa_aaa_aih.exe

On recent versions of Microsoft Windows this triggers the user account
control, asking Joe Average for consent to continue with administrative
privileges.

install_flashplayer13x32_mssa_aaa_aih.exe
now copies itself to the TEMP directory and executes its copy with the
argument (note the missing quotes.-)
{RemoveFile:C:\Users\Joe 
Average\Downloads\install_flashplayer13x32_mssa_aaa_aih.exe}

The copy then downloads its payload gtbcheck.exe, install_flash_player.exe
and SecurityScan_Release.exe into the directory
C:\Users\Joe Average\AppData\Local\Adobe\AIH.40_hex_digits\
and executes these three programs in succession.

The last, SecurityScan_Release.exe, an NSIS installer, unpacks its payload
into directory C:\Program Files\McAfee Security Scan\version\ and calls
Windows' CreateProcess() function (see above) with the UNQUOTED command line
C:\Program Files\McAfee Security Scan\3.0.285\McCHSvc.exe /Service

This command line now runs the rogue program C:\Program.exe which was placed
there waiting for some dimwit of a developer to call CreateProcess() with an
unquoted command line.


Fortunately Joe Average (really: his Administrator) had a hunch and placed
http://home.arcor.de/skanthak/download/SENTINEL.EXE as C:\Program.exe on
his system which displayed a message box to Joe Average informing him that
some crappy software may have just run malware on his PC.

This caught the silly beginners mistake of a company that brags with

| For award-winning customer service, please visit our Web
| site that will have answers to almost all questions concerning
| our company:
|  == http://service.mcafee.com

in automated replies to mail sent to supp...@mcafee.com but does not
provide a mailbox to report bugs or vulnerabilities.


JFTR: english versions of Windows have a Program Files directory for
  nearly 20 years now. That should REALLY be enough time for EVERY
  programmer to learn how to properly handle pathnames with spaces.


To complete the story: when Joe Average noticed what was done to him he
opened the Windows control panel and went to uninstall programs, then
selected McAfee ... and clicked uninstall.

This started C:\Program Files\McAfee Security Scan\uninstall.exe
which unpacked its payload Au_.exe (see above: it's an NSIS installer)
to TEMP and called it with the argument (again note the missing quotes)
 _?=C:\Program Files\McAfee Security Scan\

Au_.exe in turn called Windows' CreateProcess() function with the
(you guess it) UNQUOTED command line
C:\Program Files\McAfee Security Scan\3.0.285\McCHSvc.exe /unregserver
which again led to execution of C:\Program.exe


regards
Stefan Kanthak

Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 13): surprising and inconsistent behaviour, sloppy coding, sloppy QA, sloppy documentation

[Stefan Kanthak]

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

[Full-disclosure] Defense in depth -- the Microsoft way (part 13): surprising and inconsistent behaviour, sloppy coding, sloppy QA, sloppy documentation

[Stefan Kanthak]

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/

Defense in depth -- the Microsoft way (part 14): incomplete, misleading and dangerous documentation

[Stefan Kanthak]

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

Re: Word 2003 SP2 .doc fork bomb on WinXP SP3

[Stefan Kanthak]

Someone without a name wrote:

 # Exploit Title: Word 2003 SP2 .doc fork bomb on WinXP SP3

[...]

 # Tested on: Windows XP SP3  Word 2003 SP2 (11.6568.6568)  

OUCH!

The current service pack for Office 2003 and Word 2003 is SP3.
The current version of Word 2003 is 11.0.8407, see
https://support.microsoft.com/kb/2826020 alias
http://technet.microsoft.com/security/bulletin/MS13-086

Whoever uses outdated and vulnerable versions of products is just stupid!

Stefan Kanthak

Defense in depth -- the Microsoft way (part 12): NOOP security fixes

[Stefan Kanthak]

Hi @ll,

with http://technet.microsoft.com/security/bulletin/ms12-034
Microsoft addressed CVE-2012-0181 for Windows NT 5.x; see
https://support.microsoft.com/kb/2686509 for details.

BUT: the hotfix KB2686509 does NOT fix anything!

Instead it just checks ONCE(!) whether all the keyboard layout DLLs
registered beneath

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout\LCID]
LayoutFile=KBD*.DLL

are either registered with their fully-qualified pathname or exist in
%SystemRoot%\System32.

This STATIC, ONE TIME check but does NOT cure the problem, it only checks
for the symptom!

If Microsoft would REALLY care about security, the hoxfix KB2686509 (or
better: Windows setup) would (re)write all references to filenames with
their fully-qualified pathname, i.e. as

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout\LCID]
LayoutFile=%SystemRoot%\\System32\\KBD*.DLL


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

2012-05-08vendor publishes http://support.microsoft.com/kb/2686509
  alias
  http://technet.microsoft.com/security/bulletin/ms12-034


stay tuned
Stefan Kanthak


PS: if Microsoft weren't such sloppy coders and had a QA department this
whole class of vulnerabilities would not exist: the path to EVERY
executable in Windows is well-known, all references can use the
fully-qualified, absolute pathname.

http://home.arcor.de/skanthak/download/XP_FIXIT.INF fixes all the
2500+ unqualified (plus not properly quoted long) filenames left in
the registry of Windows XP SP3 AFTER fixing the other 2000+ unqualified
(plus not properly quoted long) filenames in the \i386\HIVE*.INF and
\i386\DMREG.INF (from which the initial registry is built) on the
installation media.

http://home.arcor.de/skanthak/download/W7_ERROR.INF documents the
4500+ unqualified filenames in the registry of Windows 7 Professional
with SP1, and http://home.arcor.de/skanthak/download/W7_ISSUE.INF
documents some other issues.

Defense in depth -- the Microsoft way (part 11): privilege escalation for dummies

[Stefan Kanthak]

Hi @ll,

in http://seclists.org/fulldisclosure/2013/Sep/132 I showed a
elaborated way for privilege elevation using IExpress (and other
self-extracting) installers containing *.MSI or *.MSP which works
in certain situations.

The same IExpress installer(s) but allow a TRIVIAL to exploit
privilege escalation which works in all situations too:

Proof of concept (run on a fully patched Windows 7 SP1):

Step 0:
   login as UAC-enabled user.

Step 1:
   download the IExpress package CAPICOM-KB931906-v2102.exe from
   http://www.microsoft.com/en-us/download/details.aspx?id=3207
   resp. http://technet.microsoft.com/security/bulletin/ms07-028

Step 2:
   download http://home.arcor.de/skanthak/download/SENTINEL.EXE
   (note: all downloads go per default into the same directory)
   as MSIEXEC.EXE (this executable is just used as a canary).

Step 3:
   execute the downloaded CAPICOM-KB931906-v2102.exe (UAC will
   ask for confirmation or prompt for administrative credentials).


Result:
   the downloaded MSIEXEC.EXE is executed with administrative
   credentials!


Reason:
   the COMPLETELY SUPERFLUOUS elevation of IExpress packages through
   UAC (due to its braindead installer detection).


Note 0:
   it is completely sufficient to run IExpress packages unprivileged/
   unelevated: the target directory for the extraction,
   %TEMP%\IXP000.TMP, can be created/written with standard user
   rights!

Note 1:
   if the downloaded MSIEXEC.EXE requests elevation by itself UAC
   displays the publisher name etc. read from the digital signature
   of the downloaded MSIEXEC.EXE giving the user a chance to detect
   the fake MSIEXEC.EXE.

Note 2:
   if an IExpress installer executes another command (setup.exe,
...) rename the downloaded file to the resp. name.

Note 3:
   of course other self-extractors which execute commands without
   fully qualified path (remember: the application directory is
   searched first) can be used too!

Note 4:
   in general, setup PROGRAMS are evil!

   there is no need to wrap a call of MSIEXEC.EXE /package *.MSI
   or RUNDLL32.EXE SETUPAPI.DLL,InstallHinfSection ... *.INF
   into an executable!

   at least Microsoft stopped to deliver updates/hotfixes/patches
   for NT6.x as executables, but uses CAB archives named *.MSU.


Timeline:
~

2013-09-22sent report to vendor

2013-09-23vendor replies and asks: is the vulnerability in IExpress?

2013-09-23NO, the vulnerability results from the UAC!

2013-09-23vendor replies: this scenario has been publicly known,
  and was mentioned in a presentation a Black Hat in 2012.
  the resolution was to implement a policy that IExpress
  will no longer be used on Microsoft Update.

  Really  really?

  The Black Hat presentation used IExpress to wrap and
  disguise a MetaSploit/meterpreter payload, not for a
  privilege escalation.

  http://www.microsoft.com/en-us/download/details.aspx?id=39802
  alias http://support.microsoft.com/kb/931125 is an
  IExpress package AND is delivered via Microsoft Update!

2013-09-23asked about the details of the Black Hat presentation and
  whether/when the SUPERFLUOUS detection and elevation of
  IExpress installers will be addressed.

2013-09-30vendor replies: I still do not see any security vulnerability
  here. I can see an escalation of UAC privileges, but as has
  been documented on numerous occasions*, UAC is not considered
  to be a security boundary, so such an escalation is not
  considered to be a security vulnerability.

2013-10-02report published


stay tuned
Stefan Kanthak

Re: %windir%\temp\sso\ssoexec.dll (or: howtrustworthy is Microsoft's build process)

[Stefan Kanthak]

This is a followup to http://seclists.org/fulldisclosure/2012/Mar/17
and http://seclists.org/fulldisclosure/2013/Aug/225:

On Sunday, March 04, 2012 9:06 PM I wrote:

 Hi @ll,
 
 the system image \Setup\WIM\setup.wim on the POSReady 2009 eval CD,
 available from the Microsoft Download Center under
 http://www.microsoft.com/downloads/en/details.aspx?FamilyID=1e077ece-3f19-4c41-b219-6fcc821fb5fc,
 contains the following registry entries:
 
 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows 
 NT\CurrentVersion\Winlogon\Notify\SSOExec]
 Asynchronous=dword:0001
 Impersonate=dword:0001
 Logoff=SSOReset
 Unlock=SSOExec
 Lock=SSOReset
 DLLName=%windir%\\temp\\sso\\ssoexec.dll

[...]

 To complete the picture: the ACLs on the directory %windir%\temp in
 systems installed from this image/CD allow unprivileged users to create
 a subdirectory sso in %windir%\temp and then the ssoexec.dll,
 allowing them to have their code run under every (other) user account
 used to log on afterwards, resulting in a privilege escalation.

After I learned that the same vulnerability exists in EVERY installation
of Windows Embedded POSReady 2009 I contacted a vendor and Microsoft
again.

The vendor got the following reply from Microsoft:

| The Microsoft Windows Embedded Product team, along with the MSRC 
| (Microsoft Security Response Center) team researched this in early
| 2012 and determined that this is a not a vulnerability because 
   ~
| Microsoft Malware Protection Center does not consider this to be 
  
| malware.
  

OUCH! How absurd!

| It was determined that these keys came from XP Embedded and 
| the Standard Windows Logon Component. They found no evidence of 
| malware on our build systems and the presence of the keys is not
| an indication that malware was ever present on the systems

There is no file ssoexec.dll in Windows Embedded POSReady 2009!
As far as I know there is no file by this name in ANY version/variant
of Windows!

I requested clarification about these absurd statements and whether
a hotfix will be provided from the MSRC sec...@microsoft.com and
got the following answer:

| Could you explain how the EOP attack works using this DLL?
| Normal users don't have write permission to %windir%, and if an
| attacker controls an Administrator account then they've already
| defeated security.

to which I replied:

| The directory in question is but %windir%\temp\!
| In Windows Embedded POSReady 2009 UNPRIVILEGED users can create
| the subdirectory sso\ and the DLL ssoexec.dll.
| Game over!

which yield another absurd answer from the MSRC:

| After some research, it appears this EOP attack requires that the
| attacker has already violated one of the 10 Immutable Laws of Security
| (http://technet.microsoft.com/library/cc722487.aspx ), most notably
| laws #1 or #3. You should read the article to understand why those
| laws matter.

OUCH! I asked the MSRC again:

| which part of In Windows Embedded POSReady 2009 UNPRIVILEGED users
| can create the subdirectory sso\ and the DLL ssoexec.dll is not
| understood?

and got the final answer:

| We are aware of the issues and arguments you've mentioned. An attacker
| in a position to carry out these attacks could also carry out many
| other attacks we can't stop. The link provided below explains this in
| detail.

OUCH!

Stefan Kanthak

Defense in depth -- the Microsoft way (part 9): erroneous documentation

[Stefan Kanthak]

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

Defense in depth -- the Microsoft way (part 8): execute everywhere!

[Stefan Kanthak]

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

Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 8): execute everywhere!

[Stefan Kanthak]

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 ]

Windows Embedded POSReady 2009: cruft, not craft

[Stefan Kanthak]

\\NWWia\\XrxFTPLt.exe

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ati HotKey Poller]
Start=dword:0002
Type=dword:0110
ErrorControl=dword:0001
ImagePath=expand:system32\\atievxx.exe
ObjectName=LocalSystem
Group=Event log

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\AssetManagement]
EventMessageFile=expand:C:\\WINDOWS\\system32\\CCM\\ccm_caltrack.dll
TypesSupported=dword:0007

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\LiveMeeting]
TypesSupported=dword:0007
EventMessageFile=expand:C:\\PROGRA~1\\MICROS~3\\LIVEME~1\\Console\\MUI\\0409\\UCCPRES.dll

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\SmsClient]
EventMessageFile=expand:C:\\WINDOWS\\system32\\CCM\\climsgs.dll
TypesSupported=dword:0007

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Pctspk]
Start=dword:0002
Type=dword:0010
ErrorControl=dword:0001
ImagePath=expand:system32\\pctspk.exe
DisplayName=PCTEL Speaker Phone


Needless to say: all the files referenced in this debris are NOT present
in the system image, and all the device drivers who had registry keys
created under [HKEY_LOCAL_MACHINE\SOFTWARE\%vendor%] are missing too.

Whoever built this system image apparently did not start from a clean
environment, installed superfluous components like LiveMeeting Console
and System Center Configuration Management Client, used unsuitable
tools to integrate 3rd-party drivers, and used unsuitable tools to
prepare it for deployment.

Is this trustworthy computing? Software engineering? Due diligence?
And what about quality assurance?

JFTR: the unqualified filenames used in this cruft are nice targets for
  binary planting attacks!


stay tuned
Stefan Kanthak

Defense in depth -- the Microsoft way (part 7): executable files in data directories

[Stefan Kanthak]

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:

Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure

[Stefan Kanthak]

Reindl Harald h.rei...@thelounge.net wrote:

 Am 12.08.2013 23:32, schrieb coderaptor:
 Why can't enable_functions be pre-populated with known good functions, and 
 everything else disabled? Again,
 sacrificing security convenience is the norm.

 if you would only have the slightest clue what you are speaking about
 you would not ask that naive

 [harry@srv-rhsoft:~]$ php -r print_r(get_defined_functions()); | wc -l
 1330

 oh, and they depend on the loaded extensions (inlcuding 3rd party extensions)

 oh, and they *all* would have to be classified if, how and in which context
 they all may or may not have a secuirity impact

That's one of the duties/tasks of their developer(s): WTFM!

 ALL software MUST come with SECURE DEFAULTS. PERIOD. Anyone who thinks 
 otherwise should fly in an aircraft running
 his own designed software. Knowledgeable Admins are not an alternative to 
 secure defaults, rather I'd prefer both.

 *define what is secure* and make sure you define it by context

 unlink('file_my_script_wrote'); is fine

No, its UNSAFE!
The standard use case of PHP is preprocessor for HTTP demon.
There is ABSOLUTELY no need to allow the preprocessor to unlink a file.

 unlink($_GET['what_ever_input']): is a security hole

No, not necessarily. The user who can run

$ php -r unlink($_GET['what_ever_input']);

can also run

$ rm $SOMEFILE

OTOH: the user who can instruct his web browser to fetch
http://example.org/index.html is not able to unlink $SOMEFILE by
calling rm.

 so do we now disable unlink();

Not WE, but the developer.
All functions which are not used in the typical operating
environment of the resp. program (see above) have to be turned
off by default. file handling is NONE of PHPs typical operations!

Stefan Kanthak

Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure

[Stefan Kanthak]

Reindl Harald h.rei...@thelounge.net wrote:

 Am 10.08.2013 16:52, schrieb Tobias Kreidl:
 It is for this specific reason that utilities like suPHP can be used as a 
 powerful tool to at least keep the
 account user from shooting anyone but him/herself in the foot because of any 
 configuration or broken security
 issues. Allowing suexec to anyone but a seasoned, responsible admin is IMO a 
 recipe for disaster.

 and what makes you believe that a developer can not be a seasoned, 
 responsible admin?

Because developers write functions like system, symlink and suexec
which can create havoc (and are WELL-KNOWN for creating havoc since
years) and allow everybody to call them in the default configuration of
their software.

 bullshit, many of the seasoned, responsible admins which are only
 admins are unable to really understand the implications of whatever
 config they rollout

It was the developer who created and published this vulnerable software
or the vulnerable default configuration in the first place.

If a user/administrator who installs software has to turn insecure
features OFF its the developer who is to blame, and of course the
testers, the QA and the management too.

Stefan Kanthak

Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure

[Stefan Kanthak]

Reindl Harald h.rei...@thelounge.net wrote:

 Am 11.08.2013 22:15, schrieb Stefan Kanthak:
 Reindl Harald h.rei...@thelounge.net wrote:
 Am 10.08.2013 16:52, schrieb Tobias Kreidl:
 It is for this specific reason that utilities like suPHP can be used as a 
 powerful tool to at least keep the
 account user from shooting anyone but him/herself in the foot because of 
 any configuration or broken security
 issues. Allowing suexec to anyone but a seasoned, responsible admin is IMO 
 a recipe for disaster.

 and what makes you believe that a developer can not be a seasoned, 
 responsible admin?
 
 Because developers write functions like system, symlink and suexec
 which can create havoc (and are WELL-KNOWN for creating havoc since
 years) and allow everybody to call them in the default configuration of
 their software.

 a so because some stupid developers all are faulty?

If you say so: OK.
Read again what I wrote, carefully!

 bullshit, many of the seasoned, responsible admins which are only
 admins are unable to really understand the implications of whatever
 config they rollout
 
 It was the developer who created and published this vulnerable software
 or the vulnerable default configuration in the first place.

 it was the admin who did not RTFM and rolled out default
 settings in environents with untrustable code

JFTR: untrustable  vulnerable!

Read again what I wrote, carefully.

If you'd have a clue you may have heard of concepts like fail safe
or safe default configuration.
ANY software with an insecure default configuration is DEFECTIVE!

JFTR: why should gazillions of users/administrators fix the fault(s)
of a single/few developer(s)?

 If a user/administrator who installs software has to turn insecure
 features OFF its the developer who is to blame, and of course the
 testers, the QA and the management too

 not entirely untrue, but anybody who thinks he can install
 whatever server-software with defaults, not RTFM and call
 hiself a serious admin is a fool

Why not: I expect every developer to exercise all due diligence,
test the code, and ship it with a SECURE default configuration.
Software with an insecure default configuration is DEFECTIVE!

 again:
 symlinks are to not poision always and everywhere
 they become where untrusted customer code is running
 blame the admin which doe snot know his job and not
 the language offering a lot of functions where some
 can be misused

Again: symlinks are well-known as attack vector for years!

It's not the user/administrator who develops or ships insecure
code!

Stefan

OUTDATED, UNSUPPORTED and VULNERABLE 3rd party components installed with Exact Audio Copy

[Stefan Kanthak]

Hi,

Exact Audio Copy (see http://www.exactaudiocopy.de/) V1.0 beta 3,
released 2011-09-11, installs the following OUTDATED, UNSUPPORTED
and VULNERABLE 3rd party components:

1. Microsoft SQL Server Compact 3.5 Service Pack 1:

| X:\filever.exe /S %ProgramFiles%\Exact Audio Copy\sqlce*.dll
|x:\program files\exact audio copy\sqlce*.dll
| --a-- W32i   DLL ENU  3.5.5692.0 shp343,104 06-25-2008 sqlceca35.dll
| --a-- W32i   DLL ENU  3.5.5692.0 shp 84,544 06-25-2008 
sqlcecompact35.dll
| --a-- W32i   DLL ENU  3.5.5692.0 shp172,608 06-25-2008 
sqlceoledb35.dll
| --a-- W32i   DLL ENU  3.5.5692.0 shp644,160 06-25-2008 sqlceqp35.dll
| --a-- W32i   DLL ENU  3.5.5692.0 shp348,224 06-25-2008 sqlcese35.dll

   Support end for SQL Server Compact 3.5 Service Pack 1 was on
   2011-06-29, see http://support.microsoft.com/lifecycle/?p1=2855

   Its supported successor, Microsoft SQL Server Compact 3.5
   Service Pack 2 for Windows Desktop is available since 2010-05-17,
   see http://www.microsoft.com/en-us/download/details.aspx?id=5783


2. From the REDIST.TXT included in the SQL Compact Edition:

| Private deployment of just the native stack and explicit loading
| of SQL Server Compact Assembly via Assembly.LoadFrom(), .local
| file, or the use of DLL/COM redirection strategies are not
| supported and may result in serviceability issues.
| For more information see http://support.microsoft.com/kb/835322
| and http://msdn2.microsoft.com/en-us/library/aa375142.aspx


3. MSVC++ 2005 runtime libraries 8.0.50727.4053:

| X:\filever.exe /S %ProgramFiles%\Exact Audio Copy\Microsoft.VC80.CRT
|x:\program files\exact audio copy\microsoft.vc80.crt\*.*
| --a---   -   -   -   -455 12-07-2009 
microsoft.vc80.crt.manifest
| --a-- W32i   DLL ENU  8.0.50727.4053 shp632,656 07-12-2009 msvcr80.dll

   The current version of the MSVCRT++ 2005 runtime is available
   since 2011-04-11, see http://support.microsoft.com/kb/2538243
   alias http://technet.microsoft.com/security/bulletin/ms11-025

   JFTR: See http://support.microsoft.com/kb/835322

   When installed via the MSVCRT++ redistributable package,
   Windows Update but keeps this component up-to-date!


Stefan Kanthak


Timeline:
~

2013-08-06informed developer

2013-08-06developer replies:

  a. EAC was released two months after the release of
 the service pack

  2011-09-11 is two months later than 2010-05-17?

  b. EAC is written in Modula II and needs no MSVCRT++

  The satellites used by EAC but need it!

  c. EAC uses SQL Compact DLLs from Microsoft, which
 request the exact library version in their manifest
 (Visual Studio 8 enforces this). Since I use the 
 latest SQL Compact Installation I had to include the
 corresponding MSVCRT++ DLLs

  Really?
  - the manifests of the sqlce*35.dlls refer to version
8.0.50608.0
  - Visual Studio does not enforce anything in a manifest
  - see http://msdn.microsoft.com/library/aa375680.aspx!
  - the latest SQL Compact Edition is NOT used, see above
  - the corresponding DLLs version 8.0.50608.0 are NOT
included

  d. what does 'application local' mean?

  OUCH!
  Obviously, the developer has no clue how manifests and
  side-by-side installations work and didnt notice the
  contents of REDIST.TXT

2013-08-07replied with all the details
  
2013-08-07developer replies: write your own EAC

Defense in depth -- the Microsoft way (part 6): beginner's errors, QA sound asleep or out of sight!

[Stefan Kanthak]

\\Uninstall\\setup.exe -uninstall


stay tuned
Stefan Kanthak


PS: if you want to catch such beginners errors place a copy of
http://home.arcor.de/skanthak/download/SENTINEL.EXE as
%SystemDrive%\PROGRA.EXE on your Windows system(s).

If running on WinSta0 SENTINEL.EXE displays a message box
listing the pathname of the executed process, its command line
and the working directory.

If you want to get rid of the message box Rogue program ...
displayed during login add the following registry entry:


[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\DontShowMeThisDialogAgain]
RogueProgramName=Yes


But there are more directories like %ProgramFiles%
alias %SystemDrive%\Program Files; start a command prompt
and run the following commands to list them:

For /D /R %SystemRoot% %X In (* *) Do @Echo %X
For /D /R %ProgramFiles% %X In (* *) Do @Echo %X
If Defined ProgramFiles(x86) For /D /R %ProgramFiles(x86)% %X In (* *) 
Do @Echo %X

In case that %CommonProgramFiles%/%CommonProgramFiles(x86)%
are no subdirectories of %ProgramFiles%/%ProgramFiles(x86)% run
the commands for these directories too.


And: execution of command lines like
%SystemRoot%\System32\REGSVR32.EXE %ProgramFiles%\...\filename[.DLL]
%SystemRoot%\System32\RUNDLL32.EXE 
%ProgramFiles%\...\filename[.DLL],Entry
will run a rogue DLL %SystemDrive%\PROGRA.DLL.

To catch the latter, place a copy of
http://home.arcor.de/skanthak/download/SENTINEL.DLL as
%SystemDrive%\PROGRA.DLL on your Windows system(s).

If running on WinSta0 SENTINEL.DLL displays a message box
listing the pathname of the executed DLL, the pathname of the
calling process, its command line and the working directory.

Test it with RUNDLL32.EXE SENTINEL.DLL,Entry


For completeness sake: run the batch script
http://home.arcor.de/skanthak/download/SENTINEL.CMD
(with administrative rights) to place SENTINEL.{EXE,DLL} as
%SystemDrive%\PROGRA.{EXE,DLL}, %ProgramFiles%\COMMON.{DLL,EXE},
%ProgramFiles(x86)%\COMMON.{DLL,EXE} and SENTINEL.EXE with the
appropiate filename next to every directory with space(s) in its
name.

The latter is necessary to catch command lines like
C:\PROGRA~1\Common Files\...\filename[.extension] or
C:\PROGRA~1\COMMON~1\Microsoft Shared\...\filename[.extension] etc.

Defense in depth -- the Microsoft way (part 4)

[Stefan Kanthak]

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!

VULNERABLE (3rd party) components in Adobe Reader 11.0.03, and dangling reference to Acrobat.exe

[Stefan Kanthak]

AppName=AdobeCollabSync.exe
AppPath=X:\\Program Files\\Adobe\\Reader 11.0\\Reader

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Low 
Rights\ElevationPolicy\{9C6A861C-B233-4994-AFB1-C158EE4FC578}]
Policy=dword:0003
AppPath=X:\\Program Files\\Adobe\\Reader 11.0\\Reader
AppName=AcroRd32.exe

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Low 
Rights\ElevationPolicy\{A2397324-4D73-4870-A795-995C56F49FBD}]
Policy=dword:0001
AppPath=X:\\Program Files\\Adobe\\Reader 11.0\\Reader
AppName=arh.exe


If the wise guys at Adobe know the platform on which their product runs
a little better they'd probably know that Low Rights\Elevation Policy
is supported on Windows Vista and later only.


Stefan Kanthak

PS: the PDF Preview Handlers which are installed unconditionally on
Windows XP are superfluous too (at least when Outlook 2007 is not
installed).
Cf. http://msdn.microsoft.com/library/cc144143.aspx

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.pdf\ShellEx\{8895b1c6-b41f-4c1c-a562-0d564250836f}]
@={49400A7C-81A8-4F52-8CCE-D54739EE87EC}

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{49400A7C-81A8-4F52-8CCE-D54739EE87EC}]
AppID={5D238751-7E51-4F24-9E7D-93C58881B20B}
DisplayName=@\X:\\Program Files\\Adobe\\Reader 
11.0\\Reader\\pdfprevhndlrshim.exe\,-101
@=Adobe PDF Preview Handler

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{49400A7C-81A8-4F52-8CCE-D54739EE87EC}\LocalServer32]
@=\X:\\Program Files\\Adobe\\Reader 11.0\\Reader\\pdfprevhndlrshim.exe\

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{49400A7C-81A8-4F52-8CCE-D54739EE87EC}\ProgID]
@=PDFPrevHndlrShim.PDFPrevHndlrShim.1

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{49400A7C-81A8-4F52-8CCE-D54739EE87EC}\Programmable]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{49400A7C-81A8-4F52-8CCE-D54739EE87EC}\TypeLib]
@={A58FB5B3-CF96-4C63-B0D2-232A1AEA1A1B}

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{49400A7C-81A8-4F52-8CCE-D54739EE87EC}\VersionIndependentProgID]
@=PDFPrevHndlrShim.PDFPrevHndlrShim

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{DC6EFB56-9CFA-464D-8880-44885D7DC193}]
AppID={6d2b5079-2f0b-48dd-ab7f-97cec514d30b}
@=Adobe PDF Preview Handler for Vista
DisplayName=@X:\\Program Files\\Adobe\\Reader 
11.0\\Reader\\pdfprevhndlr.dll,-101
DisableLowILProcessIsolation=dword:0001

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{DC6EFB56-9CFA-464D-8880-44885D7DC193}\InprocServer32]
@=X:\\Program Files\\Adobe\\Reader 11.0\\Reader\\pdfprevhndlr.dll
ThreadingModel=Apartment

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{DC6EFB56-9CFA-464D-8880-44885D7DC193}\ProgID]
@=PDFPrevHndlr.PDFPreviewHandler.1

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{DC6EFB56-9CFA-464D-8880-44885D7DC193}\TypeLib]
@={0F6D3808-7974-4B1A-94C2-3200767EACE8}

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{DC6EFB56-9CFA-464D-8880-44885D7DC193}\VersionIndependentProgID]
@=PDFPrevHndlr.PDFPreviewHandler

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PDFPrevHndlr.PDFPreviewHandler]
@=Adobe PDF Preview Handler for Vista

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PDFPrevHndlr.PDFPreviewHandler\CLSID]
@={DC6EFB56-9CFA-464D-8880-44885D7DC193}

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PDFPrevHndlr.PDFPreviewHandler\CurVer]
@=PDFPrevHndlr.PDFPreviewHandler.1

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PDFPrevHndlr.PDFPreviewHandler.1]
@=Adobe PDF Preview Handler for Vista

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PDFPrevHndlr.PDFPreviewHandler.1\CLSID]
@={DC6EFB56-9CFA-464D-8880-44885D7DC193}

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PDFPrevHndlrShim.PDFPrevHndlrShim]
@=Adobe PDF Preview Handler

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PDFPrevHndlrShim.PDFPrevHndlrShim\CLSID]
@={49400A7C-81A8-4F52-8CCE-D54739EE87EC}

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PDFPrevHndlrShim.PDFPrevHndlrShim\CurVer]
@=PDFPrevHndlrShim.PDFPrevHndlrShim.1

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PDFPrevHndlrShim.PDFPrevHndlrShim.1]
@=Adobe PDF Preview Handler

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PDFPrevHndlrShim.PDFPrevHndlrShim.1\CLSID]
@={49400A7C-81A8-4F52-8CCE-D54739EE87EC}

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\PreviewHandlers]
{49400A7C-81A8-4F52-8CCE-D54739EE87EC}=Adobe PDF Preview Handler
{DC6EFB56-9CFA-464D-8880-44885D7DC193}=Adobe PDF Preview Handler for Vista

Vulnerable Microsoft VC++ 2005 RTM runtime libraries installed with Microsoft Security Essentials (and numerous other Microsoft products)

[Stefan Kanthak]

Hi @ll,

this is part 2 of Defense in depth -- the Microsoft way, see
http://seclists.org/fulldisclosure/2013/May/107


On Windows NT 5.x the current Microsoft Security Essentials v4.2
(available from http://www.microsoft.com/security_essentials,
and offered as optional update KB2804527 via Microsoft Update)
as well as MANY other Microsoft products [*] install outdated and
vulnerable Microsoft Visual C++ Runtime Libraries MSVC?80.DLL
v8.0.50727.42


| C:\filever /S %SystemRoot%\msvc?80.dll
| 
c:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd\msvc*
| --a-- W32i   DLL ENU8.0.50727.42 shp479,232 09-22-2005 msvcm80.dll
| --a-- W32i   DLL ENU8.0.50727.42 shp548,864 09-22-2005 msvcp80.dll
| --a-- W32i   DLL ENU8.0.50727.42 shp626,688 09-22-2005 msvcr80.dll


These libraries come as part of the bundled component Microsoft
Application Error Reporting; its installer DW20Shared.msi contains
the outdated and vulnerable libraries (which are installed even if
a newer version is already present) in form of an MSI merge module
which in turn is part of Visual C++/Studio 2005 RTM, whose support
ended 2008-01-08, see
http://support.microsoft.com/lifecycle/search/default.aspx?sort=PNalpha=Visual+Studio+2005Filter=FilterNO

Current and supported versions of Visual C++/Studio 2005 SP1 come
with updated MSI merge modules, see
http://support.microsoft.com/kb/2643995


These libraries (as well as the MSI merge module) have been updated
multiple times since: see
http://support.microsoft.com/kb/919588
http://support.microsoft.com/kb/923610
http://support.microsoft.com/kb/932391
http://support.microsoft.com/kb/932392
http://support.microsoft.com/kb/973544 (alias MS09-035)
http://support.microsoft.com/kb/973882
http://support.microsoft.com/kb/2467175 (alias MS11-025)
http://support.microsoft.com/kb/2538242 (alias MS11-025)


Due to the end-of-life condition of Visual C++/Studio 2005 RTM the
security bulletins MS09-035 and MS11-025 dont list these old versions
any more.


The FAQ section of
http://technet.microsoft.com/en-us/security/bulletin/ms11-025 says:

| In the case where a system has no MFC applications currently installed
| but does have the vulnerable Visual Studio or Visual C++ runtimes
| installed, Microsoft recommends that users install this update as a
| defense-in-depth measure, in case of an attack vector being introduced
| or becoming known at a later time.

Of course the same holds for ATL applications (where MS09-035 recommends

| Developers who have built components and controls using ATL should
| download this update and recompile their components and controls
| following the guidance provided in the following MSDN article.

and refers to http://msdn.microsoft.com/en-us/vstudio/ee309358.aspx)
and CRT applications too.


The outdated and vulnerable libraries are NOT detected by the Windows
Update Agent and thus not replaced with their current version.


The VERY simple fix/mitigation: either uninstall DW20Shared.msi (run
MSIEXEC.EXE /X {9512-00B9-0409--000FF1CE})
or install the current MSVC++ 2005 Runtime Redistributable, see
http://support.microsoft.com/kb/2538242


Timeline:

2012-06-18vendor informed

2012-06-20vendor acknowledges receipt

2012-06-20sent additional info (log files)

2012-08-01vendor replies: not reproducible on Windows 7

2012-08-02sent additional info: only Windows XP and Server 2003
  are affected, can be seen in the log files sent before

2012-10-09sent additional info: (3rd party) products which dont
  ship a current MSVC++ 2005 Runtime are affected too

2012-11-29vendor replies: not able to find vulnerabilities

2012-11-29asked vendor what MS09-035 and MS11-025 are good for
  then, and for the purpose of their recommendations and
  FAQ

...

2013-06-03report published


Stefan Kanthak


[*] DW20Shared.msi is bundled with numerous other Microsoft products too,
including

* Windows Defender
* Forefront Security ...
* Office 2003 (and every single component of it, Word, Excel, PowerPoint,
  Outlook, Visio, Access, Publisher, OneNote, Project, ...)
* Office 2007 (and every single component of it, Word, Excel, PowerPoint,
  Outlook, Visio, Access, Publisher, OneNote, Project, ...)
* Office 2010 (and every single component of it, Word, Excel, PowerPoint,
  Outlook, Visio, Access, Publisher, OneNote, Project, ...)
* Office Communicator 2005
* Office Groove 2007
* Groove Server 2010
* Sharepoint Services 2.0
* Sharepoint Services 3.0
* SharePoint Designer 2007
* SharePoint Foundation 2010
* SharePoint Server 2010
* SQL Server 2005 Native Client
* SQL Server 2008 Native Client
* SQL Server 2010 Native Client
* SQL Server 2012 Native Client
* SQL Server Compact 3.5
* .NET Framework 2.0
* .NET Framework 3.0
* .NET Framework 3.5

Defense in depth -- the Microsoft way

[Stefan Kanthak]

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

Vulnerability in Fujitsu Desktop Update (for Windows)

[Stefan Kanthak]

Hi @ll,

Fujitsu's update utility Fujitsu Desktop Update (see
http://support.ts.fujitsu.com/DeskUpdate/Index.asp), which is
factory-preinstalled on every Fujitsu (Siemens) PC with Windows,
has a vulnerability which allows the execution of a rogue program
in the security context of the current user.


The application is registered as control panel item via

[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ControlPanel\NameSpace\{070B64FF-795D-4DAA-88AD-6D3277C7E445}]
@=Fujitsu DeskUpdate


The shell object with GUID {070B64FF-795D-4DAA-88AD-6D3277C7E445} is
registered with

[HKLM\SOFTWARE\Classes\CLSID\{070B64FF-795D-4DAA-88AD-6D3277C7E445}]
@=Fujitsu DeskUpdate
InfoTip=expand:@C:\\Program Files 
(x86)\\Fujitsu\\DeskUpdate\\DeskUpdate.exe,-132
System.ControlPanel.Category=dword:0005
System.Software.TasksFileUrl=C:\\Program Files 
(x86)\\Fujitsu\DeskUpdate\\duconfig.xml

[HKLM\SOFTWARE\Classes\CLSID\{070B64FF-795D-4DAA-88AD-6D3277C7E445}\DefaultIcon]
@=expand:C:\\Program Files (x86)\\Fujitsu\\DeskUpdate\\DeskUpdate.exe,-0

[HKLM\SOFTWARE\Classes\CLSID\{070B64FF-795D-4DAA-88AD-6D3277C7E445}\Shell\Open\Command]
@=C:\\Program Files (x86)\\Fujitsu\\DeskUpdate\\DeskUpdate.exe


The last entry is a pathname with unquoted spaces and allows the
execution of the rogue programs C:\Program.exe and/or
C:\Program Files.exe, as documented in
http://msdn.microsoft.com/library/ms682425.aspx


Stefan Kanthak

PS: long pathnames containing spaces exist for about 20 years
now in Windows, EVERY developer should know how to use them
properly, and EVERY QA should check their proper use!

Re: Vulnerabilities in Windows 8 Professional x64 factory preinstallation of Fujitsu Lifebook A512 [continued]

[Stefan Kanthak]

On Sunday, May 05, 2013 10:13 PM I wrote:

 Hi @ll,
 
 Fujitsus http://www.fsc-pc.de/ factory preinstallation (as
 found on a Fujitsu Lifebook A512 purchased a month ago) of
 Windows 8 Professional x64 (I'm VERY confident that other
 variants of Fujitsu's Windows 8 factory installation are just
 the like) has the following vulnerabilities which can lead to
 code execution in the context of the LocalSystem account.
 
 
 A. Command lines with unquoted paths containing spaces:

[...]

and missed some more REALLY nice vulnerabilities (just like the one
Microsoft fixed with https://support.microsoft.com/kb/2781197
alias http://technet.microsoft.com/security/bulletin/ms13-034,
which of course is present too).


A.6: TWO vulnerabilities in the preinstalled services from Fujitsu:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PFNService]
ImagePath=expand:C:\\Program Files\\Fujitsu\\Plugfree 
NETWORK\\PFNService.exe

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PowerSavingUtilityService]
ImagePath=expand:C:\\Program Files\\Fujitsu\\PSUtility\\PSUService.exe


A.7: SIX vulnerabilities in the preinstalled services from Intel:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AMPPALR3]
ImagePath=expand:C:\\Program 
Files\\Intel\\BluetoothHS\\BTHSAmpPalService.exe

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EvtEng]
ImagePath=expand:C:\\Program Files\\Intel\\WiFi\\bin\\EvtEng.exe

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\jhi_service]
ImagePath=expand:C:\\Program Files (x86)\\Intel\\Intel(R) Management Engine 
Components\\DAL\\jhi_service.exe

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LMS]
ImagePath=expand:C:\\Program Files (x86)\\Intel\\Intel(R) Management Engine 
Components\\LMS\\LMS.exe

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MyWiFiDHCPDNS]
ImagePath=expand:C:\\Program Files\\Intel\WiFi\\bin\\PanDhcpDns.exe

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RegSrvc]
ImagePath=expand:C:\\Program Files\\Common 
Files\\Intel\\WirelessCommon\RegSrvc.exe


JFTR: two other services of Intel don't show this vulnerability!

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHSSecurityMgr]
ImagePath=expand:C:\\Program 
Files\\Intel\\BluetoothHS\\BTHSSecurityMgr.exe

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\UNS]
ImagePath=expand:C:\\Program Files (x86)\\Intel\\Intel(R) Management 
Engine Components\\UNS\\UNS.exe


Stefan Kanthak

Vulnerability in Microsoft Security Essentials v4.2

[Stefan Kanthak]

Hi @ll,

versions of Microsoft Security Essentials before the current
v4.2 (see https://support.microsoft.com/kb/2805304) have a
vulnerability that could lead to execution of arbitrary code
in the security context of the LocalSystem account (almost like
https://support.microsoft.com/kb/2781197 alias
http://technet.microsoft.com/security/bulletin/ms13-034).

The UninstallString written to

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\Microsoft
 Security Client]
UninstallString=C:\\Program Files\\Microsoft Security Client\\Setup.exe /X

contains unquoted spaces.
This command may be called by Windows Update Agent or deployment
agents running under the LocalSystem account.


Timeline:
~

2012-12-05vendor informed

2013-12-06vendor acknowledged report

2013-02-13vendor released fixed version


Stefan Kanthak

VULNERABLE and COMPLETELY outdated 3rd-party libraries/components used in 3CX Phone 6

[Stefan Kanthak]

Hi @ll,

the current 3CXPhone6.msi (for Windows), available from
http://www.3cx.com/VOIP/sip-phone/, digitally signed on 2012-07-30,
installs the following outdated and vulnerable 3rd-party libraries:

* libeay32.dll and ssleay32.dll version 0.9.8h (from 2008-05-28)
  of OpenSSL.

  The current version of OpenSSL is 0.9.8y, see
  http://www.openssl.org/, it fixes about 20 CVEs found in earlier
  versions downto 0.9.8h.


* FFmpeg/FFdshow version 1.1.0

  The current version of FFmpeg/FFdshow is 1.2, see
  http://www.ffmpeg.org/security.html for the 24 fixed CVEs since
  1.1.0.


Timeline:
~

2013-05-03vendor informed

2013-05-05vendor replied:
  3CX Phone is freeware, use another software

I second that: don't use software from 3CX!

2013-05-06report published


Stefan Kanthak

Mozilla Firefox and Microsoft Internet Explorer stall when using workaround from MS06-020 or MS06-069

[Stefan Kanthak]

Hi @ll,

the Microsoft security bulletins
http://technet.microsoft.com/en-us/security/bulletin/ms06-020
http://technet.microsoft.com/en-us/security/bulletin/ms06-069
show the following workaround to disable Macromedia Flash Player
with software restriction policies a.k.a. SAFER:

--- MS06-069.REG ---
REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
TransparentEnabled=dword:0002

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0\Paths\{2742f840-c2d8-4eb3-a486-0a9d0879f29f}]
LastModified=hex(b):10,c3,8a,19,c6,e3,c5,01
Description=Block Macromedia Flash
SaferFlags=dword:
ItemData=hex(2):25,77,69,6e,64,69,72,25,2f,73,79,73,74,65,6d,33,32,2f,6d,61,63,72,6f,6d,65,64,2f,66,6c,61,73,68,2f,2a,00

--- EOF ---

When this (or an equivalent) SAFER rule to block flash player
is set AND the flash player plugin/activex control is installed
and enabled in Mozilla Firefox or Microsoft Internet Explorer,
then both browsers stall or slow to a crawl as soon as a web page
which uses the flash player plugin/activex control is loaded.

Apparently both web browsers handle the return code(s) from the
denied loading of the flash player plugin/activex control wrong!

Tested with MSIE6 to MSIE9 on Windows XP to Windows 7,
and Mozilla Firefox 1x.x on Windows XP and Windows 7.

Stefan Kanthak

PS: Opera doesn't show this error!

Vulnerable, superfluous/outdated/deprecated/superseded 3rd party OCXs and DLLs distributed by and installed with Dataram RamDisk 4.0.0

[Stefan Kanthak]

Hi @ll,

the recently released RamDisk 4.0.0 from Dataram Inc.,
http://memory.dataram.com/products-and-services/software/ramdisk
(formerly known as Cenatek RamDisk) comes with several vulnerable and
some superfluous as well as outdated/deprecated/superseded 3rd party
OCXs and DLLs from Microsoft.

1. TABCTL32.OCX   version 6.1.97.82 from 2004-03-09
   COMDLG32.OCX   version 6.1.97.82 from 2004-07-14
   MSCOMCT2.OCX   version 6.1.97.82 from 2004-03-08
   MSCOMCTL.OCX   version 6.1.98.18 from 2009-12-19

   are all vulnerable, deprecated and have been superseded several
   times since their release.
   Cf. http://support.microsoft.com/kb/957924,
   http://support.microsoft.com/kb/926857 and
   http://technet.microsoft.com/security/bulletin/MS08-070,
   http://support.microsoft.com/kb/2641426,
   http://support.microsoft.com/kb/2664258 and
   http://technet.microsoft.com/security/bulletin/MS12-027,
   http://support.microsoft.com/kb/2708437 and
   http://technet.microsoft.com/security/bulletin/MS12-060


   Additionally these files are installed in the applications directory,
   not the Windows System directory.

   This prevents Windows Update from detecting and updating vulnerable
   and deprecated/superseded libraries (and fixing YOUR errors) now, and
   in the future too.
   Cf. http://support.microsoft.com/kb/835322


   To make things even worse, these application-local installed OCX are
   registered system-global, overwriting the existing registration of
   the current versions of these OCX installed elsewhere, and thus
   propagate their vulnerabilities and errors to any other application
   using these OCX.


2. COMCAT.DLL version 4.71.1460.1 from 1999-06-01
   OLEAUT32.DLL   version 2.40.4275.1 from 1999-03-08
   OLEAUT32.DLL   version 2.40.4275.1 from 2000-04-12
   OLEPRO32.DLL   version 5.0.4275.1  from 1999-03-08
   STDOLE2.TLBversion 2.40.4275.1 from 1999-06-03

   are all superfluous, outdated/deprecated/superseded and vulnerable too.

   Cf. http://support.microsoft.com/kb/2476490 and
   http://technet.microsoft.com/security/bulletin/MS11-038


   Additionally these files are part of ALL supported Windows versions
   and MUST NOT be redistributed since Windows 2000!

   Cf. http://msdn.microsoft.com/en-us/library/4kbye0ax.aspx

   | If these DLLs are not available in the target system, you need to
   | get them updated through the PRESCRIBED mechanism for updating the
  ~~
   | corresponding operating system. 

   or cf. http://support.microsoft.com/kb/831491

   | Remove the commonly redistributed system files from the setup
   | package


3. MSVBVM60.DLL   version 6.0.97.82 from 2004-02-23

   is superfluous and outdated/deprecated/superseded.

   A newer version of this file is part of ALL supported Windows
   versions!
   Cf. http://support.microsoft.com/kb/314720




Timeline:
~


2010-06-28vendor informed (for v3.5.20 of their product)

  no reaction from vendor

2012-10-06vendor informed (for v4.0.0 of their product)

  no reaction from vendor

2012-11-06report published


Recommendation:
~~~

Stay away from products of vendors/companies who dont follow even the
most basic principles of software engineering!


Stefan Kanthak

Vulnerable MSVC++ 2008 runtime libraries distributed with and installed by eM client

[Stefan Kanthak]

Hi @ll,

http://www.emclient.com/dist/latest/setup.msi, an e-mail client
for Windows, distributed with SoftMaker Office 2010 Professional
for example, contains and installs the following deprecated and
VULNERABLE Microsoft Visual C++ 2008 Runtime DLLs:

- msvcm9032File  -  MSVCM90.DLL version 9.0.21022.8 from 2007-11-07
- msvcm9064File  -  MSVCM90.DLL version 9.0.21022.8 from 2007-11-07
- msvcr9032File  -  MSVCR90.DLL version 9.0.21022.8 from 2007-11-07
- msvcr9064File  -  MSVCR90.DLL version 9.0.21022.8 from 2007-11-07

These DLLs have been updated several times since 2007-11-07, for their
current version cf. http://support.microsoft.com/kb/2467174,
http://support.microsoft.com/kb/2538243 and
http://technet.microsoft.com/security/bulletin/MS11-025


To make things worse: instead of using the redistributable MSVC++ 2008
runtime eM Client makes another mistake and installs these libraries
below the applications directory, where they are NOT detected by Windows
Update Agent and thus never get updated to their current or any future
fixed versions.
Cf. http://support.microsoft.com/kb/835322


Timeline:
~

2012-10-02vendor informed

  no reaction from vendor

2012-11-02report published


Stefan Kanthak

Vulnerable MSVC++ 2008 runtime libraries distributed with and installed by Ogg DirectShow filters

[Stefan Kanthak]

Hi @ll,

the Ogg DirectShow filters available from http://www.xiph.org/dshow/
are distributed with and install vulnerable MSVC++ 2008 runtime libraries
MSVC?90.DLL.

See http://support.microsoft.com/kb/2467174
and http://support.microsoft.com/kb/2538243
resp. http://www.microsoft.com/technet/security/bulletin/MS11-025.mspx


To make things worse, the vulnerable libraries are NOT installed as
side-by-side components below %SystemRoot%\WinSxS\, but as private
components in the applications directory, where they are not detected
and not updated by tools like Windows Update Agent or Secunia PSI.

Cf. http://support.microsoft.com/kb/835322


Additionally, the installer places the 64-bit components into the
wrong path %ProgramFiles(x86)%\Xiph.org\OpenCodecs\x64\.


Workaround:
~~~

Delete all MSVC?.DLL installed with the Ogg DirectShow filters
in %ProgramFiles(x86)%\Xiph.org\OpenCodecs\ and
%ProgramFiles(x86)%\Xiph.org\OpenCodecs\x64\.


Timeline:
~

2010-05-23informed maintainer about errors and problems in
  version 0.82.16930

2010-05-25maintainer replied will have a look

2010-07-21maintainer released version 0.84.17338

2010-07-21informed maintainer about problems still not fixed

2011-01-12maintainer released current version 0.85.1 

2012-03-08asked maintainer for a fix for the vulnerable MSVCRT

2012-03-09maintainer replied planning update before easter

2012-10-03report published


Stefan Kanthak

[Full-disclosure] Dell Data Protection | Access for Windows contains and installs outdated, superfluous and vulnerable system components and 3rd party components/drivers

[Stefan Kanthak]

Hi @ll

the current version of Dell's Data Protection | Access (DDPA) software for
Windows (Build 2.2.3.008 from 2012-06-14, released August 2012) contains
and installs several outdated, superfluous and vulnerable Windows system
components as well as outdated and vulnerable 3rd party components and drivers.

http://www.dell.com/support/drivers/uk/en/ukdhs1/DriverDetails?driverId=KPCWG

From the readme.txt:

| Dell Data Protection | Access (DDP|A) is an integrated end point security
| management suite, providing for seamless data security and authentication.
| It allows you to authenticate using a fingerprint, smartcard, contactless
| smartcard or password. Pre-Windows can be configured to unlock self-encrypting
| drives upon authentication.


The outdated, superfluous and vulnerable components (incomplete):

#1. Microsoft MSXML Parser.msiversion 6.0 from 2005-09-09

 All versions of Windows supported by DDP|A include a newer version
 of MSXML 6.0, the latest update/security fix cf.
 http://technet.microsoft.com/en-us/security/bulletin/ms12-043


#2. Microsoft Root Certificate Update October 2010\rootsupd.exe

The current Microsoft root certificate update is from April 2012,
cf. http://support.microsoft.com/kb/931125


#3. Microsoft Visual Studio Runtimes\vcredist_x86.exe
 version 9.0.30729.17 from 2008-08-08

For the current Microsoft Visual C++ 2008 Redistributable Package
cf. http://technet.microsoft.com/en-us/security/bulletin/ms11-025


#4. Microsoft CCID Smartcard Reader for XP\usbccid.sys
 version 5.2.3790.2444 from 2005-05-17

The installer package for DDP|A but includes the hotfix
WindowsXP-KB967048-v2-x86-ENU.exe with the current version of
this driver: 5.2.3790.4476, 2009-03-17


#5. AuthenTec AES2810 Fingerprint Reader\AT8MinFoose.msi
 version 8.4.4.39 from 2012-02-02

Cf. 
http://blog.crackpassword.com/2012/08/upek-fingerprint-readers-a-huge-security-hole/


#6. UPEK TouchChip Fingerprint Reader\UPEK_Touchchip.msi
 version 5.9.4.6685 from 2010-09-15

Cf. 
http://blog.crackpassword.com/2012/08/upek-fingerprint-readers-a-huge-security-hole/

This driver package contains parts of OpenSSL (no version specified),
it installs a textfile OpenSSL license from 2006-06-14!
So: add OpenSSL to the list of vulnerable components too.


#7. UPEK TouchChip Fingerprint Reader PBA Support\spba.msi
  version 5.9.4.6901 from 2010-??-??

This package contains a vulnerable MSVCRT+ 2005 runtime (version
8.0.50727.762)

Cf. http://technet.microsoft.com/en-us/security/bulletin/ms11-025

This driver package contains parts of OpenSSL (no version specified),
it installs a textfile OpenSSL license from 2006-06-14!
So: add OpenSSL to the list of vulnerable components too.


#8. Preboot Manager.msi version 03.02.00.119 from 2011-12-06
  by Wave Systems Corp.

This package contains a vulnerable MSXML 4.0 SP2 (version 4.20.9818.0
from 2003-04-18).
Cf. http://technet.microsoft.com/en-us/security/bulletin/ms12-043

This package contains a VTAPI.DLL (version 5.6.0.3239 from 2006-11-13)
from UPEK Inc. (see #6 and #7 above) which contains parts of OpenSSL.
So: yet another component with vulnerable OpenSSL code.

JFTR: no textfile with the OpenSSL license included here.


#9. NTRU CryptoSystems TCG Software Stack\NTRU-CTSS-v1.2.1.37-eu.msi
  version 1.2.1.37 from 2011-10-08
  by NTRU CryptoSystems Inc.

This package contains a vulnerable MSVCRT++ 2010 (version 10.0.30319.1
from 2010-03-18), cf.
http://technet.microsoft.com/en-us/security/bulletin/ms11-025


... and more (I stopped counting)!


Dell Inc.: Don't you have any QA? Can't afford one?
UPEK Inc.: Don't you have any QA? Can't afford one?
Wave Corp.: Don't you have any QA? Can't afford one?
NTRU Inc.: Don't you have any QA? Can't afford one?

What about just a little bit of serious software engineering and due
diligence in your development, build and production processes?

It's a stupid idea to build security software from vulnerable components!


Stefan Kanthak


Timeline


2012-08-24informed vendor support

2012-09-24no reaction/reply from vendor support, 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/

The information transmitted in this message and its attachments (if any) is 
intended only for the person or entity to which it is addressed.

The message may contain confidential and/or privileged material. Any review, 
retransmission, dissemination or other use

How well does Microsoft support (and follow) their mantra keep your PC updated?

[Stefan Kanthak]

 update KB2691894
   http://support.microsoft.com/kb/2691894/en-us
   (cf. http://support.microsoft.com/kb/2267621/en-us).

Step 2:

   Find the directory
   
C:\WINDOWS\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd\
   with vulnerable DLLs MSVC?80.DLL v8.0.50727.42 (this version is
   MSVC++ 2005 RTM, ie. end-of-life/out-of-service) on your system.

Step 3:

   Open control panel, start the software applet and try to find
   the just installed component Microsoft Application Error Reporting
   and (parts of) the component Microsoft Visual C++ Runtime.

   They are missing!

   How should a user follow Microsoft's recommendation if s/he doesnt
   even know that there are (parts of) vulnerable components installed?

Step 4:

   Start Windows Update or Microsoft Update and perform a custom
   search for updates.

   Result: no update(s) for Microsoft Visual C++ 2005 runtime libraries
   or error reporting tool.

   Again: a complete waste of time, WU/MU doesnt offer the necessary
   update MS11-025, since Windows Update Agent doesnt detect the
   improperly installed MSVCRT!


Stefan Kanthak


[1] Application Error Reporting alias Windows Error Reporting
SQL Server 2005 and several subcomponents
SQL Server 2008 and several subcomponents
SQL Server 2012 and several subcomponents
...

[2] Windows Defender
Security Essentials
Forefront Security ...
{Exchange Office Outlook OneNote Word Excel PowerPoint Publisher Project 
Access Visio ...} 2003
{Exchange Office Outlook OneNote Word Excel PowerPoint Publisher Project 
Access Visio ...} 2007
Office Communicator 2005
Office Groove 2007
Groove Server 2010
Sharepoint Services 2.0
Sharepoint Services 3.0
SharePoint Designer 2007
SharePoint Foundation 2010
SharePoint Server 2010
.NET Framework 2.0
.NET Framework 3.0
.NET Framework 3.5
...

Vulnerable Microsoft VC++ 2005 runtime libraries in Microsoft Live Meeting 2007 Client installed in private location

[Stefan Kanthak]

 12.0.6421.1000 756,032 12-May-11 17:54

  MSPTLS.DLL 12.0 is part of various other Office 2007 components,
  its current version is but 12.0.6654.5000

| C:\filever /S msptls.dll
|
| c:\program files (x86)\common files\microsoft shared\office12\msptls.dll
| --a-- W32i   DLL   -  12.0.6654.5000 shp756,048 10-05-2011 msptls.dll
|
| c:\program files (x86)\microsoft office\live meeting 8\console\msptls.dll
| --a-- W32i   DLL   -  12.0.6421.1000 shp756,032 05-12-2011 msptls.dll


* Intldate.dll   12.0.6413.1000  79,224 12-May-11 17:54

  MSPTLS.DLL 12.0 is part of various other Office 2007 components,
  its current version is but 12.0.6500.5000

| C:\filever /S intldate.dll
|
| c:\program files (x86)\microsoft office\live meeting 8\console\intldate.dll
| --a-- W32i   DLL   -  12.0.6413.1000 shp 79,224 05-12-2011 intldate.dll
|
| c:\program files (x86)\microsoft office\office12\intldate.dll
| --a-- W32i   DLL   -  12.0.6500.5000 shp 78,208 02-25-2009 intldate.dll


* Rtyuv.dll   1.0.3656.0 30,976 12-May-11 18:18

  RTYUV.DLL 1.0 is part of Microsoft Roundtable.


Again the developers dont follow their employers own guidelines
(see http://msdn.microsoft.com/en-us/ms997548.aspx for example):

| If a file is shared, but only among your applications, create a
| subfolder in the following location and store the file there:
|
| C:\Program Files\Common Files\Company Name
|
| Alternatively, for application suite installations where multiple
| applications are bundled together, you can create suite subfolders as
| follows:
|
| For your executable files:
|
| C:\Program Files\Suite Name
|
| For your support files shared only within the suite:
|
| C:\Program Files\Suite Name\System

but create a mess instead and place numerous copies of these (and some more)
libraries in various different locations!


Stefan Kanthak


Timeline:

2012-03-16problem reported

2012-03-17vendor acknowledges the report, opens MSRC case and asks for
  responsible disclosure

2012-03-23vendor sends update case manager assigned

2012-04-09vendor sends update still under investigation

2012-07-03vendor answers investigation complete and acknowledges the
  facts, but will not issue an MSRC bulletin since they were
  unable to find any attack vectors

OpenLimit Reader for Windows contains completely outdated, superfluous and VULNERABLE system components

[Stefan Kanthak]

 will fail!


To complete the sad story: before the installation ALL system DLLs were
registered with their fully qualified pathnames and were not vulnerable
to binary planting attacks (http://support.microsoft.com/kb/2269637
and http://support.microsoft.com/kb/2264107).


After the installation, the Windows installation was vulnerable again
(modulo the Known DLLs):

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{002F---C000-0046}\InProcServer32]
@=oleaut32.dll

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00020420---C000-0046}\InProcServer]
@=ole2disp.dll

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00020420---C000-0046}\InProcServer32]
@=oleaut32.dll

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00020421---C000-0046}\InProcServer]
@=ole2disp.dll

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00020421---C000-0046}\InProcServer32]
@=oleaut32.dll

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00020422---C000-0046}\InProcServer]
@=ole2disp.dll

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00020422---C000-0046}\InProcServer32]
@=oleaut32.dll

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00020423---C000-0046}\InProcServer]
@=ole2disp.dll

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00020423---C000-0046}\InProcServer32]
@=oleaut32.dll

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00020424---C000-0046}\InProcServer]
@=ole2disp.dll

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00020424---C000-0046}\InProcServer32]
@=oleaut32.dll

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00020425---C000-0046}\InProcServer]
@=ole2disp.dll

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00020425---C000-0046}\InProcServer32]
@=oleaut32.dll

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0BE35203-8F91-11CE-9DE3-00AA004BB851}\InProcServer32]
@=oleaut32.dll

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0BE35204-8F91-11CE-9DE3-00AA004BB851}\InProcServer32]
@=oleaut32.dll

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{46763EE0-CAB2-11CE-8C20-00AA0051E5D4}\InProcServer32]
@=oleaut32.dll

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{B196B286-BAB4-101A-B69C-00AA00341D07}\InProcServer32]
@=oleaut32.dll


Stefan Kanthak


Timeline:

2012-05-19vendor informed

   ... no reaction until

2012-06-25report published

[Win32-API] SetNamedSecurityInfo() IGNORES and DESTROYS protected DACLs/SACLs

[Stefan Kanthak]

Hi @ll,

(this is the prequel to http://seclists.org/bugtraq/2012/May/75
alias http://seclists.org/fulldisclosure/2012/May/109)

With Windows 2000 Microsoft introduced the inheritance of access
rights and new Win32-API functions like SetNamedSecurityInfo()
which handle the inheritance.

SetNamedSecurityInfo() but has a serious bug: it applies inheritable
ACEs from a PARENT object to a target object even if it must not do so,
indicated by the flags SE_DACL_PROTECTED and/or SE_SACL_PROTECTED in
the security descriptor of the target object.

This erroneous behaviour can result in lesser protection of any target
object whose security descriptor is changed with SetNamedSecurityInfo().


From the official documentation:

http://msdn.microsoft.com/en-us/library/aa376326.aspx

| When you call the SetNamedSecurityInfo and SetSecurityInfo functions 
| to set the security information of an object, the system imposes the 
| current inheritance model on the ACLs of all objects in the hierarchy 
| below the target object.
  ~~~


http://msdn.microsoft.com/en-us/library/aa379579.aspx

| Remarks
|
| If you are setting the discretionary access control list (DACL) or 
| system access control list (SACL) of an object, the system 
| automatically propagates any inheritable access control entries (ACEs) 
| to existing child objects, according to the rules of inheritance.
  ~


http://msdn.microsoft.com/en-us/library/aa374920.aspx

| These rules have been enhanced with the following features:
...
| The ability to prevent a DACL or SACL from inheriting ACEs by setting 
| the SE_DACL_PROTECTED or SE_SACL_PROTECTED bits in the security 
| descriptor's control bits.


http://technet.microsoft.com/en-us/library/cc781716.aspx

| SE_DACL_PROTECTED Windows 2000 and later: The security descriptor's
|   DACL cannot be modified by inheritable ACEs.
|
|   If this flag is not set, the security descriptor
|   inherits information from the security descriptor
|   of the parent object.
...
| SE_SACL_PROTECTED Windows 2000 and later: The security descriptor's
|   SACL cannot be modified by inheritable ACEs.
...
| ... sets the security descriptor control flag SE_DACL_PROTECTED, which 
| protects a child object's DACL by blocking inheritance from the parent 
| object's DACL.


http://msdn.microsoft.com/en-us/library/aa379566.aspx

| SE_DACL_PROTECTED
| 0x1000Prevents the DACL of the security descriptor from
|   being modified by inheritable ACEs.  To set this
|   flag, use the SetSecurityDescriptorControl function.
...
| SE_SACL_PROTECTED
| 0x2000Prevents the SACL of the security descriptor from
|   being modified by inheritable ACEs.  To set this
|   flag, use the SetSecurityDescriptorControl function.


To demonstrate the error call the example code from 
http://msdn.microsoft.com/en-us/library/aa379283.aspx
as follows:

#include windows.h
#include tchar.h
#include aclapi.h

int _tmain()
{
return AddAceToObjectsSecurityDescriptor (
TEXT(%ALLUSERSPROFIL%), // specify your path here!
SE_FILE_OBJECT,
TEXT(S-1-1-0),
TRUSTEE_IS_NAME,
FILE_EXECUTE,
DENY_ACCESS,
OBJECT_INHERIT_ACE | INHERIT_ONLY_ACE); }


In all current versions of Windows the directory %ALLUSERSPROFILE%
has SE_DACL_PROTECTED flag set in its security descriptor... before
the call. Afterwards, SE_DACL-PROTECTED is gone, and %ALLUSERSPROFILE%
got additional inherited access rights.


regards
Stefan Kanthak

ICACLS.EXE ignores and destroys SE_DACL_PROTECTED/SE_SACL_PROTECTED

[Stefan Kanthak]

Hi @ll,

since Windows Vista resp. Windows Server 2003 Service Pack 2, the
command line tool to modify/set file/directory permissions is
ICACLS.EXE [0][1][2][3][4].

Main advantage over the previous command line tools CACLS.EXE [5],
XCACLS.EXE [6] and XCACLS.VBS [7] is the ability to specify
inheritance and to process/propagate inheritable permissions.

But exactly the handling of inheritance is severely broken: in an
objects security descriptor both DACLs and SACLs can be marked as
PROTECTED, meaning that inheritable ACEs from the parent object
are NOT to be applied to an object and its children [8][9].

ICACLS.EXE, when operating on an object with protected ACLs, but
1. ignores this protection,
2. resets/destroys the protection
   and
3. applies/propagates the inheritable permissions from the parent
   to the object and its children.

This (typically) results in lesser protection of the modified object
and its children, since ACLs that were neither present on the object
before nor specified as arguments to ICACLS.EXE are added to the
object and (propagated to) its children.

The following batch demonstrates the bug (the D:P in the SDDL [10]
representation of the security descriptors gets changed to D:) and
reverts the changes^Wdamage done:

--- *.CMD ---
For %%X In (%USERPROFILE%
%ALLUSERSPROFILE%
%SystemRoot%\Connection Wizard
%SystemRoot%\Debug\UserMode
%SystemRoot%\System32\Config\SystemProfile
%SystemRoot%\System32\SPOOL\Printers) Do Call :ICACLS %%~fX\.
Rem \. is necessary due to another bug in ICACLS.EXE:
Rem  /Restore interprets pathnames different from /Save when the pathname
Rem   is a directory!
Exit /B

:ICACLS
%SystemRoot%\System32\ICACLS.EXE %~1 /Save %TEMP%\BEFORE.ACL /C /T
%SystemRoot%\System32\ICACLS.EXE %~1 /Deny *S-1-1-0:(OI)(IO)(X)
%SystemRoot%\System32\ICACLS.EXE %~1 /Save %TEMP%\AFTER.ACL /C /T
%SystemRoot%\System32\ICACLS.EXE %~1 /Restore %TEMP%\BEFORE.ACL /C
%SystemRoot%\System32\FC.EXE /U %TEMP%\BEFORE.ACL %TEMP%\AFTER.ACL
Del %TEMP%\BEFORE.ACL %TEMP%\AFTER.ACL
--- EOF ---

Vendor was informed and has acknowledged the bug, but won't neither
issue an immediate fix nor even a warning note stating the bug.


regards
Stefan Kanthak


[0] http://support.microsoft.com/kb/919240
[1] http://support.microsoft.com/kb/943043
[2] http://support.microsoft.com/kb/944820
[3] http://support.microsoft.com/kb/947870
[4] http://support.microsoft.com/kb/2028627
[5] http://support.microsoft.com/kb/135268
[6] http://support.microsoft.com/kb/318754
[7] http://support.microsoft.com/kb/825751
[8] http://msdn.microsoft.com/library/aa374920.aspx
[9] http://msdn.microsoft.com/library/aa379566.aspx
[10] http://msdn.microsoft.com/library/aa379570.aspx

%windir%\temp\sso\ssoexec.dll (or: how trustworthy is Microsoft's build process)

[Stefan Kanthak]

Hi @ll,

the system image \Setup\WIM\setup.wim on the POSReady 2009 eval CD,
available from the Microsoft Download Center under
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=1e077ece-3f19-4c41-b219-6fcc821fb5fc,
contains the following registry entries:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows 
NT\CurrentVersion\Winlogon\Notify\SSOExec]
Asynchronous=dword:0001
Impersonate=dword:0001
Logoff=SSOReset
Unlock=SSOExec
Lock=SSOReset
DLLName=%windir%\\temp\\sso\\ssoexec.dll


The directory %windir%\temp in the system image is but empty.


The presence of these registry entries is evidence that (one of) the
system(s) used to build and capture the POSReady 2009 evaluation system
image were infested with malware, and that either the infestation was not
detected at all (bad) or the infestation was detected, but incompletely
(or accidentially, when %windir%\temp was cleared) removed and a
compromised system used to build the system image (worse).

JFTR: MSFT initiated their trustworthy computing about 10 years ago!


To complete the picture: the ACLs on the directory %windir%\temp in
systems installed from this image/CD allow unprivileged users to create
a subdirectory sso in %windir%\temp and then the ssoexec.dll,
allowing them to have their code run under every (other) user account
used to log on afterwards, resulting in a privilege escalation.


Timeline


2012-02-03informed vendor

2012-02-03vendor replies:
  The registry key and DLL are part of the Windows embedded
   software package and their existence is expected.

.oO(OUCH! they must be joking...)

2012-02-04informed vendor that SSOEXEC.DLL is NOT part of any Windows
  software package

2012-02-06vendor replies:
  we are still looking and hope to provide clarification soon.

2012-02-06vendor replies:
  this reference in no way indicates there is or ever was a
   virus on our build systems.

2012-02-08asked vendor to consider that both
  http://www.bing.com/search?q=ssoexec and
  
https://encrypted.google.com/search?num=100safe=offq=%22ssoexec%22+OR+%22ssoreset%22
  only find hits that show problems with malware

2012-03-04no more answer from vendor, report published


Stefan Kanthak

Re: Perfect PDF products distributed with vulnerable MSVC++ libraries

[Stefan Kanthak]

Brad Hards br...@frogmouth.net wrote:

 On Sunday 19 June 2011 11:37:33 Stefan Kanthak wrote:
 soft Xpansion www.soft-xpansion.com distributes their (freeware)
 products Perfect PDF 7 Master and Perfect PDF 7 Reader (the
 current files are dated 2011-05-10) with OUTDATED and VULNERABLE
 Visual C++ 2008 runtime libraries VCRedist_x86.exe/VCRedist_x64.exe
 version 9.0.30729.17 of 2008-08-08.
 
 These libraries have been updated since then at least twice due to
 vulnerabilities, see
 http://www.microsoft.com/technet/security/bulletin/MS09-035.mspx
 and
 http://www.microsoft.com/technet/security/bulletin/MS11-025.mspx
 Did you check if these vulnerabilities be exploited via this product?

No. I would have mentioned them explicitly then.

 I'm not suggesting that its OK to distribute outdated libs, just to
 understand the risk a little more.

1. Software that is distributed with such outdated libraries is VERY
   likely compiled/produced in an outdated development environment
   TOO, so there may be more errors/vulnerabilities lurking.


2. http://www.microsoft.com/technet/security/bulletin/MS11-025.mspx

| In the case where a system has no MFC applications currently installed
| but does have the vulnerable Visual Studio or Visual C++ runtimes
| installed, Microsoft recommends that users install this update as a
| defense-in-depth measure, in case of an attack vector being introduced
| or becoming known at a later time.

   For the above products Microsofts advice is like a self-fullfilling
   prophecy:-(


3. Even if the current MSVC++ runtime is installed later (via Windows
   Update, for example), the vulnerable MSVC++ runtime(s) remain
   installed (side-by-side).
   You have to (and should!) remove them manually to get rid of them
   completely!


Stefan

Perfect PDF products distributed with vulnerable MSVC++ libraries

[Stefan Kanthak]

Hi @ll, 

soft Xpansion www.soft-xpansion.com distributes their (freeware)
products Perfect PDF 7 Master and Perfect PDF 7 Reader (the
current files are dated 2011-05-10) with OUTDATED and VULNERABLE
Visual C++ 2008 runtime libraries VCRedist_x86.exe/VCRedist_x64.exe
version 9.0.30729.17 of 2008-08-08.

These libraries have been updated since then at least twice due to
vulnerabilities, see
http://www.microsoft.com/technet/security/bulletin/MS09-035.mspx
and
http://www.microsoft.com/technet/security/bulletin/MS11-025.mspx


Timeline:

2011-05-13vendor informed via mail

  (no reply)

2011-06-19vulnerability report published


Stefan Kanthak

Essential PIM 4.22: MANY vulnerabilities in 3rd party libraries

[Stefan Kanthak]

Hi @ll,

the current version of Essential PIM 4.22, available at
http://www.astonsoft.com/epim_download/EssentialPIMPort4.zip
with HTTP timestamp Wed, 15 Jun 2011 13:20:12 GMT, comes with
VULNERABLE and COMPLETELY outdated 3rd party runtime libraries!


1. libeay32.dll and ssleay32.dll of OpenSSL 0.9.8i, from 2008-09-15

   updated 8 times due to fixed vulnerabilities, current release is
   0.9.8r; see http://openssl.org/news/ and
   http://openssl.org/news/vulnerabilities.html


2. msvcrt80.dll version 8.0.50727.42, from 2005-09-23

   updated at least twice due to fixed vulnerabilities; see
   http://support.microsoft.com/kb/973544,
   http://support.microsoft.com/kb/969706 and
   http://www.microsoft.com/technet/security/bulletin/MS09-035.mspx
   plus
   http://support.microsoft.com/kb/2467175,
   http://support.microsoft.com/kb/2500212 and
   http://www.microsoft.com/technet/security/bulletin/MS11-025.mspx.

   For general guidelines see http://support.microsoft.com/kb/326922


3. gds32.dll of FirebirdSQL 2.1.2.18118, from 2009-02-28

   updated at least once due to fixed vulnerabilities, current
   release is 2.1.4; see http://firebirdsql.org/


4. icudt30.dll and icuuc30.dll 3.0.0.0, from 2009-02-27

   updated quite some times and superseded with version 4 due to
   fixed vulnerabilities:
   CVE-2007-4770CVE-2007-4771CVE-2008-1036CVE-2009-0153 

   current release is 4.8; see http://site.icu-project.org/


5. hunspelldll.dll unknown version, from 2009-06-26

   current release is 1.3.1; see http://hunspell.sourceforge.net/


It needs REAL chuzpe to build and distribute software with those
vulnerable and outdated libraries (and most probably a vulnerable
and outdated development environment too).


Timeline:

2011-05-28  vulnerability report sent to vendor after release of v4.21

2011-05-30  vendor reply:
We'll update them in the next version. Thanks for notice.

2011-06-15  vendor releases v4.22 with EXACT the same vulnerable libraries
already included in v4.21
vendor obviously doesn't care about security at all!

2011-06-17  vulnerability report published


Stefan Kanthak

Vulnerable and completely outdated 3rd party ZIP code in FastStone image viewer

[Stefan Kanthak]

The FastStone image viewer http://www.faststone.org/ (and most
probably other FastStone products too) contains a 3rd party
ZipDll.dll 1.6.0.0 dated 2001-10-28.

This DLL was originally written by Chris Vleghert and Eric W. Engler,
based on InfoZIPs http://infozip.org code from 2000.

It is but vulnerable and completely outdated:  the current version of
the successor http://dll.delphizip.org/ is 1.90, the oldest version
(1.78.7.3) listed there is from July 2005, almost 4 years newer than
the DLL distributed with the Faststone image viewer.

According to http://infozip.org/FAQ.html#corruption all versions of
ZIP prior to 2.31 (November 2004) and UnZIP prior to 5.52
(February/March 2005) are vulnerable.


Vendor was informed via http://www.faststone.org/contactUs.htm,
but did not respond at all!


Stefan Kanthak


PS: Tools like Secunia's PSI don't detect such outdated and
vulnerable DLLs/components, so: user beware!

Re: Flaw in Microsoft Domain AccountCachingAllows Local Workstation Admins to TemporarilyEscalatePrivileges and Login as Cached Domain Admin Accounts(2010-M$-002)

[Stefan Kanthak]

StenoPlasma @ ExploitDevelopment stenopla...@exploitdevelopment.com wrote:

Your MUA is defective, it strips the References: header! 

 Stefan,
 
 For you information:
 
 Cached domain accounts on a local system are not stored in the SAM.  They 
 are stored in the SECURITY registry hive.  When a cached domain user logs 
 in to the system, they do not authenticate against the SAM (As you can see 
 in my article, I am not editing the SAM).  

OUCH!
Obviously you have NOT understand a single word!

It is COMPLETELY irrelevant where cached credentials are stored on the
local computer, and I haven't written anything about that.

Logins with local user accounts are authenticated against the resp. SAM,
whereas logins with domain user accounts are authenticated against the
resp. AD. Only if the latter is not available cached credentials are used.

Stefan

[ another braindead fullquote removed]

Re: [Full-disclosure] Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts (2010-M$-002)

[Stefan Kanthak]

Andrea Lee and...@kattrap.net wrote:

 I hope I'm not just feeding the troll...

No. You just made a complete fool of yourself.-P
Read the initial post again.
CAREFULLY.
Especially that part about unplugging from the network.

 A local admin is an admin on one system. The domain admin is an admin
 on all systems in the domain, including mission critical Windows
 servers.

Correct so far.

 With temporary domain admin privs,

What are temporary domain admin privs?
If you meant to say cached credentials, just use cached credentials.

 the local admin could log into the AD

A local admin (or better: a local user account) CAN'T log into the AD.
Only domain user accounts can.

Cached credentials are stored for domain accounts only, and are only
used when the AD is NOT available during login. They are NEVER used to
login to another computer!

 and change permissions / passwords for another user or
 another user, thus getting full admin rights on all systems for a long
 period of time. Plus whatever havoc might be caused by having the
 ability to change rights on fileshares to allow the new domain admin
 to see confidential files..

 I would expect that the intent is to use another flaw for a normal
 user to become a local admin, and then jump to domain admin via this.

You got wrong expectations. And: there is no jump!

 So yes. In an enterprise environment, the domain administrator is bigger.

GIGO!

Stefan

[ braindead fullquote removed ]

Re: Flaw in Microsoft Domain Account CachingAllows Local Workstation Admins to Temporarily EscalatePrivileges and Login as Cached Domain Admin Accounts (2010-M$-002)

[Stefan Kanthak]

George Carlson gcarl...@vccs.edu wrote:

 Your objections are mostly true in a normal sense.

And in abnormal sense?

 However, it is not true when Group Policy is taken into account.

Group Policies need an AD. Cached credentials are only used locally,
for domain accounts, when the computer can't connect to the AD.

 Group Policies differentiate between local and Domain administrators

Local administrators don't authenticate against an AD, they authenticate
against the local SAM. No GPOs there!
And: a local administrator can override ANY policy, even exempt the
computer completely from processing Group Policies.

 and so this
 vulnerability is problematic for shops that differentiate between
 desktop support and AD support.

Again: this is NO VULNERABILITY.
An administrator is an administrator is an administrator.

[braindead fullquote removed ]

Stefan

Re: Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts (2010-M$-002)

[Stefan Kanthak]

StenoPlasma @ www.ExploitDevelopment.com wrote:

Much ado about nothing!

 TITLE:
 Flaw in Microsoft Domain Account Caching Allows Local Workstation
 Admins to Temporarily Escalate Privileges and Login as Cached Domain
 Admin Accounts

There is NO privilege escalation. A local administrator is an admistrator
is an administrator...

 SUMMARY AND IMPACT:
 All versions of Microsoft Windows operating systems allow real-time
 modifications to the Active Directory cached accounts listing stored
 on all Active Directory domain workstations and servers. This allows
 domain users that have local administrator privileges on domain assets
 to modify their cached accounts to masquerade as other domain users
 that have logged in to those domain assets. This will allow local
 administrators to temporarily escalate their domain privileges on
 domain workstations or servers.

Wrong. The local administrator is already local administrator. There's
nothing the elevate any more.

 If the local administrator masquerades
 as an Active Directory Domain Admin account, the modified cached
 account is now free to modify system files and user account profiles
 using the identity of the Domain Admin's account.

There is no need to masquerade: the local administrator can perform all
these modifications, and if s/he wishes, hide the tracks: turn off
auditing before, clear audit/event logs afterwards, change the SID in
the ACEs of all objects touched (SubInACL.Exe comes handy), ...

Or: just change the NoDefaultAdminOwner setting. After that, all
Administrators masquerade as Administrators. uh-oh.

 This includes
 creating scripts to run as the Domain Admin account the next time that
 they log in.

Ridiculous.
A local administrator can add any script/executable s/he wants to any
autostart (scheduled task, registry, logon script, userinit, shell,
...).
There's ABSOLUTELY no need to masquerade.

 All files created will not be linked to your domain
 account in file and folder access lists.

ACEs can always be edited by a local administrator, see SubInACL.Exe,
or TakeOwn.Exe.

 All security access lists
 will only show the Domain Admin's account once you log out of the
 modified cached account. This leads to a number of security issues
 that I will not attempt to identify in the article. One major issue is
 the lack of non-repudiation. Editing files and other actions will be
 completed as another user account. Event log entries for object access
 will only be created if administrators are auditing successful access
 to files (This will lead to enormous event log sizes).

A local administrator can turn audit/event logs off, clear or modify them.

Stefan

Vulnerable 3rd-party DLLs used in TrendMicro's malware scanner HouseCall

[Stefan Kanthak]

Trend Micro http://www.trendmicro.com/ / http://www.antivirus.com/
offer a free malware cleanup tool named HouseCall 7.1 for Windows:
http://housecall.trendmicro.com/
http://go.trendmicro.com/housecall7/HousecallLauncher.exe
http://go.trendmicro.com/housecall7/HousecallLauncher64.exe


Versions of this security product before the current build 1078
from 2010-08-30, published 2010-09-06 (according to HTTP timestamp),
came with outdated and vulnerable OpenSource components:

1. libcurl.dll: version 7.19.0 from 2008-09-01

   updated 10 times since, at least 3 times due to vulnerabilities;
   see http://curl.haxx.se/ and
   http://curl.haxx.se/docs/security.html
   

2. ssleay32.dll and libeay32.dll: version 0.9.8i from 15.2008-09-15

   updated 5 times since due to vulnerabilities; see
   http://openssl.org/news/ and
   http://openssl.org/news/vulnerabilities.html


3. bzip2.exe: version 1.0.2

   gets downloaded upon start, updated 3 times since then due to
   vulnerabilities; see http://www.bzip.org/downloads.html


Users who downloaded this security product before 2010-09-07 should
get a new copy ASAP!


Stefan Kanthak



Timeline:

2010-07-08: informed vendor support

no reaction

2010-07-15: informed vendor sales department

2010-07-16: reply from vendor: will forward to product manager

2010-07-21: reply from vendor: service engineering team now in charge

2010-08-26: sent status request to vendor

2010-08-26: reply from vendor: will request status from product manager

no more reaction

2010-09-06: silently fixed

2010-09-16: report published

Re: Binary Planting Goes EXE

[Stefan Kanthak]

ACROS Security Lists wrote:

 For everyone interested in binary planting vulnerabilities, here's some new
 information on the EXE vector from our research.

 http://blog.acrossecurity.com/2010/09/binary-planting-goes-exe.html

Tell news!

1) There is an equivalent to SafeDLLSearchPath for executables: see
   http://support.microsoft.com/kb/905890, to be turned on with

   [HKLM\System\CurrentControlSet\Control\Session Manager]
   SafeProcessSearchMode=dword:01


2) You missed %HomeDrive%%HomePath% a.k.a. BASE directory: see
   http://support.microsoft.com/kb/246061, to be turned off with either

   
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
   StartRunNoHomePath=dword:01

   or

   
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
   StartRunNoHomePath=dword:01


3) Planting a rogue executable C:\Program.{exe,com,...} (yes, this needs
   administrative rights in the first place) may still work, even on
   Windows 7 x64: just 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


   Yes, even more than 15 years after introduction of long filenames
   some developers still don't know how to properly quote command lines,
   and their QA seems sound asleep!


Stefan Kanthak

Nuance OmniPage 16 Professional installs multiple vulnerable Microsoft runtime libraries

[Stefan Kanthak]

Nuance Communications, Inc. offer on their german web page
http://www.nuance.de/kostenlose-ocr-software-test/download.asp
a trial version of OmniPage 16 Professional for download.

The installer OPPro16_TD.exe (a self-extracting RAR archive) was
published Tue, 30 Jun 2009 14:38:28 GMT (according to its HTTP
time stamp), unpacking reveals a BUILD.ID OP-0861-035-7563.1134
with time stamp Tue, 17 Jun 2008 09:51:32.

After installation on a fully patched Windows XP with Service Pack 3
the following vulnerable Microsoft runtime libraries are found:

1. %SystemRoot%\SYSTEM32\GDIPLUS.DLL 5.1.3097 2001-06-15 21:00

   GDIPLUS.DLL has been patched several times since 2001, see
   http://www.microsoft.com/technet/security/bulletin/MS08-052.mspx
   or http://support.microsoft.com/kb/954593/en-us for the current
   version, 5.1.3102.5581 (XP SP3) or 5.1.3102.3352 (XP SP2).

   MALUS #1:
 since GDIPLUS.DLL is part of the OS in Windows XP and installed
 in its side-by-side cache a 3rd party vendor MUST NOT install a
 GDIPLUS.DLL into the system directory.
 See http://support.microsoft.com/kb/835322/en-us and
 http://msdn.microsoft.com/en-us/library/ms995328.aspx

   MALUS #2:
 the current version was available when the installer was published!


2. %SystemRoot%\SYSTEM32\CAPICOM.DLL 2.0.0.1 2003-10-28 12:24

   CAPICOM.DLL has been patched several times since 2003, see
   http://www.microsoft.com/technet/security/bulletin/MS07-028.mspx
   or http://support.microsoft.com/kb/931906/en-us for the current
   version, 2.1.0.2.

   MALUS #1:
 the installer is brain-dead, it overwrites a newer version of
 CAPICOM.DLL if this already exists in %SystemRoot%\SYSTEM32\!

   MALUS #2:
 the current version was available when the installer was built!

   MALUS #3:
 the installer does not detect a properly installed current
 version of CAPICOM.DLL in its default location
 %ProgramFiles%\Microsoft CAPICOM 2.1.0.2\Lib\X86\CAPICOM.DLL.

 Registration of the older library over the newer one creates a
 mess with the registered interfaces which will lead to arbitrary
 program errors in applications that use interfaces which had
 been registered by the newer CAPICOM.DLL when called after
 interfaces now registered by the older CAPICOM.DLL.


3. %SystemRoot%\SYSTEM32\MSXML4.DLL  40.10.9404.0 2002-04-02 02:52
   %SystemRoot%\SYSTEM32\MSXML4R.DLL 40.10.9404.0 2002-04-02 02:43

   This is MSXML 4 Service Pack 1, which has been updated several
   times since 2002, see
   http://www.microsoft.com/technet/security/bulletin/MS08-069.mspx
   or http://support.microsoft.com/kb/954430/en-us as well as
   http://support.microsoft.com/kb/973685/en-us for the current
   version, MSXML 4 Service Pack 3.

   MALUS #1:
 the installer is brain-dead, it overwrites newer versions of
 MSXML4*.DLL if these already exist in %SystemRoot%\SYSTEM32\!

   MALUS #2:
 although the current version was not available when the installer
 was published, a newer version than included was available when
 the installer was built, see
 
http://www.microsoft.com/downloads/details.aspx?familyid=3144B72B-B4F2-46DA-B4B6-C5D7485F2B42displaylang=en



Timeline:

2010-06-07  vendor informed per mail (multiple recipients)

2010-06-08  several automatic delivery receipts

2010-06-16  no human reply; 2nd try, vendor informed again

2010-06-17  human reply, promising to forward to responsible team

2010-06-26  no reaction; disclosure


Who cares about software engineering and the build process at Nuance?
Who cares about security of customer systems at Nuance?


Stefan Kanthak

Re: Samba Remote Zero-Day Exploit

[Stefan Kanthak]

Michael Wojcik wrote:

 From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de]
 Sent: Saturday, 06 February, 2010 08:21
 
 Dan Kaminsky wrote:
 
 [...]
 
  (On a side note, you're not going to see this sort of symlink stuff
  on Windows,
 
 What exactly do you mean?
 Traversing symlinks on the server/share, or creation of wide
symlinks
 by the client on the server/share?
 
 Since Windows 2000 NTFS supports junctions, which pretty much
 resemble Unix symlinks, but only for directories.
 See http://support.microsoft.com/kb/205524/en-us

 And at least since Vista, it also supports symlinks, which are designed

s/at least//

[ well-known facts snipped ]

 The Windows SMB server apparently won't cross reparse points, though, so
 there's no equivalent vulnerability.

NO, Windows SMB server crosses reparse points!

But as Dan Kaminsky pointed out, you need to have administrative rights
to remotely create a junction on an SMB share, so the non-admin user
cant get himself access to files outside a share he's allowed to access.

Stefan

Re: Samba Remote Zero-Day Exploit

[Stefan Kanthak]

Dan Kaminsky wrote:

[...]

 (On a side note, you're not going to see this sort of symlink stuff on
 Windows,

What exactly do you mean?
Traversing symlinks on the server/share, or creation of wide symlinks
by the client on the server/share?

Since Windows 2000 NTFS supports junctions, which pretty much resemble
Unix symlinks, but only for directories.
See http://support.microsoft.com/kb/205524/en-us

On the server, create a junction in your share and let it point to an
arbitrary local directory outside the share, and clients connected to
that share can enter the junction and access the linked directory.

If you have write access to the share from the client you can create
a wide junction there too, just as the OP showed with smbclient/samba.

 and Samba is supposed to match Windows semantics in general.

Except a mapping of directory symlinks to junctions for example.-(

Stefan

Re: Samba Remote Zero-Day Exploit

[Stefan Kanthak]

Dan Kaminsky wrote on February 06, 2010 6:43 PM:

 You need admin rights to create junctions.

OUCH!
No, creating junctions (as well as the Vista introduced symlinks)
DOESN'T need admin rights!

[snip]

Stefan

Latest Intel Pro/10* ethernet adaptor drivers contain vulnerable MSVC runtime!

[Stefan Kanthak]

Hi @ll,

Intel just released updated drivers for their ethernet network adaptors,
see
http://downloadcenter.intel.com/Detail_Desc.aspx?agr=YDwnldID=17906ProdId=3025lang=eng
and
http://downloadcenter.intel.com/Detail_Desc.aspx?agr=YDwnldID=18518ProdId=3025lang=eng
for example.

Unfortunately ALL these driver packages but contain an outdated and
unsupported Microsoft Visual C++ 2008 Runtime, repackaged as
VC90_CRT_{x86,ia64,x64}.msi and violating Microsofts redistribution
rules, which installs VULNERABLE runtime DLLs.

See http://support.microsoft.com/kb/973551,
http://support.microsoft.com/kb/973552 and
http://www.microsoft.com/technet/security/bulletin/MS09-035.mspx

Stefan Kanthak

Windows packages for BIND9 contain vulnerable MSVC runtime components

[Stefan Kanthak]

Hi @ll,

ISC just released updates for their supported BIND versions.

Unfortunately ALL the Windows packages (BIND9.6.1-P2.zip,
BIND9.5.2-P1.zip and BIND9.4.3-P4.zip) but contain an outdated
and unsupported Microsoft Visual C++ 2005 Redistributable
(vcredist_x86.exe) which installs VULNERABLE runtime DLLs.

See http://support.microsoft.com/kb/973544 and
http://www.microsoft.com/technet/security/bulletin/MS09-035.mspx

Stefan Kanthak

Vulnerable MSVC++ runtime distributed with OpenOffice.org 3.1.1 for Windows

[Stefan Kanthak]

The just released latest version of OpenOffice.org 3.1.1 for Windows
distributes (once again) a completely outdated and vulnerable MSVC++
runtime.

The unpacked installation archive contains in subdirectory \REDIST\
the installer of the Microsoft Visual C++ 2008 Redistributable,
VCRedist_x86.exe, time stamp 2009-01-19, version 9.0.21022.8.

This file was digitally signed by Microsoft Corporation on 2007-11-07,
i.e. it contains the initial release of the VC++ 2008 runtime.

This runtime but has been updated serveral times since its first
release, the last update was published just a month ago: see
http://support.microsoft.com/kb/973551/en-us as well as
http://www.microsoft.com/technet/security/bulletin/MS09-035.mspx,
for the current version and
http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf
as well as
http://www.microsoft.com/downloads/details.aspx?FamilyID=a5c84275-3b97-4ab7-a40d-3802b2af5fc2
for the previous updates.

Fortunately the eventually installed outdated VC++ runtime will be
updated by the Automatic Updates feature of Windows with the hotfix
MS09-035 alias KB973551, IFF the Windows administrator has opt'd-in
to Microsoft Update.
If not, all users of OpenOffice.org (as well as other poorly crafted
software which distributes outdated 3rd-party DLLs) are put at risk!

Stefan Kanthak

Vulnerable DLLs distributed with Terratec HomeCinema 6.3

[Stefan Kanthak]

Once again a sad story of poor software engineering, missing QA
and a TOTALLY unresponsive vendor.

The current version 6.3 of Terratec's TV software HomeCinema
http://ftp.terratec.de/Receiver/TerraTec_HomeCinema/TerraTec_Home_Cinema_6.3.exe
from 2009-05-05 installs outdated and vulnerable .DLLs (the
test system used is a fully patched german Windows XP SP3):


1. Version 1.2.2 of ZLIB1.DLL is installed as
   %ProgramFiles%\TerraTec\TerraTec HomeCinema\zlib1.dll.

   Current since 2005-07-18 is version 1.2.3 of ZLIB1.DLL
   (see http://zlib.org/):

| Version 1.2.3 eliminates potential security vulnerabilities in
| zlib 1.2.1 and 1.2.2, so all users of those versions should
| *upgrade* *immediately*.


2. Version 5.1.3102.2180 of Microsoft's GDIPLUS.DLL is installed as
   %SystemRoot%\SYSTEM32\GDIPLUS.DLL.

   The current version of GDIPLUS.DLL for Windows XP SP3 is
   5.1.3102.5512, which is already part of the system and installed
   into Windows' side-by-side cache under %SystemRoot%\WinSxS\!

   According the MSDN GDIPLUS.DLL MUST NOT be installed into
   %SystemRoot%\SYSTEM32\, and DLLs distributed with Windows
   MUST NOT be redistributed by ISVs.

   In addition see the MSFT security bulletin MS08-052
   http://www.microsoft.com/technet/security/bulletin/MS08-052.mspx
   as well as the MSFT knowledge base article 954593
   http://support.microsoft.com/kb/954593/en-us.


3. The DLLs of the current version of the component MSXML4 SP2 are
   installed to %SystemRoot%\SYSTEM32\.

   This component is but not installed from the redistributable
   package provided by Microsoft that ISVs have to use to meet the
   legal mumbo-jumbo, instead Terratec choose to repackage the DLLs
   into an NSIS installer, thus violating MSFTs redistribution
   policy.

   (Un)fortunately this NSIS installer is flawed and does not
   perform all the necessary steps needed for a clean installation
   of MSXML4 SP2, so Microsoft Update detects the MSXML4 SP2
   installation as outdated/incomplete and fetches the current
   patch installer (http://support.microsoft.com/kb/954430/en-us,
   http://www.microsoft.com/technet/security/bulletin/MS08-069.mspx)
   to repair it.

   The best of all: MSXML4 is NOT referenced at all by the installed
   application CynergyDVR.EXE, which but uses XMLLITE.DLL
   (http://support.microsoft.com/kb/915865/en-us) instead.


4. A superfluous pthreadVC2.dll is installed as
   %CommonProgramFiles%\TerraTec\Cyberlink\Decoder\pthreadVC2.dll


Stefan Kanthak

PS: Tools like Secunia's PSI don't detect such outdated and
vulnerable DLLs. Admin beware!


TIMELINE:

2009-06-16  phone call with Terratec's hotline - they were unable
to take any action, but requested to send report per
mail

2009-06-17  sent mail to Terratec - no response

2009-06-30  resent mail to Terratec - again no response

2009-07-16  report published

Windows Update (re-)installs outdated Flash ActiveX on Windows XP

[Stefan Kanthak]

Windows Update (as well as Microsoft Update and the Automatic Update)
installs an outdated (and from its manufacturer unsupported) Flash
Player ActiveX control on Windows XP.


Although this fact is nothing really new it but shows the lack of taking
care for security problems and in general the chuzpe of many software
producers to ship their products with outdated and often vulnerable
components.


The ouverture:

* Windows XP RTM (i.e. the original release version without any service
  packs) installs a Flash Player ActiveX control SWFLASH.OCX v5.0r42

* Windows XP Service Pack 1 updates the SWFLASH.OCX to v5.0r44

* Windows XP Service Pack 2 (released in August 2004) replaces the
  SWFLASH.OCX with FLASH.OCX v6.0r79

* security update KB913433 (see http://support.microsoft.com/kb/913433
  and http://www.microsoft.com/technet/security/bulletin/ms06-020.mspx)
  updates FLASH.OCX to 6.0r84

* security update KB923789 (see http://support.microsoft.com/kb/923789
  and http://www.microsoft.com/technet/security/bulletin/ms06-069.mspx)
  updates FLASH.OCX to 6.0r88

* Windows XP Service Pack 3 (released in April 2008) contains the same
  FLASH.OCX v6.0r79 as Service Pack 2, i.e. none of the security updates
  published after Service Pack 2 were incorporated!
  The MSKB article KB948460 but STILL states wrong that KB913433 (sic!)
  is included in Service Pack 3

To my knowledge Adobe stopped direct support for Flash Player 6 in late
2005, the newest version of Flash Player ActiveX 6.0 available on their
web site http://www.adobe.com/go/tn_14266 is 6.0r79 from 2005-11-11.
Later versions of Flash Player ActiveX 6.0 were available from Microsoft
only: http://www.adobe.com/devnet/security/security_zone/apsb06-03.html
and http://www.adobe.com/support/security/bulletins/apsb06-11.html

I doubt that these outdated Flash Player ActiveX controls are safe and
not vulnerable to current exploits, so Microsoft puts it's customers
clearly at risk.


The unhappy end:

* Start with a fully patched Windows XP with Service Pack 3 AND the
  current Adobe Flash Player ActiveX v10.0r22.87 installed.

  Since recent Flash Player installers remove any older versions of the
  ActiveX control this means that neither FLASH.OCX nor SWFLASH.OCX are
  present in %SystemRoot%\System32\Macromed\ or
  %SystemRoot%\System32\Macromed\Flash\

* Install an arbitrary software product that installs a Flash Player
  ActiveX prior to 6.0r88 (there are MANY software products that do so).

  For example, get the current MSN CD-ROM MSN 9.6-PROD, part no.
  X14-85160-02 DE from Microsoft; this CD-ROM contains the product
  Digital Image Standard Edition 2006 v11.1 from 2007-01-29, which
  installs an outdated and VULNERABLE FLASH.OCX v6.0r29 to
  %SystemRoot%\System32\Macromed\!

  Note that the installer was created AFTER KB923789, which but was not
  incorporated. Does Microsoft really care about security?

  If you dont want to order the MSN CD-ROM a trial version of Digital
  Image Starter Edition 2006 is available from
  
http://www.microsoft.com/downloads/details.aspx?FamilyID=7c3b3ded-a15f-48c5-b724-7796fe8c151e

  If you dont want to install such a big product either, get the
  Windows Update KB913433 from
  
http://www.microsoft.com/downloads/details.aspx?FamilyId=B2B8F9A8-4874-405A-9F0C-768B2631673A
  extract the Flash Player ActiveX installer INSTALL_FP6_WU.EXE from
  the package and run the installer.

  The attempt to install a Flash Player ActiveX prior to 6.0r88 over a
  later version does not YET any harm, since starting with 6.0r88 Adobe
  sets deny ACLs on the %SystemRoot%\System32\Macromed\Flash\FLASH*.OCX
  as well as all the registry entries which prevent earlier Flash Player
  ActiveX installers to overwrite them, so any Flash Player ActiveX
  6.0r88 and later is preserved.

  Any of the above mentioned products but installs the previously not
  existent file %SystemRoot%\System32\Macromed\Flash\FLASH*.OCX

* Visit http://windowsupdate.microsoft.com/ (or wait till the daily
  run of the Automatic Update) and install the Windows Update KB923789.

  This but DOES harm: since the Flash Player ActiveX installer that has
  been wrapped in KB923789 (re-)sets the ACLs it overwrites the registry
  entries of the newer/recent Flash Player ActiveX. DAMAGE DONE!


I informed Microsoft in the last two years several times about this
problem and discussed it with various members of their Microsoft Security
Response Center, but the problem persists.


Stefan Kanthak

Re: OpenID/Debian PRNG/DNS Cache poisoning advisory

[Stefan Kanthak]

Dan Kaminsky wrote:
 
 
 Eric Rescorla wrote:
 At Fri, 8 Aug 2008 17:31:15 +0100,
 Dave Korn wrote:
   
 Eric Rescorla wrote on 08 August 2008 16:06:

 
 At Fri, 8 Aug 2008 11:50:59 +0100,
 Ben Laurie wrote:
   
 However, since the CRLs will almost certainly not be checked, this
 means the site will still be vulnerable to attack for the lifetime of
 the certificate (and perhaps beyond, depending on user
 behaviour). Note that shutting down the site DOES NOT prevent the attack.

 Therefore mitigation falls to other parties.

 1. Browsers must check CRLs by default.
 
 Isn't this a good argument for blacklisting the keys on the client
 side?
   
   Isn't that exactly what Browsers must check CRLs means in this context
 anyway?  What alternative client-side blacklisting mechanism do you suggest?
 

 It's easy to compute all the public keys that will be generated
 by the broken PRNG. The clients could embed that list and refuse
 to accept any certificate containing one of them. So, this
 is distinct from CRLs in that it doesn't require knowing 
 which servers have which cert...
 Funnily enough I was just working on this -- and found that we'd end up 
 adding a couple megabytes to every browser.

At least for the weak keys kudos to Debian's OpenSSL maintainer
there exists an extension to Firefox which checks the keys, see 
http://codefromthe70s.org/sslblacklist.asp, as well as c't's
SSLguardian for the Windows Crypto API, see
http://www.heise-online.co.uk/security/features/111039/0 and
http://www.heise-online.co.uk/security/features/111039/1

Stefan

Re: Firewire Attack on Windows Vista

[Stefan Kanthak]

Steve Shockley wrote:

 Stefan Kanthak wrote:
 2. The typical user authentication won't help, we're at hardware
 level here, and no OS needs to be involved.
 
 So, if I understand you correctly, if I boot my machine into DOS the 
 memory can be read over Firewire?

If DMA is enabled on the firewire interface its possible!

If the BIOS allows to boot from a firewire device then it will setup
the hardware!

 Or does the machine need a Firewire driver loaded to be vulnerable?

If the BIOS does not setup the firewire interface the some driver has
to do it. So: it depends.

You can also read the memory if you shut down but dont power off your
system. Typically drivers leave their devices in working condition.

Stefan

Re: Firewire Attack on Windows Vista

[Stefan Kanthak]

Larry Seltzer wrote:


 I actually do have a response fom Microsoft on the broader issue, but it
 doesn't address these issues or even concded that there's necessarily
 anything they can do about it. They instead speak of the same
 precautions for physical access that they spoke of a couple weeks ago
 with respect to the frozen notebook memory attack - use drive
 encryption, use 2-factor authentication, use hibernate instead of sleep,
 use group policy to enforce them. I don't think it's a bad response
 under the circumstances.

WRT the DMA access over FireWire it's but a bad response since it doesn't
get the point!

1. Drive encryption won't help against reading the memory.

2. The typical user authentication won't help, we're at hardware level
   here, and no OS needs to be involved.

3. The computer is up (and running; see above), no hibernate or sleep
   is involved here.

4. Group policies can be circumvented, even by a limited user.
   
http://blogs.technet.com/markrussinovich/archive/2005/12/12/circumventing-group-policy-as-a-limited-user.aspx

Stefan

Re: [Full-disclosure] Firewire Attack on Windows Vista

[Stefan Kanthak]

Larry Seltzer wrote:

WRT the DMA access over FireWire it's but a bad response since it
doesn't get the point!
1. Drive encryption won't help against reading the memory.
2. The typical user authentication won't help, we're at hardware level
   here, and no OS needs to be involved.
3. The computer is up (and running; see above), no hibernate or sleep
   is involved here.

 So on a freshly-booted system with drive encryption you can read
 whatever you want on the disk? 

No. As another poster already wrote: there's no(t yet a) disk involved.

The attacker just reads the memory and can then try to find cached
credentials or cryptographic keys (as described in the paper by Ed Felten
et al).

But let's take it further: Windows uses TCP/IP over IEEE 1394 in
standard setup, so after getting the cached credentials of an
Administrator from memory an attacker can successfully (I assume a
standard setup where the Windows firewall allows accesses from the own
subnet) mount \\target\C$ or \\target\ADMIN$ and thus read the files
on the disk. If only drive encryption is used, the files are decrypted
by the target.

4. Group policies can be circumvented, even by a limited user.

http://blogs.technet.com/markrussinovich/archive/2005/12/12/circumventi
ng-group-policy-as-a-limited-user.aspx 

What he says is that some group policies, not including system-wide
security settings, maybe circumvented, even by a limited user.

Right. The point is that group policies can/might help, but are not
fool proof.

Stefan Kanthak

Re: Windows binary of GSview 4.8 contain vulnerable zlib (CAN-2005-2096) and vulnerable bz2lib (CAN-2005-0758 CAN-2005-0953)

[Stefan Kanthak]

I wrote Monday, October 29, 2007 10:04 PM:


 I wrote Sunday, October 21, 2007 2:18 PM:
 
  Anonymous [EMAIL PROTECTED] wrote Saturday, October 20, 2007 11:55 AM:
  
  As a workaround, one could try to manually replace zlib32.dll in a Windows
  GSView 4.8 installation with the current zlib1.dll version 1.2.3.
 
 [...]
 
  Unfortunately the maintainer of GSview choose not to reply to my bug
  report which included a question about the source of the ZLIB32.DLL.
 
 The maintainer finally replied to the last of my three attempts to
 contact him (very timely, regarding the different timezones we are in):
 
 | I can't do much about it just at the moment.  I've had a computer
 | motherboard failure and while I've now got a new computer, I haven't
 | got all my development tools running yet.
 |
 | I will update the DLL in the next release.  Yes, I compiled the DLL
 | myself.  There wasn't a precompiled version at the time I started using
 | it.

In the meantime an updated version 4.9 of GSView is available from
http://www.cs.wisc.edu/~ghost/gsview/ that fixes CAN-2005-2096 (zlib)
as well as CAN-2005-0953 and CAN-2005-0758 (libbz2).

The latter had been disclosed to the author/maintainer only until now.

The zlib32.dll distributed in the installation is now the official
zlib1.dll from zlib.net; due to a lack of an official libbz2.dll this
one is provided by the maintainer.

Stefan Kanthak

Windows binary of Virtual Floppy Drive 2.1 contains vulnerable zlib (CAN-2005-2096)

[Stefan Kanthak]

The binary of the (presumably not widely used) Windows software
Virtual Floppy Drive 2.1
http://chitchat.at.infoseek.co.jp/vmware/vfd.html
ships with a vfd.dll that is statically linked against zlib 1.2.2
http://www.zlib.net/ which is vulnerable to CAN-2005-2096.


A scan with ClamAV against the patterns published by Florian Weimer
at http://www.enyo.de/fw/security/zlib-fingerprint/ verifies the
presence of the patterns of the vulnerable code:

| x:\clamscan --database CAN-2005-2096.db
| VFD.DLL: CAN-2005-2096.zlib-1.2.2 FOUND
|
| --- SCAN SUMMARY ---
| Known viruses: 16
| Engine version: 0.91.2
| Scanned directories: 1
| Scanned files: 1


The author and maintainer has been contacted twice via mail in
the last four weeks but choose not to respond at all.


Stefan Kanthak

Re: Windows binary of GSview 4.8 contain vulnerable zlib (CAN-2005-2096)

[Stefan Kanthak]

I wrote Sunday, October 21, 2007 2:18 PM:

 Anonymous [EMAIL PROTECTED] wrote Saturday, October 20, 2007 11:55 AM:
 
 As a workaround, one could try to manually replace zlib32.dll in a Windows
 GSView 4.8 installation with the current zlib1.dll version 1.2.3.

[...]

 Unfortunately the maintainer of GSview choose not to reply to my bug
 report which included a question about the source of the ZLIB32.DLL.

The maintainer finally replied to the last of my three attempts to
contact him (very timely, regarding the different timezones we are in):

| I can't do much about it just at the moment.  I've had a computer
| motherboard failure and while I've now got a new computer, I haven't
| got all my development tools running yet.
|
| I will update the DLL in the next release.  Yes, I compiled the DLL
| myself.  There wasn't a precompiled version at the time I started using
| it.

 As long as I cant be sure that the replacement zlib1.dll from zlib.net
 is fully compatible to the ZLIB32.DLL distributed with GSview 4.8 I wont
 give any advice to exchange it.

q.e.d.

Stefan

Re: Windows binary of GSview 4.8 contain vulnerable zlib (CAN-2005-2096)

[Stefan Kanthak]

Anonymous [EMAIL PROTECTED] wrote Saturday, October 20, 2007 11:55 AM:

 As a workaround, one could try to manually replace zlib32.dll in a Windows
 GSView 4.8 installation with the current zlib1.dll version 1.2.3.

 Applications linking statically with or using their own copy of zlib 1.1.3
 or earlier must be recompiled to avoid the security problem described here.
 Otherwise it is sufficient to upgrade the shared zlib library then restart
 all applications using it.[1]

 [1] http://www.zlib.net/apps.html

http://www.zlib.net/DLL_FAQ.txt (according to the HTTP response last
modified on Sunday, 24 Oct 2004 20:53:16 GMT) states that zlib1.dll 1.2.x
is linked against MSVCRT.DLL.

The vulnerable ZLIB32.DLL distributed with GSview 4.8 is but not linked
against MSVCRT.DLL. Although its version/copyright strings equal the ones
of the official zlib1.dll from zlib.net, I'm not sure who built the
ZLIB32.DLL in question. It doesn't completely look like the official
zlib1.dll.

Unfortunately the maintainer of GSview choose not to reply to my bug
report which included a question about the source of the ZLIB32.DLL.

As long as I cant be sure that the replacement zlib1.dll from zlib.net
is fully compatible to the ZLIB32.DLL distributed with GSview 4.8 I wont
give any advice to exchange it.

BTW: replacement of ZLIB32.DLL wont close all the vulnerabilities in
GSview 4.8. The maintainer was informed about some more (trivial to spot)
vulnerabilities together with the here published one.

Stefan Kanthak

BTW: your reply is missing a References: (or In-Reply-To:) header!

Windows binary of GSview 4.8 contain vulnerable zlib (CAN-2005-2096)

[Stefan Kanthak]

The Windows binary GSV48W32.EXE of gsview
http://pages.cs.wisc.edu/~ghost/gsview/
ftp://mirror.cs.wisc.edu/pub/mirrors/ghost/ghostgum/gsv48w32.exe
ships with a zlib32.dll (originally named zlib.dll) v1.2.2
http://www.zlib.net/ which is vulnerable to CAN-2005-2096.

The zlib32.dll is dated 2005-03-06 (GSview 4.8 was release 2005-03-26),
i.e. before CAN-2005-2096 was published, so its very likely that all
the binaries provided by the author will show a vulnerable zlib if they
contain one.

A scan with ClamAV against the patterns published by Florian Weimer
at http://www.enyo.de/fw/security/zlib-fingerprint/ verifies the
presence of the patterns of the vulnerable code:

| x:\clamscan --database CAN-2005-2096.db
| ZLIB32.DLL: CAN-2005-2096.zlib-1.2.2 FOUND
|
| --- SCAN SUMMARY ---
| Known viruses: 16
| Engine version: 0.91.2
| Scanned directories: 1
| Scanned files: 1

Stefan Kanthak

Softwin's anti-virus BitDefender contains vulnerable zlib (CA-2007-07)

[Stefan Kanthak]

At least the freeware version of Softwin's anti-virus solution
BitDefender Free Edition
http://www.bitdefender.com/site/view/Download-Free-Products.html
http://download.bitdefender.com/windows/free/winfree/en/bitdefender_free_v10.exe
ships with a completely outdated zlib 1.1.3 http://www.zlib.net/
that is vulnerable to CA-2007-07 http://www.zlib.net/advisory-2002-03-11.txt.

The zlib.dll included in the versions 7.2, 8.0 and the current 10.0
of their products is dated 1998-07-12 and shows the version 1.1.3.

Stefan Kanthak

Official Windows binaries of curl contain vulnerable zlib 1.2.2 (CAN-2005-2096)

[Stefan Kanthak]

The Windows binaries of curl, built by the author and maintainer of
curl and available for download at http://curl.haxx.se/download.html
are linked with zlib 1.2.2 http://www.zlib.net/, which is but
vulnerable to CAN-2005-2096:

| x:\curl -V
| curl 7.17.0 (i586-pc-mingw32msvc) libcurl/7.17.0 zlib/1.2.2
| Protocols: tftp ftp telnet dict ldap http file
| Features: Largefile NTLM SSPI libz

A scan with ClamAV against the patterns published by Florian Weimer
at http://www.enyo.de/fw/security/zlib-fingerprint/ verifies the
presence of the patterns of the vulnerable code:

| x:\clamscan --database CAN-2005-2096.db
| CURL.EXE: CAN-2005-2096.zlib-1.2.2 FOUND
|
| --- SCAN SUMMARY ---
| Known viruses: 16
| Engine version: 0.91.2
| Scanned directories: 1
| Scanned files: 1

Stefan Kanthak