SCUP Issues and Non-Security Update KB2661254

Note:  All information in this posting was obtained in a self-contained lab and should be taken as-is.  Any changes to live Microsoft SCUP/WSUS/SCCM environments should be carefully reviewed, and each change should be tested before attempted in your live environment.

Overview of Digital Certificate Changes By Microsoft
I have tested and documented the changes Microsoft has been making regarding security and digital certificates.  You can review my blog posting on the saga here.  With all patches, it is extremely important to test patches to ensure functionality is not broken with the fixes contained.  I have done some internal testing with Microsoft’s System Center Updates Publisher (SCUP) and found this non-security update (KB2661254) could have major impacts with the program.

Timing
Research of this non-security update and subsequent changes should be on your radar this month.  Microsoft released the non-security patch during the August 2012 Patch Tuesday.  This patch is only available through the Microsoft Download Center and is not available through Windows Update or WSUS at this time.  Other vendor solutions such as VMware vCenter Protect offers this update or will be offering this update shortly through a distribution method.  Microsoft is planning to release this non-security update to both Windows Update and WSUS during the October 2012 Patch Tuesday.  With those dates in mind, you will want to address this issue or plan on delaying the release of this patch to your network until your systems are ready to accept the update.  It is important to note that this Microsoft Security Advisory has no reported active attacks against digital certificates that require immediate action in regards to vulnerability management.

SCUP/WSUS/SCCM Issues with Non-Security Update KB2661254
With Microsoft System Center Updates Publisher (SCUP), you could run into issues if you deploy the patch before testing and potentially making changes to your setup.

With SCUP, administrators are required to create a digital certificate used for signing third-party updates.  Microsoft’s WSUS (the program that SCUP publishes updates to) can recognize and accept Microsoft digitally signed patches.  But, your WSUS/SCCM/SCUP systems will need a certificate so WSUS will accept updates signed by third-party vendors.

There are two SCUP versions most people use:  version 4.5 released in December 2008 by Microsoft; version 2011 released by Microsoft in May 2011.

Scenarios:
1)  If you install SCUP 4.5 or earlier and you created a certificate with the SCUP program, the certificate is 512 bits in length.  This certificate is no longer valid and not accepted if you install the non-security update.

2)  If you install SCUP 2011, non-security update KB2530678 is applied during the installation and you created a certificate with the SCUP program, the certificate is 2048 bits in length.  This certificate is still valid and no changes are necessary if the non-security update is installed.

3)  If you install SCUP 2011, you do not install the suggested non-security update KB2530678 and you created a certificate with the SCUP program, the certificate is 512 bits in length.  This certificate is no longer valid and not accepted if you install the non-security update.

4)  If you installed SCUP 4.5 or earlier and you created a certificate with the SCUP 4.5 program; an administrator upgrades the system to SCUP 2011 at a later time, the certificate created with 4.5 (512 bits in length) is used by default with SCUP2011.  This certificate is no longer valid and not accepted if you install the non-security update.  Note:  By default, SCUP 4.5 and 2011 can be installed side-by-side.

Non-security update KB2530678 and SCUP 2011
During the installation of SCUP 2011, you will be informed that a non-security update for WSUS should be applied.  It is possible to skip this screen and bypass the installation of the non-security update.  The following screenshot shows the portion of the 2011 installation prompting for the non-security update.

 

How to determine if non-security update KB2530678 is installed
Under “Programs and Features”, you can view what updates are installed on your system.  For the non-security update needed for the 2048 bit certificate fix, the patch does not display the KB number.  The following screenshot shows the information displayed for the non-security update.

The non-security update fixes an issue where SCUP will not publish updates on systems have WSUS 3.0 SP2 and the .NET Framework are installed.  This patch is not fully documented though.  The knowledge base article for the non-security update does not state the fix for digital certificates.

What certificate is being used by System Center Updates Publisher / WSUS:
The most important piece of information needed for all administrators using SCUP is to know what certificate is being used by SCUP/WSUS/SCCM.  These actions should be taken on your SCUP, WSUS and SCCM server.  If you have these programs installed on multiple servers, the actions listed in this posting should be performed on all servers.

First, open up the System Center Updates Publisher program and navigate to the options section.  Under the “Update Server” tab, take note the name of the certificate under “Signing Certificate.”  Using the Microsoft Management Console (MMC), add the snap-in for Certificate marking the “Computer Account” as the store that you want to view.  Under the WSUS certificate tree you will see your certificate.  The following two screen shots show a System Center Updates Publisher 4.5 and 2011 installation and the certificate being used for signing updates.

The certificate created and installed using System Center Updates Publisher 4.5 / 512 bits in length.

The certificate created and installed using System Center Updates Publisher 2011 / 2048 bits in length.

In order for a workstation to allow a patch to be installed with a non-Microsoft certificate from SCUP/WSUS/SCCM, administrators needed to apply the certificate to their client systems.  This certificate is located under the Trust Root Certification Authorities and is the same certificate we were investigating in the previous step.  The following screenshot shows the certificate installed on my client systems.  This can be found the same was as earlier stated, except you will select the Trust Root Certification Authorities.

The certificate used on a client system / 512 bits in length.  This system has the non-security update already applied.  The certificate is invalid on the first certificate screen.

 

Impact of a digital certificate 512 bits in length, System Center Updates Publisher and non-security update KB2661254

Client Side Impacts
For this test, I installed an older version of the Opera Internet Browser and used VMware vCenter Protect Update Catalog data file to patch Opera.  This client system has the non-security update deployed to it.  After deploying the patch, SCCM is reporting an error during the installation as shown in the following screen shot.

The patch has failed to install due to a file that is signed with a digital certificate less than 1024 bits in length and the non-security update has been installed on the client system.

You will also see errors in a couple of logs on the target system:

WUAHandler.log:
<![LOG[1. Update: 8fefa3ee-5d35-44c8-90d7-0366737f28aa, 2   BundledUpdates: 0]LOG]!><time=”13:22:03.263+300″ date=”08-17-2012″ component=”WUAHandler” context=”” type=”1″ thread=”2596″ file=”cwuahandler.cpp:1389″>
<![LOG[1. Update (Missing): Opera 12.01 (8fefa3ee-5d35-44c8-90d7-0366737f28aa, 2)]LOG]!><time=”13:22:03.263+300″ date=”08-17-2012″ component=”WUAHandler” context=”” type=”1″ thread=”2596″ file=”cwuahandler.cpp:1511″>
<![LOG[Failed to download updates to the WUAgent datastore. Error = 0x80096004.]LOG]!><time=”13:22:03.373+300″ date=”08-17-2012″ component=”WUAHandler” context=”” type=”3″ thread=”2596″ file=”cwuahandler.cpp:503″>

WindowsUpdate.log
2012-08-17                     13:22:03:279                 680              430               DnldMgr   ***********  DnldMgr: Copy update to cache [UpdateId = {8FEFA3EE-5D35-44C8-90D7-0366737F28AA}.2]  ***********
2012-08-17                     13:22:03:326                 680              430               Misc             Validating signature for C:WINDOWSSoftwareDistributionDownload83543e81a225aa67b60a1574a14515b1eeb0158:
2012-08-17                     13:22:03:373                 680              430               Misc             WARNING: Error: 0x80096004 when verifying trust for C:WINDOWSSoftwareDistributionDownload83543e81a225aa67b60a1574a14515b1eeb0158
2012-08-17                     13:22:03:373                 680              430               Misc             WARNING: Digital Signatures on file C:WINDOWSSoftwareDistributionDownload83543e81a225aa67b60a1574a14515b1eeb0158 are not trusted: Error 0x80096004
2012-08-17                     13:22:03:373                 680              430               DnldMgr     * WARNING: Copy update to cache failed with exit code = 0x80096004
 

 

Fixing the digital certificate 512 bits in length and SCUP
First, we are going to need to get a new certificate to use for System Center Updates Publisher.  For administrators that set up their SCUP/WSUS/SCCM environments, they have gone through these steps already.

Verify the digital certificate that is being used for your SCUP/WSUS/SCCM environment.  Earlier in the blog, I outlined the sets to identify the certificate used.

**Please note:  You should backup your current digital certificate before making any changes to your system.  You can do this through the certificates snap-in and choosing export on the certificate.

 

Create a new digital certificate to use for the SCUP/WSUS/SCCM environment and client systems
Navigate to your Local Computer Certificates store on the SCUP/WSUS/SCCM system.  The digital certificate used (if SCUP/WSUS/SCCM are installed on the same machine) will be stored in three locations.  After backing up the current digital certificate, navigate to the WSUS, Trusted Publishers and Trusted Root Certification Authorities containers and remove the certificate identified in the previous steps.

Close the System Center Updates Publisher program and reopen the program.  Navigate to the Options page and you will now see there is no digital certificate assigned to the program.

For System Center Updates Publisher 2011 (clean 2011 installation and 2011 upgraded from 4.5):  You can create the digital certificate from the Options screen.  The screenshot below shows the new certificate being installed (and the name associated with it).

For System Center Updates Publisher 4.5:  This program, by default, will create a certificate that is 512 bits in length.  You will need to create or obtain a digital certificate by other methods other than the System Center Updates Publisher.  Jason Lewis from Microsoft has an excellent blog posting showing how to accomplish this task.  You can find it here.

After creating the certificate, you can now see the certificate is now greater than 1024 bit in length.  On the SCUP/WSUS/SCCM machine, you will need to place the certificate in the Trusted Publishers and Trusted Root Certification Authorities containers.

Next, you will need to assign this new digital certificate to the client systems.  In my environment, I am using Group Policy to apply certificates to my client systems.  In the Group Policy, I removed the previous certificate and placed the new certificate.

With the new digital certificate in place on the SCUP/WSUS/SCCM server(s) and the client systems, future updates should be applied with no issues.

 

Server Side Impacts
Installing the non-security update on a server with SCUP/WSUS/SCCM can present issues with digital certificates that are 512 bits in length.  For this scenario, I applied the non-security update to my SCUP/WSUS/SCCM server.  I then attempted to publish the latest version of Opera from SCUP to WSUS.  With the non-security update and a certificate 512 bits in length installed, an error will occur during the publish.  The following screenshots show the error you will receive.

You will also see the following errors in the UpdatePublisher.log file on the SCUP/WSUS/SCCM server.

SCUP 2011 UpdatesPublisher.log:
2012-08-22 20:49:03.345 UTC  Info               Scup2011.6                     CabUtilities.CheckCertificateSignature       File cert verification failed for c:Program FilesUpdate Servicesautest.cab with 2147942402$$<Updates Publisher><Wed Aug 22 13:49:3.345 2012.6><thread=6>
2012-08-22 20:49:03.346 UTC  Info               Scup2011.6                     WsusTestKeys.AreTestKeysAllowed                  Server test key check: test keys are NOT allowed$$<Updates Publisher><Wed Aug 22 13:49:3.346 2012.6><thread=6>
2012-08-22 20:49:04.533 UTC  Info               Scup2011.6                     CabUtilities.CheckCertificateSignature       File cert verification failed for JMWIN2008SP2X86UpdateServicesPackages8fefa3ee-5d35-44c8-90d7-0366737f28aaadb78be9-926d-4eb7-bd1e-1260917f93f8_1.cab with 2148098052$$<Updates Publisher><Wed Aug 22 13:49:4.533 2012.6><thread=6>
2012-08-22 20:49:04.646 UTC  Error             Scup2011.6                     Publisher.VerifyAndPublishPackage             VerifyAndPublishPackage(): Failed to Verify Signature for file: JMWIN2008SP2X86UpdateServicesPackages8fefa3ee-5d35-44c8-90d7-0366737f28aaadb78be9-926d-4eb7-bd1e-1260917f93f8_1.cab
<…section removed to conserve blog space…>
2012-08-22 20:49:04.647 UTC  Error             Scup2011.6                     Publisher.PublishPackage             PublishPackage(): Operation Failed with Error: Verification of file signature failed for file: JMWIN2008SP2X86UpdateServicesPackages8fefa3ee-5d35-44c8-90d7-0366737f28aaadb78be9-926d-4eb7-bd1e-1260917f93f8_1.cab
<…section removed to conserve blog space…>
PublishItem: InvalidException occurred during publishing: Verification of file signature failed for file: JMWIN2008SP2X86UpdateServicesPackages8fefa3ee-5d35-44c8-90d7-0366737f28aaadb78be9-926d-4eb7-bd1e-1260917f93f8_1.cab$$<Updates Publisher><Wed Aug 22 13:49:4.685 2012.6><thread=6>
Publish: A fatal error occurred during publishing :Signature verification exception during publish, verify the WSUS certificates and advanced timestamp setting are properly configured.$$<Updates Publisher><Wed Aug 22 13:49:4.688 2012.6><thread=6>

SCUP 4.5 UpdatesPublisher.log:
Download Content : Catalogs cab file was downloaded successfully .$$<Updates Publisher><Wed Aug 22 14:6:14.281 2012. ><thread=6>
Publish:  : Downloaded content for update ‘8fefa3ee-5d35-44c8-90d7-0366737f28aa’ to local file: C:UsersAdministratorAppDataLocalTemp1ujmcfghj.up4Opera_1201_en_Setup.exe$$<Updates Publisher><Wed Aug 22 14:6:14.281 2012. ><thread=6>
Publish:  : —Using default return codes for update…$$<Updates Publisher><Wed Aug 22 14:6:15.671 2012. ><thread=6>
Publish:  : — Calling update server API for update ‘8fefa3ee-5d35-44c8-90d7-0366737f28aa’$$<Updates Publisher><Wed Aug 22 14:6:15.687 2012. ><thread=6>
Publish:  : — Calling update server API for publishing update ‘8fefa3ee-5d35-44c8-90d7-0366737f28aa’$$<Updates Publisher><Wed Aug 22 14:6:15.796 2012. ><thread=6>
Publish:  : Exception occured during publishing: Verification of file signature failed for file: JMWIN2008SP2X86UpdateServicesPackages8fefa3ee-5d35-44c8-90d7-0366737f28aaadb78be9-926d-4eb7-bd1e-1260917f93f8_1.cab$$<Updates Publisher><Wed Aug 22 14:6:31.687 2012. ><thread=6>

 

Other Ramifications with Certificates
There is also one very important step for SCUP/WSUS/SCCM environments that needs to be addressed if a new certificate is being used.  All updates that have been previously published from SCUP to WSUS/SCCM are signed with the previous digital signature (512 bit certificate).  The client systems will now accept any updates that are signed with the new digital certificates, but all of my older updates are still signed with the previous digital signature.  In this scenario, the updates will fail to deploy on the client systems as the client does not recognize the digital certificate.

In the following screenshot, you can see the Opera update we have been testing is still signed with the previous (512 bit) digital signature.


For any update that you have published through SCUP to WSUS/SCCM, you will need to re-sign the update.  Under the publish options in SCUP (2011), you will need to publish a “Full Content” update with the “Sign all software updates with a new publishing certificate…” checked.  Once this setting is checked and a “Full Content” push is done, System Center Updates Publisher will download the patch again, cab the file and sign the cab with the new digital signature.  The screenshot below shows the options that must be enabled for re-publishing updates with the new digital signature.


For System Center Update Publisher 4.5, the setting is changed globally for all updates.  Under the “Settings > Advanced” tab, the checkbox “Prompt for re-signing updates while publishing” must be selected.  The screenshot below shows the global feature that must be enabled for re-publishing updates with new digital signatures.


After completing a Full Content push of my latest Opera patch with the resigning option selected, the patch is now valid.  The screenshot below shows a re-signed update from the Opera test.  The digital signature is now 2048 bits in length.


The process up to this point does not take a lot of time to complete.  There are some important notes to consider before applying this change:

1)       All previous updates will need to be updated with a new digital certificate.  Any previous updates will fail to deploy with the previous digital certificate.  If you have a massive amount of patches you deploy to your network, the resigning process will take quite an undertaking.  For example, the VMware vCenter Protect Update Catalog data feed for System Center Updates Publisher has over 700 updates spanning 71 different products.  Resigning all updates or just the latest updates for the products in this data feed will take quite a bit of time before they can be used.

2)      All previous Deployment Management packages will need to be recreated.  In the two previous screenshots, you can that resigning updates will create a new package for the newly created package (WSUS share location).

 

Deploying Updates after Changes
After all of the changes to digital signatures, I attempted to deploy an update to an outdated Opera browser.  I first deleted my previous Deployment Management package that contained the old version of the digital signature.  After creating a new Deployment Management package, I deployed the update and it was successful as shown in the next screen shot.

 

Recap
Before applying any patches to your systems, it is good practice to test the patch on test machines.  In some SCUP/WSUS/SCCM environments, one simple non-security patch could cause major headaches.  If you are a SCUP user, you still have a couple of weeks to come up with a game plan on how to accept and deploy Microsoft’s new non-security update.

 

– Jason Miller

 

New Adobe Security Bulletin Released

Adobe has just released details of a new security bulletin.  Adobe security bulletin APSB12-19 addresses six vulnerabilities and is rated Critical.  There is no indication from Adobe that the vulnerabilities fixed in this release have any attacks against them.

This is a quick turnaround from Adobe for a security release for their Flash Player.  Last Tuesday, Adobe released security bulletin APSB12-18 fixing a zero-day vulnerability in Adobe Flash Player 11.

New Versions Available:

  • Adobe Flash Player 11.4.402.265
  • Adobe Flash Player 10.3.183.23
  • Adobe Air 3.4.0.2540

With any Adobe Flash Player security bulletin release, Google releases a new version of their Chrome browser.  This browser includes the latest version of Adobe Flash Player included.

New Versions Available:

  • Google Chrome 21.0.1180.83
  • Google Chrome Frame 21.0.1180.83

The remaining fixes in the Google Chrome and Google Chrome Frame browser contain non-security updates.  More information on the Google release can be found here.

 

– Jason Miller

August 2012 Patch Tuesday Overview

Marking the August 2012 edition of Patch Tuesday, Microsoft has released nine bulletins addressing 27 vulnerabilities.

Last month Microsoft released a Security Bulletin (MS12-043) addressing a Zero-Day vulnerability in the Microsoft XML Core Services.  With the Security Bulletin release, Microsoft addressed the vulnerability in MS XML Core Services 3.0, 4.0 and 6.0.  Microsoft did not release the patches for MS XML Core Services version 5.0 until this month.  As you go through your patching cycle, it is important to remember to apply the patches for this additional (10th) bulletin that is left over from last month.

Microsoft also released a non-security update in part of their work on hardening digital certificates on Windows operating systems.  Non-security update KB2661254 will block any digital certificates that are not 1024 bits in length.  As this non-security update is a defense-in-depth update and there are no known active attacks related to the patch, administrators should concentrate on the Security Bulletin releases first this month.  Although unlikely, there is a potential that this non-security update could break functionality on systems if not thoroughly tested first.  At this time, this non-security update is only available on the Microsoft Download Center.

There are two bulletins administrators should look at applying right away to prevent malicious webpages from exploiting their systems.  MS12-052 affects all supported versions of the Microsoft Internet Explorer browser.  This is the third straight month we have seen some type of Security Bulletin released for Microsoft’s browser.

When patching your Internet Explorer browsers this month, administrators will need to apply two patches to fully mitigate the risk of an attack.  If Internet Explorer version 8 is installed, administrators will need to apply the Internet Explorer Cumulative Update (MS12-052) and Security Bulletin MS12-056.  MS12-056 fixes a vulnerability in JScript that could lead to Remote Code Execution.

Windows Remote Desktop is appearing once again with a critical Security Bulletin.  Similar to previous Microsoft Security Bulletins affecting RDP, an attacker can gain access to the system by sending an unauthenticated, malicious RDP packet to a Windows XP SP3 system with RDP enabled.  As I said earlier this year, RDP is commonly used and turned on by administrators to remotely control their systems.

One Security Bulletin this month addresses a vulnerability that has seen targeted, limited attacks.  MS12-060 addresses a vulnerability in Windows Common Controls that could lead to Remote Execution.  If a user opens a malicious RTF document on an upatched system, an attacker can gain complete access to the system.  RTF documents as attachments are common.  In addition, most email security software do not block these types of attachments due to how commonly they are used.

The last Microsoft Security Bulletin administrators should pay particular attention to this month is MS12-054.  This Security Bulletin addresses multiple vulnerabilities in the Windows Networking Components.  If an attacker is able to share a resource with a malicious name on a network, the attacker can gain control of other systems with an unauthenticated response to the machine.  An example of this is any resource, such as a shared printer, that machines will attempt to find on a network.

Adobe has also joined this edition of Patch Tuesday with their own Security Bulletin releases for their Acrobat, Reader, Flash and Shockwave programs.  Adobe Security Bulletin APSB12-16, affecting Adobe Acrobat and Reader, addresses 20 Critical vulnerabilities.  Adobe Security Bulletin APSB12-17, affecting Adobe Shockwave Player, addresses 5 Critical vulnerabilities.  Adobe Security Bulletin APSB12-18, affecting Adobe Flash Player, addresses 1 Critical vulnerability.  This vulnerability has seen limited attacks in the wild.

With every Adobe Security Bulletin release, Google also releases updates for their Google Chrome and Chrome Frame browsers.  A new update released today by Google includes the latest version of Flash with their installation.

As with any Patch Tuesday, it is important to keep an eye on any other non-Microsoft vendor releasing Security Bulletins.

I will be going over the August Patch Tuesday in detail in addition to any other non-Microsoft releases since the last Patch Tuesday in our Monthly Patch Tuesday webinar. In addition, I will be spending some time discussing the Flame virus situation. This webinar is scheduled for next Wednesday, August 15th at 11:00am CT. You can register for this webinar here.

– Jason Miller

August 2012 Patch Tuesday Advanced Notification

Today marks the day Microsoft announces their Advanced Notification for the August 2012 edition of Patch Tuesday.  Microsoft is planning to release 9 bulletins.

Security Bulletin Breakdown:

  • 5 bulletins are rated as Critical
  • 4 bulletins are rated as Important
  • 8 bulletins addressing vulnerabilities that could lead to Remote Code Execution
  • 1 bulletin addressing vulnerabilities that could lead to Elevation of Privilege

 

Affected Products:

  • All supported versions of Internet Explorer
  • All supported versions of Microsoft Operating Systems
  • Microsoft Office 2003, 2007, 2010
  • Microsoft Visio 2010
  • Microsoft Office 2003 Web Components
  • Microsoft Visio Viewer 2010
  • Microsoft SQL Server 2000, 2005, 2008, 2008 R2
  • Microsoft Commerce Server 2002, 2007, 2009, 2009 R2
  • Microsoft Host Integration Server 2004
  • Microsoft Exchange Server 2007, 2010
  • Microsoft Visual FoxPro 8, 9
  • Microsoft Visual Basic 6.0 Runtime

 

In addition to Microsoft, this Patch Tuesday marks Adobe’s Quarterly update for Adobe Reader and Acrobat.  Adobe released Security Advisory APSB12-16.  This bulletin is rated as Critical and will be released during the August 2012 Patch Tuesday.

The following Adobe products will be patched:

  • Adobe Reader 10.1.3
  • Adobe Reader 9.5.1
  • Adobe Acrobat 10.1.3
  • Adobe Acrobat 9.5.1

 

I will be going over the August Patch Tuesday in detail in addition to any other non-Microsoft releases since the last Patch Tuesday in our Monthly Patch Tuesday webinar.  In addition, I will be spending some time discussing the Flame virus situation.  This webinar is scheduled for next Wednesday, August 15th at 11:00am CT.  You can register for this webinar here.

 – Jason Miller