June 2007, Microsoft Patch Tuesday Overview.
Overview of the June 2007 Microsoft patches and their status.
| # | Affected | Contra Indications | Known Exploits | Microsoft rating | ISC rating(*) | |
|---|---|---|---|---|---|---|
| clients | servers | |||||
| MS07-030 | Vulnerabilities in Microsoft Visio Could Allow Remote Code Execution. | |||||
| Visio 2002 Visio 2003 CVE-2007-0934 CVE-2007-0936 |
KB 927051 | No known exploits | Important | Critical | Important | |
| MS07-031 | Vulnerability in Schannel Could Allow Remote Code Execution | |||||
| Windows 2000 Windows XP Windows Server 2003 CVE-2007-2218 |
KB 935840 | Exploit (PoC) | Critical | Critical | Critical | |
| MS07-032 | Vulnerability in Windows Vista Could Allow Information Disclosure | |||||
| Windows Vista CVE-2007-2229 |
KB 931213 | No known exploits | Moderate | Less Urgent | Less Urgent | |
| MS07-033 | Cumulative Security Update for Internet Explorer | |||||
| Internet Explorer CVE-2007-0218 CVE-2007-1750 CVE-2007-1751 CVE-2007-1752 CVE-2007-2222 CVE-2007-3027 |
KB 933566 | Exploit | Critical | Critical | Important | |
| MS07-034 | Cumulative Security Update for Outlook Express and Windows Mail | |||||
| Outlook Express (XP, 2003) Windows Mail (Vista) CVE-2007-2111 CVE-2007-1658 CVE-2007-2225 CVE-2007-2227 |
KB 929123 | No known exploits | Critical | Critical | Important | |
| MS07-035 | Vulnerability in Win32 API Could Allow Remote Code Execution | |||||
| Windows 2000 Windows XP Windows Server 2003 CVE-2007-2219 |
KB 935839 | No known exploits | Critical | Critical | Critical | |
We will update issues on this page as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
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.
Keywords: mspatchday
0 comment(s)
Beta Software (Safari for Windows)
We got an unusual number of e-mails regarding the vulnerabilities in yesterday's release of Safari for Windows. I was a bit hesitant to cover it in a diary. After all, its beta software. We all know better then to use beta software in production. So operational impact of these issues should be nil.
Now... on the other hand, I own two Apple computers. So I know the power of the brushed-metal kool-aid. So lets talk about beta software in general. You got a sales guy in jeans and a black turtle neck, or a monkey running across a banner ad, telling you about the latest and greatest version of product "X". "Now with even more of must have 'Y'".
So how do you resist? I found its usually impossible. However, you can minimize the impact. Keep a "beta" machine around. Use it to install all the free trials, latest beta versions and other junk. The machine will soon become too unstable to use, making the desire for even more free-trial-super-feature-enhanced software vane quickly.
In very few cases you may want to use a beta product or a version downloaded and compiled from CVS. But these cases should be limited and strictly controlled. A couple of check points for approving a beta solution:
* Do we actually need the software?
* Is there a workaround that will make the "release" version workable?
* Is there a competing product that will do the job?
* Whats the track record of the vendor (will they always point to the next version thats just about to be released).
* How can we test if this beta software actually does what it promises?
Similar rules should be applied to any version upgraded or new software, even if its a "release". Sometimes, its better to stick with an older version for a while. At least you know how to work its bugs.
oh. and I am still typing this diary on my 3+ year old Linux system. Its the system I use to actually get work done.
Now... on the other hand, I own two Apple computers. So I know the power of the brushed-metal kool-aid. So lets talk about beta software in general. You got a sales guy in jeans and a black turtle neck, or a monkey running across a banner ad, telling you about the latest and greatest version of product "X". "Now with even more of must have 'Y'".
So how do you resist? I found its usually impossible. However, you can minimize the impact. Keep a "beta" machine around. Use it to install all the free trials, latest beta versions and other junk. The machine will soon become too unstable to use, making the desire for even more free-trial-super-feature-enhanced software vane quickly.
In very few cases you may want to use a beta product or a version downloaded and compiled from CVS. But these cases should be limited and strictly controlled. A couple of check points for approving a beta solution:
* Do we actually need the software?
* Is there a workaround that will make the "release" version workable?
* Is there a competing product that will do the job?
* Whats the track record of the vendor (will they always point to the next version thats just about to be released).
* How can we test if this beta software actually does what it promises?
Similar rules should be applied to any version upgraded or new software, even if its a "release". Sometimes, its better to stick with an older version for a while. At least you know how to work its bugs.
oh. and I am still typing this diary on my 3+ year old Linux system. Its the system I use to actually get work done.
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
Comments