evilrouters.net

Yesterday, December 15th, Adobe posted APSA09-07, “Security Advisory for Adobe Reader and Acrobat”, which is summarized as follows:

Adobe has confirmed a critical vulnerability in Adobe Reader and Acrobat 9.2 and earlier versions that could cause a crash and potentially allow an attacker to take control of the affected system. There are reports that this vulnerability is being actively exploited in the wild. Adobe recommends customers follow the mitigation guidance below until a patch is available.

Furthermore, Adobe mentioned that they plan to release an update by January 12, 2010. That’s 28 days — a LONG time for a security vulnerability that is being actively exploited in the wild. Fortunately, there appears to be a simple way to mitigate this vulnerability: disable JavaScript.

For individual users or those not on a corporate network, the easiest way is to simply do the following:

• Launch Adobe Acrobat or Adobe Reader
• Select Edit, then Preferences
• Select the JavaScript category
• Uncheck the “Enable Acrobat JavaScript” option
• Click OK

This should mitigate the issue.

Unfortunately, some of us have hundreds or thousands of desktops and visiting each one to change this setting is not feasible. Luckily, I stumbled across an Administrative Template for a Group Policy Object that was created by Elazar Broad earlier this year, in reference to APSA09-01. For those who may not be completely familiar with creating a Group Policy Object using this Administrative Template to disable the JavaScript functionality domainwide, I have created a video demonstration of how to do so.

First, download the administrative template here, then click here to watch the video.

This is a little “off-topic” from my usual Cisco-related posts (remember, I still do some server-side stuff too!), but we got hit by this so I thought I’d share (thanks to mardraum for letting me know about the solution).

Earlier this week, on Patch Tuesday, Microsoft released KB973917, “Description of the update that implements Extended Protection for Authentication in Internet Information Services (IIS)“. The related update was responsible for hosing a couple of servers that we have that run IIS 6.0 on Windows Server 2003 SP2. A quick fix was to uninstall that update, but Microsoft the next day posted KB2009746, “Internet Information Services 6.0 may not function correctly after installing KB973917“, which describes perfectly the issue we were seeing:

Consider the following scenario. You have an Internet Information Services (IIS) 6.0 web server running on Windows Server 2003 Service Pack 2. The Microsoft update KB973917 gets installed on the server. After installing KB973917, the IIS 6.0 application pools cannot start up successfully. An inspection of the event logs show that the IIS worker processes are terminating unexpectedly, showing event messages similar to the following:

     Event Type: Warning
     Event Source: W3SVC
     Event Category: None
     Event ID: 1009
     Date:  12/9/2009
     Time:  10:55:01 AM
     User:  N/A
     Computer: WEBSERVER01
     Description:
     A process serving application pool 'DefaultAppPool' terminated unexpectedly. The process id was '1234'. 
     The process exit code was '0xffffffff'.

In some cases, the IIS application pool(s) are eventually disabled by the Rapid Fail Protection feature. Users who try browsing to the web sites hosted on the server may complain that the web sites are unavailable and cannot be accessed.

The article goes on to describe the root cause…

Previous to the installation of the KB973917 update, one or more of the core IIS .dll files were not at the correct file version. Specifically, the earlier installation of Windows Server 2003 Service Pack 2 on the server did not complete successfully, leaving some of the IIS .dlls at the Service Pack 1 level while bringing others up to the Service Pack 2 level. The IIS services had been able to run successfully even with that file mismatch in place. However, the installation of the KB973917 update exposes this pre-existing file mismatch environment to the degree that IIS is now unable to function properly.

…as well as the resolution…

To resolve this problem, reinstall Service Pack 2 for Windows Server 2003 on the web server. This will bring all IIS 6.0 components up to the correct file versions, and will maintain the installation of the KB973917 update. Reinstalling the KB973917 update should not be necessary.

I can confirm that reinstalling SP2 for Windows Server 2003 does, indeed, fix the issue (for us, at least!). We reinstalled KB973917 afterwards and both affected servers are fine.

In case you haven’t been paying attention lately, Microsoft has recently released a couple of security advisories: 972890 and 973472.

Both of them are bad news — unpatched vulnerabilities allowing remote code execution. Microsoft has also stated in each of the security advisories:

We are aware of attacks attempting to exploit the vulnerability.

That’s bad news. At this time I’m writing this, the Internet Storm Center is already reporting more than two million infections in China alone.

While there are currently no patches, Microsoft has published workarounds for these issues. They involve setting a grand total of 47 killbits of Class Identifiers. This might be okay if you have only one PC and a couple hours to kill. For those of us who work in large organizations with hundreds or thousands of PCs, that’s just not feasible.

I have posted two administrative templates that can be used in group policy objects (GPOs) to automate this. They can be downloaded here:

• Administrative template for MS 972890
• Administrative template for MS 973472

For those who may not be used to using their own administrative templates to push out registry settings like this, I’ve recorded a video for you. I hope it’s helpful!

• If your screen isn’t “wide” enough, you can watch the video here instead.

Today is (was) Patch Tuesday.

I’m glad that I’m not using [MICROSOFT PRODUCT]. The latest [VIRUS/WORM/TROJAN] exploits a [FLAW/BUG/BACKDOOR] in [MICROSOFT PRODUCT], and it [DOES/DOESN'T] use Outlook and the stupidity of users. Luckily, I’m running [FREE ALTERNATIVE TO MICROSOFT PRODUCT], so I’m not at risk. In fact, [FREE ALTERNATIVE TO MICROSOFT PRODUCT] has protected me from [ANY INTEGER OVER 200,000] [VIRUSES/WORMS/TROJANS].

And just look at the [HUNDREDS/THOUSANDS/MILLIONS/BILLIONS] of dollars that we’ve saved.

Today, once again, I got annoyed by someone complaining about Microsoft “not including” a telnet client with Windows Vista, so here I am.

Most people will simply use another telnet client: PuTTY, TeraTerm Pro, or — my personal favorite — SecureCRT. The truth is, however, Microsoft actually did include a telnet client with Windows Vista. The problem is that it simply is not installed by default. Below is a step-by-step guide detailing how to install it:

• Start by opening up the Control Panel by clicking the Start button, then “Control Panel”
• Once in the control panel, click on “Programs”.
• Under “Programs and Features”, click on “Turn Windows features on or off”.
• If you get a “User Account Control” popup asking for your permission, click “Continue”
• In the “Windows Features” window that appears, scroll down and click the checkbox next to “Telnet client”.
• Click the “OK” button.
• Windows will then make you wait a random period of time while it installs the telnet client.
• Close the “Control Panel” window.

At this point, you can open up a command prompt (click “Start”, “All Programs”, “Accessories”, and “Command Prompt”) and start the telnet client by typing in “telnet” and pressing the Enter key.

See, wasn’t that simple!?