Microsoft March 2013 Black Tuesday Overview
Overview of the March 2013 Microsoft patches and their status.
| # | Affected | Contra Indications - KB | Known Exploits | Microsoft rating(**) | ISC rating(*) | |
|---|---|---|---|---|---|---|
| clients | servers | |||||
| MS13-021 |
The usual MSIE cumulative patch, adding fixes for eight more vulnerabilities. All 8 are of the "use after free" type and they all allow random code execution. Replaces MS13-009. |
|||||
|
MSIE CVE-2013-0087 CVE-2013-0088 CVE-2013-0089 CVE-2013-0090 CVE-2013-0091 CVE-2013-0092 CVE-2013-0093 CVE-2013-0094 CVE-2013-1288 |
KB 2809289 | CVE-2013-1288 was made public according to Microsoft. |
Severity:Critical Exploitability:1 |
Critical | Important | |
| MS13-022 |
A double dereference vulnerability that allows random code execution in Silverlight. This also affects the mac version of silverlight 5. The update is expected via the auto-update feature on Macs. Replaces MS12-034. |
|||||
|
Silverlight CVE-2013-0074 |
KB 2814124 | No publicly known exploits |
Severity:Critical Exploitability:1 |
Critical | Important | |
| MS13-023 |
A memory management vulnerability allow random code execution in the Visio viewer. The full package is exempt from this problem. Replaces MS12-059. |
|||||
|
Visio Viewer CVE-2013-0079 |
KB 2801261 | No publicly known exploits |
Severity:Critical Exploitability:2 |
Critical | Important | |
| MS13-024 |
Four different privilege escalation vulnerabilities in Sharepoint. Of note: it includes an XSS and a directory traversal vulnerability in addition to a problem with callback functions and a buffer overflow. Replaces MS12-066. |
|||||
|
Sharepoint CVE-2013-0080 CVE-2013-0083 CVE-2013-0084 CVE-2013-0085 |
KB 2780176 | No publicly known exploits. |
Severity:Critical Exploitability:1 |
N/A | Critical | |
| MS13-025 | A buffer management problem allows leaking arbitrary data in memory. It could expose usernames and passwords of accounts. | |||||
|
OneNote CVE-2013-0086 |
KB 2816264 | No publicly known exploits. |
Severity:Important Exploitability:3 |
Important | Less Urgent | |
| MS13-026 |
When previewing or opening an email that contain HTML5, outlook for Mac can load content from random webservers without user interaction. The note is quite confusing. E.g.: every mac capable of running the affected versions has a webkit browser installed together with the OS; Office for Mac 2008 did not have outlook - it had entourage instead; Outlook isn't part of all Office for Mac 2011 licenses either. Replaces MS12-076. |
|||||
|
Outlook for Mac CVE-2013-0095 |
KB 2813682 | No publicly known exploits |
Severity:Important Exploitability:3 |
Less Urgent | Less Urgent | |
| MS13-027 | 3 similar problems exist with the windows USB drivers that allow privilege escalation to full administrative rights. | |||||
|
USB Kernel Mode Drivers CVE-2013-1285 CVE-2013-1286 CVE-2013-1287 |
KB 2807986 | No publicly known exploits |
Severity:Important Exploitability:1 |
Important | Less Urgent | |
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
-
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.
--
Swa Frantzen -- Section 66
Adobe March 2013 Black Tueday
This month Adobe decided to fix four vulnerabilities in their Flash Player and AIR products for Black Tuesday:
APSB12-15 tells about the fixes for CVE-2013-0646 (integer overflow), CVE-2013-0650 (use after free), CVE-2013-1371 (memory corruption) and CVE-2013-1375(heap buffer overflow).
--
Swa Frantzen -- Section 66
IPv6 Focus Month: How to say no!
Oops, it's on!
Even if you could not care less about IPv6, there are quite serious security consequences to it being out there and to your devices having it. Even if you're not actively participating, you need to address the risk IPv6 poses in some environments.
IPv6 is equiped with the ability to connect with IPv4 networks - which sounds logical as before IPv6 is globally rolled out (if that ever happens), all globally accessible services (like "the web") are on the old IPv4 network. But even when you least expect it, IPv6 can open up tunnels through IPv4 networks and connect anyway - even where you have disabled the transition of IPv6 packets in perimeters and the like.
Now there are places you want no complications from having to deal with 2 concurrent IP stacks. Eg. an easy to audit high security setup (aka a donjon) that is not likely to run out of addresses is much easier if you can do it without added complications.
So what can we do ?
Host
At the host level we can try to tell it not to participate in IPv6, but it might be not all that easy. Beck when IPv6 started to become implemented some of us ripped out IPv6 support in our more critical machines' kernels. But even if you still succeed in that (it's not so easy anymore as in the early days), there is more and more you have to do as more and more of the system tools are IPv6 aware and will complain loudly if the kernel doesn't do IPv6 anymore.
There's a point where this doesn't pay off, anymore and obviously it's not something you can do in proprietary OSes anyway.
Many devices anlso simply cannot be configured not to do any IPv6 on their interfaces.
So your options on hosts are often limited. And it often lacks central control to enfoce it across all hosts you might have.
Network
The more intelligent your network is, the more likely you can write filters in it not to transmit IPv6 packets. This is still not your perimeter that blocks it, but it's you best approach to make sure machines do not start to talk IPv6 among themselves within your perimeter.
In larger networks one can e.g. use netflows to monitor for IPv6 traffic on the inside as well.
Perimeter / Firewall
Your firewall is essentially a router that filters traffic. Now most highend environments will have a default closed policy and as long as that policy is also applied to IPv6 you should be in the clear for traffic that passes through your perimeter.
But: how do you know it is in fact closed for IPv6 when you have e.g. a bit older software that only knows about IPv4. How can you be sure it's blocking IPv6 ?
The answer lies in detecting IPv6 traffic.
Similarly, if you policy isn't a fully closed policy, you need to work to make sure that IPv6 packets that disguise themselves as IPv4 do not leave your secured area as they would become accessible from the outside through tunnels they create themselves.
Monitoring
Your IDS/IPS and other monitoring might need to monitor for IPv6 use if you do not want it to be used.
Encapsulation
So that leaves us to try to enumerate how IPv6 can be embedded in IPv4.
-
If you look at the IPv4 protocol numbers (official list here), you'll notice there are a lot of them in there related to IPv6. Yes, IPv4 can be encapsulated next to ICMP (1) , TCP (4) and UDP (17) etc.
The most commonly known one is 41, but there are quite a few others, all relating to IPv6. -
In order to pass through out IPv4 NAT gateways (technically some will call it port address translation - as more often than not we're doing an N to 1 mapping) it's easier for those building a tunnel to encapsulate their IPv6 in a UDP packet.
So you need to know these too. I know of Teredo which is built into windows and enabled by default.
Teredo connects to UDP port 3544 by default. - Essentially nothing prevents a determined -or malicious if you're enforcing policies- entitiy on the inside of your perimeter to tunnel any protocol over any other allowed one - even if proxied, nothing changes there obviously. As soon as you allow communication there is a potential for those on the inside and outside to work together to build a tunnel - fact of live.
Well known endpoints
There are a number of well known endpoints for IPv6 tunnels.
- DNS request for isatap.MyCompany.com. indicate a ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) in action
- DNS request for teredo.ipv6.microsoft.com indicate Teredo in action.
- 192.88.99.* is used by 6to4
Those can be blocked and/or monitored. But again no guarantees exist no new tunneling mechanisms will be invented are existing be intentionally modified to escape anyway.
Papers
In a quick search I found this at vendors on how to block IPv6:
- http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/white_paper_c11-629391.html
- http://technet.microsoft.com/en-us/library/bb726956.aspx
Well, then it's off to you, our readers: feel free to comment on how you prevent IPv6, your experiences in getting out to the rest of IPv6 without a cooperating perimeter etc.
--
Swa Frantzen -- Section 66
Comments