Threat Level: green Handler on Duty: Manuel Pelaez

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

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)

Cyber Security Awreness Month - Day 9 - Request for Comment (RFC)

Published: 2012-10-09
Last Updated: 2012-10-09 13:52:30 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

The Internet Engineering Task Force (IETF) is the main standard body for Internet related protocols. As far as standard bodies go, the IETF is probably the most open. Standards are discussed on mailing lists, and all you need to do is sign up for a mailing list and chime in, or attend one of the IETF meetings or both. There is no "membership" and standards usually require aconsensus. 

The RFC Process

RFCs are not only published by the IETF, but the Internet Architecture Board (IAB) and Internet Engineering Steering Group (IESG).  Not all RFCs are "standards". Some just document best practices or just informational (for example RFC1796: "Not all RFCs are Standards"). There are three distinct sub-series: Standards (STD), Best Current Practice (BCP) and Informational (FYI).

The RFC process itself is regulated by RFCs. RFCs start out as Internet Drafts. These drafts have a limited lifetime (default is 6 months) and are discarded unless they are selected to become an RFC by the IESG. 

Once an RFC is published, it's content can no longer be changed. Once in a while you will see erratas that are added to RFCs. But for the most part, to update an RFC, a new RFC needs to be published. When researching RFCs, it is VERY important to make sure it hasn't been updated by a newer RFC (I prefer the listing at http://tools.ietf.org/html/ as it links to updates)

There is no enforcement of RFCs, other then peer pressure. For the most part, if you want stuff to work, you better follow RFCs. Until about a week ago, one of the expressions of the peer pressure aspect of the RFC system was rfc-ignorant.org .  The site listed networks that choose not to obey some RFCs, in particular related to spam and abuse reporting. 

RFCs and Security

All RFCs should have a security sections. It will summarize any security impact the particular RFC may have. In addition, there are a good number of RFCs that deal with security issues.  I recommend taking a look at new RFCs regularly. Internet standards are very dynamic and assumptions you make based on old standards can be dangerous, or you are not taking advantage of some of the newer features.

IETF also publishes a list of security related RFCs here: http://www.apps.ietf.org/rfc/seclist.html

 

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

0 comment(s)
ISC StormCast for Tuesday, October 9th 2012 http://isc.sans.edu/podcastdetail.html?id=2857
Diary Archives