Patch Tuesday - August 2008

ChangeBase AOK – Patch Tuesday Update
July 2008


As part of the July release of the regularly scheduled Microsoft Updates, there are currently eleven scheduled for release; six with the maximum rating of Critical and five with the maximum rating of Important.

Here is a brief summary of the patches that affect the Microsoft Windows operating system;

1) Microsoft Security Bulletin MS08-045
Description: Cumulative Security Update for Internet Explorer (953838). This security update resolves five privately reported vulnerabilities and one publicly disclosed vulnerability. All of the vulnerabilities could allow remote code execution if a user views a specially crafted Web page using Internet Explorer.

2) Microsoft Security Bulletin MS08-046
Description: Vulnerability in Microsoft Windows Image Colour Management System Could Allow Remote Code Execution (952954). This update resolves a privately reported vulnerability in the Microsoft Image Colour Management (ICM) system that could allow remote code execution in the context of the current user.

3) Microsoft Security Bulletin MS08-047
Description: Vulnerability in IPsec Policy Processing Could Allow Information Disclosure (953733). This update resolves a privately reported vulnerability in the way certain Windows Internet Protocol Security (IPsec) rules are applied.

4) Microsoft Security Bulletin MS08-048
Description: Vulnerability in IPsec Policy Processing Could Allow Information Disclosure (953733). This update resolves a privately reported vulnerability in the way certain Windows Internet Protocol Security (IPsec) rules are applied. This vulnerability could cause systems to ignore IPsec policies and transmit network traffic in clear text.

5) Microsoft Security Bulletin MS08-049
Description: Vulnerabilities in Event System Could Allow Remote Code Execution (950974). This update resolves two privately reported vulnerabilities in Microsoft Windows Event System that could allow remote code execution.

6) Microsoft Security Bulletin MS08-050
Description: Vulnerability in Windows Messenger Could Allow Information Disclosure (955702). This security update resolves a publicly reported vulnerability in supported versions of Windows Messenger. As a result of this vulnerability, scripting of an ActiveX control could allow information disclosure in the context of the logged-on user.

Note: These are not all of the patches that have been released by Microsoft today as the following only apply to Microsoft Office products;

• Microsoft Security Bulletin MS08-042
• Microsoft Security Bulletin MS08-041
• Microsoft Security Bulletin MS08-043
• Microsoft Security Bulletin MS08-051
• Microsoft Security Bulletin MS08-044

Using the ChangeBase AOK Workbench to analyse each of these patches against a sample of approximately 700 unique application packages with the intention of providing some insight into the following questions;

What patches when released are likely to cause my applications to fail?
What patches contain files and settings already included in my application portfolio?
What order should I test my applications?
What patches should I test most and why?

Results
The following table details the results from the ChangeBase AOK Patch Impact Analysis and includes information on what application packages in the sample portfolio;

What is the total number of applications affected by each patch?
What applications also include files and configuration data that were embedded in the patch update?
What applications had specific dependencies on changes includes in these updates



Special Notes:

• MS08-046 Security Update for Windows Server 2003 raised a specific driver issues with Fujitsu 4340 colour scanners (mscms.dll)
• MS08-048 Security Update for Windows Mail raised a specific DLL conflict with Microsoft Digital Image software
• MS08-050 Security Update for Windows XP raised an application conflict with Microsoft Messenger



Conclusion

From the results derived from the ChangeBase AOK Patch Impact Analysis, it appears that the following patch updates could be deployed with relatively light testing and with an expected minimal impact on the application portfolio; MS08-46, MS08-47, MS08-48, MS08-49 and MS08-50. However, the Microsoft Internet Explorer 7 Update IE7 (MS08-045) appears to cause application level conflict issues and has been raised a direct dependency for a number of applications. This could mean that these applications may be adversely affected by the MS08-045 update and this patch should be fully tested prior to deployment to production environments.

The Microsoft Compatiblity database - Dynamic Shims

I was doing some thinking about a central database of application compatibility shims. I have a couple of concerns regarding the implementation/deployment of these compatibility shims – but these may be more due to my ignorance rather than the limitations of the design/deployment of this compatibility technology.

First, is that the shim is “attached” to the application object and is not related to the user and second, I have found it hard to separate shims into “machine” shims and "user" shims; effectively separating changes to the target desktop or server environment based on machine or user privileges . This is important for deployment reasons and that we may not want to apply a particular shim to a particular user on a particular machine or a particular machine etc… you get the get the kind of matrix of deployment scenarios that one could encounter.

So, following along these lines, I wanted to move up the problem tree and start dealing with the compatibility problem on a larger (let’s call it Enterprise) level. Some of the things that I would require from an application compatibility framework/approach would include the following “pillars”;

- Leverage existing management approaches and technologies covering
- Deployment
- Reporting/Audit
- Updating/Removal
- Support for central management, remote access and disconnected use
- Support for machine, user, grouping and domain focused management
- Support for versioning, incremental updates and roll-backs

Using these pillars of Enterprise Compatibility Management, my thinking led me to use Active Directory as a central store for all compatibility settings. These GP objects would contain either the machine or the user appropriate settings for each app compatibility issue and would benefit from both GPO deployment and reporting technologies.

If this has not already be done, I think that we would probably not want to store all of the shim data in AD… we may need a translator that sits between the deployed AD registry settings and the local machine SDB database. Something like the following rough diagram ;



Using this approach we could deploy shims to the user, desktop, group or by domain. We could also determine what settings have been put in place and be able to audit the results. Also, no major technology needs to be created. We could use the existing SDB database (which incidentally gets recompiled every time a change is made anyway). We would require the creation of a Active Directory GPO2SDB converter and the WMI interface but that could done relatively easily now that the SDB API's have been made available on MSDN and their is an XML converter for viewing the contents of the SDB database.

The WMI interface would be required to interrogate the closed SDB database and enable auditing and reporting of the result SHIM changes to the local machine.

API calls that break applications

As mentioned in the Microsoft Compatibility tool-kit, the Developer cookbook and Microsoft Developer Network (MSDN - see references below) Safe Exception handling under Vista refers to the deprecation (end of support) for two API's under Vista, Windows 2003 and Windows Longhorn Server. These two API's (IsBadReadPtr and IsBadWritePtr)

relate to the handling of pointer to the global memory stack used by Windows.

These two API calls are used ensure that a particular pointer (or memory handle) is properly committed to the Windows Heap stack. Meaning that the code in question has not cased a corruption in the Windows swap file or memory stack. These two calls were intended for debugging purposes and known affectionately as "CrashMyApplication" and "CrashMyApplicationAndMyMemory" respectively as they had a very common habit of crashing an application under debug and trace conditions.

Microsoft has removed support for the two API's for security reasons and Windows Vista and Longhorn server will no longer support these API's. It is possible to determine if these calls are included in shipped software but unless the application is tested thoroughly and all functionality is tested, it is impossible to determine if these calls are actually employed and potentially could cause a compatibility issue. However, there is a rough an ready way to determine if these calls are actively employed in an application. If the application works under the following operating systems, then these calls are not being used;

· Windows 2K (all service packs)
· Windows XP SP1 and SP2
· Windows 2000 Advanced Server
· Windows 2003 Server

The IsBadReadPtr and isBadWritePtr API calls really translate to very old applications that related to Windows 9x and NT4 systems. If your applications are currently running normally (i.e. without frequent and continuous crashes) then your application is very unlikely to actively employ these (now deprecated) API calls.

Simply scanning an application for references to these API's would produce serious over-reporting without actually demonstrating that these calls are likely to be used in a production environment (i.e not a developer testing or debugging mode). As such, ChangeBASE does not currently scan for these deprecated API calls as part of the Platform Integrity analysis.

References:

IsBadReadPtr references can be found at;
http://msdn2.microsoft.com/En-US/library/aa366713.aspx

IsBadWritePtr references can be found at;
http://msdn2.microsoft.com/En-US/library/aa366716.aspx

Critical Section and Vista Compatibility

There have been a number of questions raised about why ChangeBASE currently does not analyze applications for Critical Section security issues. Referencing the Windows 3.1 Windows Logo certification program and Microsoft's developer handbook, "Critical Section" changes under Vista include the following recommendations;

"Developer Code should always;
Should always initialize critical sections.
Should not read into undocumented objects. Applications that read into the undocumented structures to assess the status of a critical section will most likely break if they are looking for uninitialized and freed critical sections.
Should prevent starvation. Applications that call Sleep while holding the critical section lock now can cause starvation for other threads that need the lock. Sleep calls should be placed after the LeaveCriticalSection call."

To analyze specific Critical Section thread synchronization references (i.e. InitializeCriticalSectionAndSpinCount or EnterCriticalSection ) you must be able to determine the process flow or the logic flow of the software under analysis. And to this, you must run the software and walk through the desired functionality. It is possible to examine file and COM object headers for these types of functions. However, this will generate a significant "over-reporting" issue without actually producing useful information on whether the identified Critical Section functions may cause a problem.

Given that, the impact of this issue is slightly reduced performance issues on multi-threaded applications and the probability of an adverse impact is extremely low, ChangeBASE is currently not including the Critical Section analysis in the Platform Integrity plugin pack.

Further Information on Critical Section code changes can be found at:
http://msdn2.microsoft.com/en-us/library/ms682530.aspx

The 6 Laws of AOK Compatibility

There is much in the news about Vista and migrating to Vista recently. Of prime concern is application compatibility which when simply put means getting applications to work on the target desktop or server environment. There is a lot of complexity in getting applications working - whether on Windows XP or Vista or the soon to be released Windows Server 2008.

And this is where I think there is some general confusion. Application compatibility is not simply about getting applications to function or work correctly on an Operating system such as Vista. Ensuring that application work correctly really means getting the application to work on the target platform and which involves the following;

1. Ensuring Operating System (e.g. Vista ) compatibility
2. Ensuring the availability of the complete and correct versions of middleware
3. Ensuring that applications do not conflict with each other (on install and un-install)
4. Ensuring that user environment is correctly setup and available

Breaking the application compatibility question into these four layers delivers a fundamental step change in the understanding and resolution of application compatibility issues. No longer can we just get one application to work on a desktop, we need to get several or even tens of applications to successfully install, update and un-install without breaking other applications. We now have large, complex and constantly changing middleware layers (Java, Crystal Reports, ODBC) that applications depend upon. Adding to the confusion, differing applications may require different versions of middleware components or worse, may ship from the software vendors with incomplete ("middleware fragments") dependencies which may allow the application in question to function but may prevent another application from working or even installing successfully. Viewing application compatibility with these four layers in mind requires a paradigm shift; to the Platform Integrity model which takes into account all of the requirements to successfully install, use and maintain applications.

To further this goal, AOK has developed the "AOK Laws of Application Compatibility" which include;

1. Enable the installation package to install successfully
2. Provide the application the required privileges and security access levels
3. Ensure that the required dependencies (middleware) are available and complete
4. Ensure that applications do not conflict with each other on installation, updating/patching or un-installation
5. Ensure that the user environment is correctly configured
6. Ensure that future changes/patches/updates do not adversely affect any of the four layers; the OS, the Middleware layer, Applications or the User Environment

When you follow these guidelines, your chances of successfully developing, deploying and maintaining your application portfolio are significantly increased; today and when dealing with future changes.