My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Microsoft October 2012 Black Tuesday Update - Overview

Published: 2012-10-09. Last Updated: 2012-10-09 17:12:12 UTC
by Johannes Ullrich (Version: 1)
6 comment(s)

Overview of the October 2012 Microsoft patches and their status.

# Affected Contra Indications - KB Known Exploits Microsoft rating(**) ISC rating(*)
clients servers
MS12-064 Remote Code Execution Vulnerability in Microsoft Word
(ReplacesMS12-029 MS10-079 MS12-050 )
Word
CVE-2012-0182
CVE-2012-2528
KB 2742319 No. Severity:Critical
Exploitability: 1
Critical Important
MS12-065 Remote Code Execution Vulnerability in Microsoft Works
(ReplacesMS12-028 )
Works
CVE-2012-2550
KB 2754670 No. Severity:Important
Exploitability: 2
Critical N/A
MS12-066 Elevation of Privilege Vulnerability via XSS in HTML Sanitation Component
(ReplacesMS12-039 )
HTML Sanitation"
CVE-2012-2520
KB 2741517 Yes (limited). Severity:Important
Exploitability: 1
Important Important
MS12-067 Oracle outside/in and advanced filter pack for FAST Search Server Code Execution Vulnerabilities
 
FAST Search Server 2010 (SharePoint)
CVE-2012-1766
CVE-2012-1767
CVE-2012-1768
CVE-2012-1769
CVE-2012-1770
CVE-2012-1771
CVE-2012-1772
CVE-2012-1773
CVE-2012-3106
CVE-2012-3107
CVE-2012-3108
CVE-2012-3109
CVE-2012-3110
KB 2742321 Yes. Severity:Important
Exploitability: 1
Important Critical
MS12-068 Privilege Escalation in Windows Kernel
(ReplacesMS09-058 MS10-021 MS11-068 MS11-098 MS12-042 )
Kernel
CVE-2012-2529
KB 2724197 No. Severity:Important
Exploitability: 3
Important Important
MS12-069 Denial of Service Vulnerability in Kerberos
(ReplacesMS11-013 )
Word
CVE-2012-2551
KB 2743555 No. Severity:Important
Exploitability: 1
Important Important
MS12-070 Reflective XSS Vulnerability in SQL Server
(ReplacesMS09-062 MS11-049 )
Word
CVE-2012-0182
CVE-2012-2528
KB 2754849 No. Severity:Important
Exploitability: 1
N/A Important
We will update issues on this page for about a week or so as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
(*): ISC rating
  • We use 4 levels:
    • PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
    • Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
    • Important: Things where more testing and other measures can help.
    • Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
  • The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
  • The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-case role.
  • Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
  • All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them.

(**): The exploitability rating we show is the worst of them all due to the too large number of ratings Microsoft assigns to some of the patches.

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

6 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

Microsoft Security Advisory: Compatibility issues affecting signed Microsoft binaries:
http://support.microsoft.com/kb/2749655
Add that to the mix or do another diary post, as it makes your head spin a bit.
More here: http://blogs.technet.com/b/srd/archive/2012/10/09/security-advisory-2749655-and-timestamping.aspx
@Susan: apparently Microsoft forgot to include all aspects of Authenticode in their testing procedures.

Authenticode is Microsoft's way of digitally signing executable (exe, ocx, etc.) and other (such as cab) files. Optionally the digital signature is timestamped, and that's the issue here.

Quoting from http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc :

----------------------
Timestamps

Certificates normally expire after a period of time, such as one year. However, software is typically designed to operate for many years. If the certificate that was used to sign the code expires, the signature cannot be validated and the software might not install or run. To avoid this issue, Microsoft recommends that software publishers timestamp their digital signatures.

A timestamp is an assertion from a trusted source, called a timestamp authority (TSA), that the digital signature’s signed hash was in existence when the timestamp was issued. If the signing certificate was valid at that time, Windows considers the signature to be valid even if the certificate has since expired. If a signature is not timestamped, when the certificate used to sign the software expires, the signature simply becomes invalid.

Timestamps also play a role when checking for revoked certificates. If a digital signature was timestamped before the certificate was revoked, the signature remains valid. Timestamping thus allows a company to revoke a certificate and start signing with a new certificate without any risk of invalidating previously signed software applications.
----------------------

From ttp://blogs.technet.com/b/srd/archive/2012/10/09/security-advisory-2749655-and-timestamping.aspx :

"Unfortunately, due to a clerical error, a subset of binaries processed by the PRSS lab between June 12, 2012 and August 14, 2012 were digitally signed in an incorrect manner.

The signing error involved the timestamp placed on each file as it was being signed. The certificate used for timestamping was missing a critical attribute that will cause the digital signature to become invalid at the point in the future when the package’s signing key has expired."
In the chart MS12-69 & MS12-70 say "Word" in Affected Column.
This does not look to be correct. MS12-69 is Kerberos related and MS12-70 is SQL Server related.
Either I don't understand the Authenticode issue at hand, or Microsoft is still messing things up.

After conducting some research, I concluded that the Authenticode issue might be caused by a missing "Key usage" extension (marked critical) in the "Microsoft Time-Stamp Service" certificate valid from 2011-07-26 to 2012-10-25 with serial number "61 05 19 96 00 00 00 00 00 1b" (thumbprint "23 4c 7a ea 9c 8c 7e 8c 3f d2 db 39 31 8f a2 ac 99 a7 23 42"), which was used to timestamp recent updates.

Although this certificate has an "Enhanced Key Usage" extension, set to "Time Stamping (1.3.6.1.5.5.7.3.8)", this extension is not marked (tagged) critical. A generic "Key Usage" extension is missing, while none of the other extensions are marked critical.

I had a look at a "VeriSign Time Stamping Services CA" certificate used to timestamp recent Adobe Flash updates, with serial nr. "79 a2 a5 85 f9 d1 15 42 13 d9 b8 3e f6 b6 8d ed". In contrast, that certificate contains the following extensions marked critical:

- Basic Constraints (critical) = Subject Type=End Entity; Path Length Constraint=None
- Key Usage (critical) = Digital Signature (80)
- Enhanced Key Usage (critical) = Time Stamping (1.3.6.1.5.5.7.3.8)

Now I just downloaded "WindowsXP-KB2723135-v2-x86-ENU.exe" (updated MS12-053) and "WindowsXP-KB2723135-v2-x86-ENU.exe" (new MS12-068). Both have been timestamped with "Microsoft Time-Stamp PCA" certificate with serial number "61 02 92 4a 00 00 00 00 00 20" valid from 2012-01-10 upto 2013-04-10 (thumbprint "21 1c 1b a9 c4 31 57 d5 d0 42 93 e5 56 9d 51 f3 c2 40 ed c0").

What I don't understand is that this new certificate is mostly identical to the former Microsoft timestamping certificate; it also doesn't have any critical extensions, and the "Key Usage" extension is also missing!

Compared to the VeriSign cert above the only relevant extension is:

- Enhanced Key Usage (NOT critical) = Time Stamping (1.3.6.1.5.5.7.3.8)

So, either there was nothing wrong with the older Microsoft timestamping certificate (and I don't understand the problem), or Microsoft is just postponing the problem by using a timestamping certificate that expires in April, 2013 instead of this month.

What am I missing here?
Microsoft stated below that the bulletins below were released to reoffer the updates with the digital signature for multiple OS versions. However, upon scanning, it appears that systems with Windows XP or Windows Server 2003 are already showing compliant for the newly released update. Anyone else out there able to confirm?

Title: Microsoft Security Bulletin Re-Releases
Issued: October 9, 2012
********************************************************************

Summary
=======
The following bulletins have undergone a major revision increment.
Please see the appropriate bulletin for more details.

* MS12-043 - Critical
* MS12-053 - Critical
* MS12-054 - Critical
* MS12-055 - Important
* MS12-058 - Critical

Bulletin Information:
=====================

* MS12-043 - Critical

- http://technet.microsoft.com/security/bulletin/MS12-043
- Reason for Revision: V3.0 (October 9, 2012): Added Microsoft
XML Core Services 4.0 when installed on supported editions of
Windows 8 and Windows Server 2012 to affected software and
announced a corresponding detection change for the KB2721691
update package. Customers who have installed Microsoft XML
Core Services 4.0 on systems running Windows 8 or Windows
Server 2012 need to install the KB2721691 update to be
protected from the vulnerability described in this bulletin.
See the update FAQ for details.
- Originally posted: July 10, 2012
- Updated: October 9, 2012
- Bulletin Severity Rating: Critical
- Version: 3.0

* MS12-053 - Critical

- http://technet.microsoft.com/security/bulletin/MS12-053
- Reason for Revision: V2.0 (October 9, 2012): Revised bulletin
to offer the rerelease of the KB723135 update for Windows XP.
Customers need to apply the rereleased update packages to
avoid an issue with digital certificates described in
Microsoft Security Advisory 2749655.
- Originally posted: August 14, 2012
- Updated: October 9, 2012
- Bulletin Severity Rating: Critical
- Version: 2.0

* MS12-054 - Critical

- http://technet.microsoft.com/security/bulletin/MS12-054
- Reason for Revision: V2.0 (October 9, 2012): Revised
bulletin to offer the rerelease of the KB2705219 update
for Windows XP, Windows Server 2003, Windows Vista, Windows
Server 2008, Windows 7, and Windows Server 2008 R2. Customers
need to apply the rereleased update packages to avoid an issue
with digital certificates described in Microsoft Security
Advisory 2749655.
- Originally posted: August 14, 2012
- Updated: October 9, 2012
- Bulletin Severity Rating: Critical
- Version: 2.0

* MS12-055 - Important

- http://technet.microsoft.com/security/bulletin/MS12-055
- Reason for Revision: V2.0 (October 9, 2012): Revised
bulletin to offer the rerelease of the KB2731847 update
for Windows XP, Windows Server 2003, Windows Vista, Windows
Server 2008, Windows 7, and Windows Server 2008 R2. Customers
need to apply the rereleased update packages to avoid an
issue with digital certificates described in Microsoft
Security Advisory 2749655.
- Originally posted: August 14, 2012
- Updated: October 9, 2012
- Bulletin Severity Rating: Important
- Version: 2.0

* MS12-058 - Critical

- http://technet.microsoft.com/security/bulletin/MS12-058
- Reason for Revision: V2.0 (October 9, 2012): Revised bulletin
to offer the rerelease of updates for Microsoft Exchange Server
2007 Service Pack 3 (KB2756496), Microsoft Exchange Server 2010
Service Pack 1 (KB2756497), and Microsoft Exchange Server 2010
Service Pack 2 (KB2756485). Customers need to apply the
rereleased updates to avoid an issue with digital certificates
described in Microsoft Security Advisory 2749655.
- Originally posted: August 14, 2012
- Updated: October 9, 2012
- Bulletin Severity Rating: Critical
- Version: 2.0
Meanwhile I've found what was wrong with the timestamping certificates Microsoft used.

From the FAQ in https://technet.microsoft.com/en-us/security/advisory/2749655 :
-------------------------------------
What causes this issue?
This issue is caused by a missing timestamp Enhanced Key Usage (EKU) extension during certificate generation and signing of Microsoft core components and software. Some certificates used for two months of 2012 did not contain an X.509 timestamp Enhanced Key Usage (EKU) extension.
-------------------------------------

Apparently 2 certificates are involved. From http://blogs.technet.com/b/srd/archive/2012/10/09/security-advisory-2749655-and-timestamping.aspx :
-------------------------------------
In addition to re-signing and re-distributing the affected files, we are taking an unusual approach to address this issue at the platform layer. The Windows team has created a package with a modified WinVerifyTrust function that makes a special case of the _two_ known timestamping certificates that were missing the critical attribute. This will enable WinVerifyTrust to continue trusting these files and packages while redistribution completes.
-------------------------------------
See https://technet.microsoft.com/en-us/security/advisory/2749655 for a description of this (kind of scary) patch.

I still don't understand why Microsoft does not follow best practices by including the following extensions -and tagging them critical- in their (timestamping) certificates, just like VeriSign does:
- Basic Constraints (critical) = Subject Type=End Entity; Path Length Constraint=None
- Key Usage (critical) = Digital Signature (80)
- Enhanced Key Usage (critical) = Time Stamping (1.3.6.1.5.5.7.3.8)

Apparently Microsoft does not learn from errors made in the past. Last June Microsoft revoked 3 certificates because Flame could abuse them for other purposes than they were intended for, just because their usage was not restricted by including extensions tagged critical (see https://blogs.technet.com/b/srd/archive/2012/06/03/microsoft-certification-authority-signing-certificates-added-to-the-untrusted-certificate-store.aspx ).

@Matt: I can confirm that none of the older updates you mention are being re-offered on my XP computer. Neither by automatic updates, nor by visiting https://www.update.microsoft.com/

Diary Archives