Saturday 23 January 2010

IE6: Almost Negligence

Last year I had the opportunity to meet with one of the directors from Microsoft and he made some interesting comments which made me rethink my view of history a little.

One of the things that he mentioned was that the release of Windows XP SP2 (and it's associated security features) was a really a moral obligation by Microsoft to increase the security and protection for their massive Windows client base.  Windows XP SP1 was a nightmare for people connecting to the internet/web as it just did not have the correct security settings and features for people to surf online safely. Windows XP Service Pack 2 (XPSP2) included these necessary features and was released free of charge by Microsoft. Which was good news!

Whether this was a pragmatic realization that if Microsoft didn't do something quick to stem the flow attacks and vulnerabilities that Windows XP Service Pack (XP SP1) suffered they would be subject to a massive class-action legal suit or a true understanding of client requirements. Given the discussions I had with other people close to the development of XP SP2, I think it was the latter and a tacit acknowledgement of the responsibility Microsoft incurred when releasing Windows XP just prior to the rise the web and subsequent cyber-attacks.

I feel that we are in a similar position now with IE6. And this time, Microsoft is not in the moral hot-seat.

It is the now the IT directors who are maintaining Windows XP clients with Internet Explorer 6 (IE6). Internet Explorer 8 (IE8) has been released for a while now and with the recent, coordinated and sophisticated attacks used to hack into Google largely mitigated by IE8 and IE7, the further use of IE6 is getting into the arena of negligence.

I recognize that upgrades are time consuming, expensive and may require resources that could be used elsewhere. However, the savings of the continued use of IE6 may soon be far out-weighed by the costs of a successful attack on the corporate network.

Internet Explorer 8 and it's contemporaries (Chrome, Firefox) are now readily available , with much improved security and protections against internet attacks. It's time for these large (and mid-sized organizations) to get the planning and migration effort started - lest those high-backed leather executive styled chairs become uncomfortably warm.

Thursday 21 January 2010

Windows 7 False God Modes

    Paul Thurrott wrote a little while ago about the Windows 7 God Mode. Where "God Mode" is the ability to access all of the Control Panel applets through a single standard Windows 7 Shell folder.  You can find his explanation here:
    So, this Windows 7 feature is pretty simple; you add a new Folder with a special name to your desktop and you get access to all of the Windows 7 Control Panel applet functionality and features through a single Explorer interface - which is pretty cool.
    Which got me thinking. Hey, this can't be that special… The name of the God Mode folder is just a GUID… So, I searched my Windows 7 local registry for that GUID and found the following;
    Note: the full path to the this registry location is:  HKEY_CLASSES_ROOT\CLSID\{ED7BA470-8E54-465E-825C-99712043E01C}
    So,  nothing special here… Just a bunch of CLSID's and a reference to the Control Panel. Which means that this "God Mode" is just a "handle" to these GUIDS through the Windows Shell…
    Meaning, that we should be able to get access to any Object that has a shell folder and Icon using the same trick…
    So,  we should be able to access the Windows 7 Sensor Control Panel Applet by creating a folder on my desktop with the name;
    And, then what about "Windows Slide Show Settings"?
    Just create a folder with the name; Test.{E95A4861-D57A-4be1-AD0F-35267E261739}
    And, because these GUID folders under the CLSID tree have registered Icons, you get the pretty pictures as well.
    Have a look at the "collections of false gods" that I have created
    Now, I have the "Power" to create gods... and I never knew it... :)

Wednesday 20 January 2010

Office 2010: The next application compatibility game...

I am trying to be a little ahead of the curve on this one.

Office 2010 is obviously coming (duh - the date in the name kinda gives it away) and I am currently planning NOT to completely disregard the application compatibility issues of integrating applications into later versions of Microsoft Office. I also plan NOT to say, "What are you worried about? It should be simple".

This is called experience...

I have just started reviewing the Microsoft Office 2010 compatibility documents recently updated (December 2009) by Microsoft and it looks like there are going to be few compatibility "Gotcha's".

First, the documents are located here:

Application compatibility assessment and remediation guide for Office 2010

And, I highly recommend the changes section detailing what has been changed and what features have been removed in the journey from Office 2007 to Office 2010 which can be found here;

Also, the Office 2010 Compatibility Microsoft blog ("Gray Matter" is an excellent resource for the Office compatibility tools. This blog can be found here:

As an example, here is a list of the features and functionality that has been removed from Word 2010:

  • Person Name removal of smart tag: The Person Name (Outlook E-mail Contacts) smart tag will be removed and replaced with functionality that uses the Global Address List (GAL) through Microsoft Office Communicator. In Word the functionality will be replaced by the “additional actions” functionality described earlier in this article, but in Excel the functionality will be completely removed. The 2007 Office system will be the last version that supports this functionality.

  • AutoSummary: AutoSummary is the feature that lists the Title, Subject, Author, Keywords, and Comments. This feature was available from the Tools menu. In Word 2010, this feature is no longer used. If you insert an abstract into the document, that is not AutoSummary data and will remain. However, if the document was in a summary view when it is saved, it will not be after you open it.

  • Microsoft Office Document Imaging (MODI): MODI provided a common document imaging and scanning solution for Office. It was also the basis of the Fax feature for Office. When MODI was installed, it was the default handler for .tif, .tiff, and .mdi files. In Office 2010, MODI is fully deprecated. This change also affects the setup tree, which no longer shows the MODI Help, OCR, or Indexing Service Filter nodes on the Tools menu. The Internet Fax feature in Office 2010 uses the Windows Fax printer driver to generate a fixed file format (TIF). MODI and all its components are deprecated for 64-bit Office 2010.

  • Research and Reference pane: The Research and Reference pane is removed from Windows Internet Explorer 7. Therefore, the shortcut ALT+Click in Microsoft Word 2010 no longer takes users to that pane. The Research and Reference feature brought up a research pane to search all Intranet sites and portals.

  • Mail Merge by using a Works database: Users cannot perform a mail merge in Microsoft Word 2010 or Microsoft Publisher 2010 by using a Microsoft Works database, because of a change in the object model. This primarily affects users who have configured a recurring mail merge that reads content from a Works database. We recommend that you use Works to export the data and then create a new data source for performing the mail merge operation.

  • Search Libraries button: The Search Libraries button is removed from the Insert Citations menu (on the References Tab).

  • WLL (Word Add-in Libraries): WLL files are deprecated for both 32-bit and 64-bit Office 2010. A WLL is an add-in for Microsoft Word that you can build with any compiler that supports building DLLs.

I can definitely see the MODI and WLL deprecations having an impact on Application Integration and compatibility.

Monday 18 January 2010

SVS and Multi-String Registry Values

I have been told there is a problem with Symantec's SVS Virtualisation solution regarding registry entries in the "Virtual File System" incorrectly over-lapping with the native registry. And, I am not sure if this problem is specific to SVS or is a problem that all virtualization technologies experience.

This problematic situation occurs when an application contains an particular type of registry setting that contains lists of items or more importantly attempts to update an existing list of registry items on the native workstation  or server environment.

To quantify the problem, here is a brief description of the types of registry settings support by the Windows registry  that has been sourced from a Microsoft Support page;

Data type
Binary Value
Raw binary data. Most hardware component information is stored as binary data and is displayed in Registry Editor in hexadecimal format.
Data represented by a number that is 4 bytes long (a 32-bit integer). Many parameters for device drivers and services are this type and are displayed in Registry Editor in binary, hexadecimal, or decimal format. Related values are DWORD_LITTLE_ENDIAN (least significant byte is at the lowest address) and REG_DWORD_BIG_ENDIAN (least significant byte is at the highest address).
Expandable String Value
A variable-length data string. This data type includes variables that are resolved when a program or service uses the data.
Multi-String Value
A multiple string. Values that contain lists or multiple values in a form that people can read are generally this type. Entries are separated by spaces, commas, or other marks.
String Value
A fixed-length text string.
Binary Value
A series of nested arrays that is designed to store a resource list that is used by a hardware device driver or one of the physical devices it controls. This data is detected and written in the \ResourceMap tree by the system and is displayed in Registry Editor in hexadecimal format as a Binary Value.
Binary Value
A series of nested arrays that is designed to store a device driver's list of possible hardware resources the driver or one of the physical devices it controls can use. The system writes a subset of this list in the \ResourceMap tree. This data is detected by the system and is displayed in Registry Editor in hexadecimal format as a Binary Value.
Binary Value
A series of nested arrays that is designed to store a resource list that is used by a physical hardware device. This data is detected and written in the \HardwareDescription tree by the system and is displayed in Registry Editor in hexadecimal format as a Binary Value.
Data without any particular type. This data is written to the registry by the system or applications and is displayed in Registry Editor in hexadecimal format as a Binary Value
A Unicode string naming a symbolic link.
Data represented by a number that is a 64-bit integer. This data is displayed in Registry Editor as a Binary Value and was introduced in Windows 2000.

The key issue here is the  REG_MULTI_SZ registry type.  If you are a native application that as part of the installation process add or edits  a list of registry entries in a registry key with type  REG_MULTI_SZ (Multi-String Values) then you will successfully add, edit or replace ONE particular application setting. 

If you are a virtualized application, the capture (or sequencing) process  will OVERWRITE  existing list  of registry settings with the REG_MULTI_SZ  type. This may cause application or worse, OS settings to be lost, read in the wrong order or read altogether incorrectly.

So, I have demonstrated this application compatibility issue with SVS, but not yet with Microsoft's APP-V product. The question, is this "REG Multi-String" edit/over-write issue systemic to all virtualization technologies.


Thursday 14 January 2010

Patch Tuesday: January 2010

With this January Microsoft Patch Tuesday Security Update, we see a very minor update with a single patch rated as Critical. Unfortunately, this patch WILL require a reboot.

Based on our sample of over 1,000 applications we have looked at conflicts with Microsoft Security Updates and the potential dependencies.
Based on the results of our AOK Application Compatibility Lab this single patch has limited impact on applications. We have included a brief snap-shot of some of the results from our AOK Software that demonstrates some of the potential impacts on the OSP application package with the following snap-shot image.

Patch Summary:

MS10-001 Vulnerability in the Embedded OpenType Font Engine Could Allow Remote Code Execution (972270)
MS10-001 Vulnerability in the Embedded OpenType Font Engine Could Allow Remote Code Execution (972270)

Testing Summary
  • MS10-001 : "Vulnerability in the Embedded OpenType Font Engine Could Allow Remote Code Execution (972270)"

Patch NameTotal
Microsoft Security Bulletin MS10-001N/A<1%YESCriticalGreen

No IssueNo Issues Detected
FixablePotentially fixable application Impact
SeriousSerious Compatibility Issue

Security Update Detailed Summary
MS10-001Vulnerability in the Embedded OpenType Font Engine Could Allow Remote Code Execution (972270)
DescriptionThis security update resolves a privately reported vulnerability in Microsoft Windows. The vulnerability could allow remote code execution if a user viewed content rendered in a specially crafted Embedded OpenType (EOT) font in client applications that can render EOT fonts, such as Microsoft Internet Explorer, Microsoft Office PowerPoint, or Microsoft Office Word. An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs, view, change, or delete data, or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.
PayloadFontsub.dll, T2embed.dll, Fontsub.dll, T2embed.dll, Fontsub.dll, T2embed.dll, Fontsub.dll, T2embed.dll

*All results are based on an AOK Application Compatibility Lab’s test portfolio of over 1,000 applications.