Archive for April, 2008

MS08-021 Being Exploited

I don’t mean to tell you ‘I told you so’, but I will. I told you so. As we discussed in the April post patch day webinar, MS08-021 is the most important patch to get installed from the April patch release. eWeek is reporting that an exploit was released in the wild for the graphic image exploit vulnerability a mere 2 days after the patch was released. More info here:


Leave a comment »

Supporting Virtualization

I’m really excited to talk about one of our upcoming features – specifically, support for Virtualization.

Shavlik already supports patch and configuration management for virtual systems on your network. A running virtual system is just like a real system to Shavlik NetChk Protect and NetChk Compliance (now NetChk Configure). You can scan and patch these virtual systems today to ensure that your running VMs are protected.

Now Shavlik is taking things to the next level. Upcoming releases of Shavlik NetChk Protect will enable you to scan and patch OFFLINE virtual images. Offline images are those that aren’t currently powered on. You may have hundreds of offline virtual images in your VM repository – these VMs are powered on for hours or days and may be powered off again until the next month when they are needed. It’s important to ensure that these systems are patched as soon as they are brought online, else you place your network at risk from these unpatched systems.

Shavlik NetChk Protect makes it easy patch these systems. Simply reference the offline image or folder of images in a NetChk machine group and perform a scan like usual. The Protect scan engine will perform a full patch assessment of each image and results are displayed alongside results for running systems (you’ll be able to differentiate images from running systems in the results view).

Patching these offline images is similarly simple. Highlight the images and patches you’d like to install and select ‘deploy’ from the Shavlik menu. The patches will be copied to the offline images and will be installed the moment that the virtual image is started (or according to its scheduled deployment time).

What’s really nice about this feature is the ability to patch not only the VM images that you know about (ESX SAN drive, folder of MS Virtual Server images, etc) but you can also scan desktops and servers for presence of VMware Workstation, VMware Server, and Microsoft Virtual PC images.

Additional information about the offline virtual scanning and patching functions are available in Shavlik Knowledge Base Article SKB 5788.

Leave a comment »

Reflections on April 2008 patch day

All 8 bulletins this month are client side vulnerabilities. IOW, your system is safe unless a user logs in and opens documents, reads email, or visits an evil website on that computer. Systems where no one logs on and does this (ie Servers in data center) are safe.

Of the five OS-related vulnerabilities this month, four impact Vista and Windows Server 2008.

The most critical to get installed away are MS08-021, MS08-022, and MS08-024. Of these, MS08-021 is the most important, as it can be exploited by all three attack vectors: visiting an evil website, opening an evil document, or reading an evil email. MS08-021 is a flaw in the way that image files are processed – an evil graphic file can execute code on your system. This is the third such evil graphic file attack since January of 2006.

MS08-022 is a flaw in jscript and vbscript in IE6 and earlier versions of IE. Visit an evil website and you’ll get hacked. This is the patch that was delayed from the January release cycle.

MS08-024 is a flaw in all versions of IE – visit an evil website and you’ll get hacked.

MS08-025 is a privilege escalation vulnerability that can allow a user to elevate themselves from user to admin. This can also be exploited by any of the other vulnerabilities announced this month. IOW, visit an evil website and it can execute code on your system to make you an admin – then the evil website can do anything on your system that it wants. IOW, from what I can tell, this vulnerability erases the mitigation that MS provides for all earlier patches about – ‘the evil code will only execute with the permissions of the logged on user – therefore you are safer if you are logged on with a non administrative account).’

Leave a comment »

Speeding up agentless deployment with distribution servers

I thought I’d take this time to share an idea that might help you speed up the agentless patch deployment process. Turns out, some work we did to support agent-based deployments can provide a big benefit for agentless deployments.

In a standard agentless deployment, the NetChk console pushes each patch or group of patches to each remote system. If there are two patches to push to each of 1,000 systems, the console will push 2,000 patches total. The console can push to 64 machines simultaneously – so it may take some time to push out all of the patches all of the machines. The patch push can also consume a lot of network bandwidth, especially if pushing patches to a large number of systems across a slow link.

We can address both speed and bandwidth issues for agentless deployments via the use of distribution servers.

The term ‘distribution server’ is really a misnomer. It’s not really a server at all. Instead, a distribution server is simply a UNC file share or a web share on a workstation or server machine.

Let’s start with the simple scenario: use the NetChk console as a distribution server. On the NetChk console, share out the C:\Program Files\Shavlik Technologies\NetChk\Patches\en-us (or similar) folder with read-only permissions for a specific netchk patch user account. This ‘share’ is your distribution server.

Next, go to tools-distribution servers to define the distribution server share you just created. Select New on the servers tab and then select the UNC radio button. Enter the UNC path to the share (ex. \\console\patchrepository) and the username and password for the account that has read-only access to this share (don’t worry, this password info is encrypted). There’s no need to enter synchronization data at the bottom of this window because the console patch repository is the same location as the distribution server share.

On the IP ranges tab of the distribution server window, create an IP range for your network. If you want all of your machines to use the same distribution server, you may enter – Assign the distribution server you just created to this IP range.

Finally, go to the deployment template that you’d like to use and select the distribution servers tab. Check the box to deploy patches using distribution servers. Set the randomization number of minutes (if desired) and also decide if you want the target systems to download the patches from the vendor websites directly if the machines can’t contact the distribution server.

Here is where the magic happens. When you go to deploy patches using this deployment template, the patches won’t be pushed to each systems. Instead, the NetChk console will push a very small deployment instruction set to each machine (and the Shavlik Scheduler, if not already present) and will schedule that instruction set to execute at the scheduled deployment time. When this deployment time occurs, the system will realize that it doesn’t have the necessary patches to deploy, it will read the instruction set to obtain the distribution server information, and it will then login to the distribution server and download the specified patches.

The above process will speed up the deployment process, however, the overall bandwidth hit against the network will be the same as if the console was doing a normal patch push. To conserve bandwidth and better handle remote sites, consider the following:

Create one distribution server at each remote site. This can be the UNC style distribution server we created above, or an http or https website at each remote site. The distribution server UNC or web share can reside on workstation or server class machines – whatever is ‘always available’ at the remote site. (Keep in mind that workstation class machines may only support ten concurrent sessions for UNC and web connections).

When defining the distribution servers, create groups of IP addresses – one group for each remote site – and assign the IP ranges to the distribution server at that site. This will ensure that the machines at remote site A will download their patches over the local area network from the distribution server at site A, thus reducing your network bandwidth over the slow link back to the NetChk console. Make sure to run the distribution server sync function to ensure that the remote distribution servers have a full copy of the patches from the console.

The above process is a unique method to leverage distribution servers (normally reserved for agent-based deployments) to aid in the speed and network bandwidth utilization when performing agentless deployments.

Leave a comment »