This month we will be releasing 9 bulletins addressing 13 vulnerabilities affecting Windows, Internet Information Services (IIS), and Microsoft Office. Four of those bulletins carry a Critical rating, with the rest rated Important.

We recommend as always that customers review the ANS summary page for more information and prepare for the testing and deployment of these bulletins as soon as possible.

Next Wednesday, September 15th, Adrian Stone and Jerry Bryant will host a public webcast during which they'll go into details about the bulletins, and answer questions live on the air. To register for this webcast in advance:

Date: Wednesday, September 15, 2010
Time: 11:00 a.m. PDT (UTC -7)
Registration: https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032454433

We highly recommend that customers register for our comprehensive alerts if you have not done so already. Sign up here: http://technet.microsoft.com/en-us/security/dd252948.aspx

Thanks,

Carlene Chmaj

Security Response Communications Manager

Follow us on Twitter: @MSFTSecResponse

Moving on in my “scripting dynamic memory” series, the next thing to look at is how to get the current memory usage and memory available data that we display in the Hyper-V manager.  You can get the current memory usage by just looking at MSVM_Memory (http://msdn.microsoft.com/en-us/library/cc136855(v=VS.85).aspx), but unfortunately you cannot get the memory availability that way.  To get the memory availability you need to use GetSummaryInformation (http://msdn.microsoft.com/en-us/library/cc160706(v=VS.85).aspx).

GetSummaryInformation is an API that we use as a light weight way to get a bunch of information about a virtual machine.  It returns a Msvm_SummaryInformation Class (or a collection of these) (http://msdn.microsoft.com/en-us/library/cc136898(v=VS.85).aspx)

# Prompt for the Hyper-V Server to use

$HyperVServer = Read-Host "Specify the Hyper-V Server to use (enter '.' for the local computer)"

# Prompt for the virtual machine to use

$VMName = Read-Host "Specify the name of the virtual machine"

# Get the management service

$VMMS = gwmi -namespace root\virtualization Msvm_VirtualSystemManagementService -computername $HyperVServer

# Get the virtual machine object

$VM = gwmi MSVM_ComputerSystem -filter "ElementName='$VMName'" -namespace "root\virtualization" -computername $HyperVServer

# SettingType = 3 ensures that we do not get snapshots

$SystemSettingData = $VM.getRelated("Msvm_VirtualSystemSettingData") | where {$_.SettingType -eq 3}

# Request the virtual machine state (100), current memory (103) and memory availability (112)

$RequestedInformation = 100,103,112

# Get the summary information for just the selected virtual machine

$SummaryInformation = $VMMS.GetSummaryInformation($SystemSettingData, $RequestedInformation).SummaryInformation | select -first 1

# Check that the virtual machine is running

if ($SummaryInformation.EnabledState -eq "2")

   { write-host "Memory information for" $VMName

     write-host

     write-host "Current memory usage:" $SummaryInformation.MemoryUsage "MB"

     # If memory available == 2147483647 then no memory available value has been returned from the virtual machine

     if ($SummaryInformation.MemoryAvailable -ne 2147483647)

        { write-host "Current memory availability:" $SummaryInformation.MemoryAvailable"%"}

     else

        { write-host "Dynamic memory is not currently active on this virtual machine"}

   }

else

   { write-host "The requested virtual machine is not currently running" }

Some things to know:

• While the code above gets the summary information for a single virtual machine – GetSummaryInformation allows you to pass in a null value for the system setting data.  In this case you will get information about all virtual machines on the system.
• While I am only displaying information about the current memory and the memory availability – you can get a lot more information in this way.  Hit the link for GetSummaryInformation above if you want to see all that you can possibly get in this fashion.

Cheers,
Ben

With the availability of dynamic memory in Windows Server 2008 R2 SP1 there are some changes to how you need to handle memory as a scripter / developer.  The WMI API changes are now documented here http://msdn.microsoft.com/en-us/library/cc136856(VS.85).aspx

Most of the changes are fairly obvious – but two not so obvious properties are the properties for the “Startup RAM” and “Maximum RAM”.  In WMI these are mapped to “VirtualQuantity” and “Limit” respectively.  Here is a sample script that simply displays the memory configuration of the specified virtual machine:

# Prompt for the Hyper-V Server to use

$HyperVServer = Read-Host "Specify the Hyper-V Server to use (enter '.' for the local computer)"

# Prompt for the virtual machine to use

$VMName = Read-Host "Specify the name of the virtual machine"

# Get the management service

$VMMS = gwmi -namespace root\virtualization Msvm_VirtualSystemManagementService -computername $HyperVServer

# Get the virtual machine object

$VM = gwmi MSVM_ComputerSystem -filter "ElementName='$VMName'" -namespace "root\virtualization" -computername $HyperVServer

# SettingType = 3 ensures that we do not get snapshots

$SystemSettingData = $VM.getRelated("Msvm_VirtualSystemSettingData") | where {$_.SettingType -eq 3}

# Get the Memory setting data

$MemSetting = $SystemSettingData.getRelated("Msvm_MemorySettingData") | select -first 1

# Display information about the current memory configuration

switch ($MemSetting.DynamicMemoryEnabled)

   {

      True  {# Dynamic memory is enabled

             write-host

             write-host "Dynamic memory is enabled."

             write-host

             write-host "Startup Memory: " $MemSetting.VirtualQuantity $MemSetting.AllocationUnits

             write-host "Maximum Memory: " $MemSetting.Limit $MemSetting.AllocationUnits

             write-host "Memory buffer:  " $MemSetting.TargetMemoryBuffer

             write-host "Weight:         " $MemSetting.Weight}

      False {# Dynamic memory is disabled

             write-host

             write-host "Dynamic memory is disabled."

             write-host

             write-host "Memory: " $MemSetting.VirtualQuantity $MemSetting.AllocationUnits

             write-host "Weight: " $MemSetting.Weight}

   }

Cheers,
Ben

Most people I know who have spent a lot of time with Hyper-V have had the experience of accidentally taking too much memory away from the parent partition.  This happens when they start too many virtual machines – and all of a sudden the performance and responsiveness of the parent partition goes down significantly.

The response from people who hit this is usually to stop the last virtual machine that they started, to reduce its memory, and then start it up again.

This solution has worked in the past – but is no longer an option with dynamic memory.  The reason why this will not work is because if you stop the last virtual machine – you just leave the memory available for your other virtual machines to use – getting you straight back where you started.

For this reason, with dynamic memory we have implemented a new “parent memory reserve” for Hyper-V.  Here we attempt to calculate an appropriate amount memory to keep for the parent partition and ensure that virtual machines with dynamic memory enabled cannot eat into this reserved memory.

That said – this reserve is not perfect.  Specifically – it only accounts for the memory requirements of Hyper-V in the parent partition.  If you are running other workloads in the parent partition (contrary to our best practice guidance) then you may still see parent partition memory starvation.

To help mitigate this issue – we are also providing a new registry entry that lets you override our parent memory reserve with your own static memory reserve.  This registry entry does not exist by default – but if you go to the HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization registry key and create a new DWORD entry with a name of memoryreserve – you can then set the value to the static amount of memory that you want to reserve for the parent.

You should be warned – if you set this value too low; virtual machines will be able to use too much memory and cause performance issues for you.  Equally – the higher you set this the fewer virtual machines you can run.

That said – I have found this to be very useful on my laptop – where I use Hyper-V like a desktop operating system.  By setting this value to 2048 (on my laptop with 8GB of RAM) I can run multiple virtual machines and know that they will not cause Outlook / Internet Explorer in the parent partition to be affected.

Cheers,
Ben

Jeff has discussed this at some length over on the virtualization team blog, but as a general rule of thumb we believe that it is much better to have paging occur inside the guest operating system rather than at the virtualization layer (if paging is needed).

The simple reason for this is that the guest operating system has far better understanding of which are the best sections of memory to page out – where as all the virtualization layer can do is to guess at what should be paged out.

In my recent demonstrations of dynamic memory I came upon another interesting angle to consider.  Here is a screenshot of task manager from a virtual machine that is running at –23% memory availability (i.e. it does not have enough memory available and is paging in the guest):

What is fascinating about this screenshot is that even though this virtual machine is significantly short of memory, the guest operating system is still keeping 112mb memory available / as file cache.  The reason for this is that the copy of Windows inside the virtual machine knows that even though it is short of memory – it can provide the best experience for the user of the virtual machine by not using all the memory that it has and by keeping a little bit free to serve as a cache / be there for new applications.

It is exactly this sort of logic that gets lost when paging is done at the virtualization layer instead of inside the guest operating system.

Cheers,
Ben

With Windows Server 2008 R2 SP1 we have added a number of new performance counters for dynamic memory.  These counters allow you to get some extra insight into what is actually happening with memory on your Hyper-V server.  The counters are grouped in two categories.  First is “Hyper-V Dynamic Memory VM”:

These counters allow you to access specific information about dynamic memory inside each of the virtual machines on your system.  The second category is “Hyper-V Dynamic Memory Balancer”:

These counters allow you to view information about dynamic memory across the entire physical computer.

One thing to note is that unlike the user interface – which uses the concept of “memory availability” (which I discussed yesterday) – the performance counters instead talk about memory pressure.  This is measuring the same thing as memory availability (i.e. how much memory does the virtual machine have compared to how much memory does it need) but the math is slightly different.  A virtual machine with a pressure of 100 has exactly the amount of memory that it needs (this is equivalent to a memory availability of 0%).  If the virtual machine pressure goes over 100 – it now has less memory than it needs (equivalent to a negative memory availability) and if the virtual machine pressure is under 100 then the virtual machine has more memory than it needs.

Virtual machine pressure is simply calculated by taking the amount of memory the virtual machine wants, dividing it by the amount of memory the virtual machine has and then multiplying the result by 100.

My favorite performance counter is the “Average Pressure” counter under the “Hyper-V Dynamic Memory Balancer” category.  This gives you a very simple view of the overall memory allocation of your system:

As long as this number is under 100, you know that there is enough memory is your system to service your virtual machines.  Ideally this value should be at 80 or lower.  The closer this gets to 100, the closer you are to running out of memory.  Once this number goes over 100 then you can pretty much guarantee that you have virtual machines that are paging in the guest operating system.

Cheers,
Ben

Since we released Security Advisory 2269637 on August 23, we've continued to conduct an investigation not only into our own affected products, but also into how we can best help to protect customers given DLL preloading also affects some third-party applications. We'd like to provide an update on our investigation.

First, I want to be clear that Microsoft plans to address those of our products affected by this issue in the most appropriate way for customers. This will primarily be in the form of security updates or defense-in-depth updates. Also, due to the fact that customers need to click through a series of warnings and dialogs to open a malicious file, we rate most of these vulnerabilities as important.

One of the goals we have at Microsoft is to make it easy for developers to create secure applications on our platform. As we stated in our previous blog post, DLL preloading is a well-known class of vulnerabilities and we have had guidance for developers in place for quite some time. We have recently updated that guidance to provide more clarity.

Even with improved guidance, we recognize that it may take quite a bit of time for all affected applications to be updated and for some, an update may not be possible. With the advisory, we released a tool to help customers protect their systems (see KB 2264107). This tool provides a framework for customers to modify the behavior of the DLL search path algorithm and essentially block unsafe DLL loading. When installed, this tool still needs to be configured in order to block malicious behavior, and customers have asked us for our recommended setting. As a result, our Security Research & Defense team has written a detailed blog post on this topic and has worked with our Microsoft Fix-it team to develop a Fix-it to enable our recommended setting which blocks most network-based attack vectors. (Please note that the tool needs to be installed prior to enabling the Fix-it.)

Many enterprise customers have asked us to make it easier for them to deploy this tool. As a result, we are working with the Windows Update (WU) team to add the tool to the WU catalog. This will make it easier for those running Windows Server Update Services (WSUS) to deploy. We are working to have that solution in place within the next couple of weeks. We are also considering releasing this solution more broadly via WU as a defense-in-depth update for all customers in an "off by default" state. We will share more information through the MSRC blog as our plans are solidified.

Customers should note that the tool is limited to protecting against DLL preloading only and does not protect against .exe files that do not properly load files via a fully qualified path and developers will be required to update those applications accordingly.

Thank you,

Jerry Bryant
Group Manager, Response Communications

When you use dynamic memory with Hyper-V one of the obvious changes to the user interface is the addition of the “Memory Availability” column:

This is actually a really useful figure to have handy.  What memory available represents is the ratio of how much memory a virtual machine has – compared to how much memory the virtual machine needs.  For example:

If a virtual machine had 1000MB of memory – but only needed 900MB of memory we would report a memory available figure of 11%, because the virtual machine has 11% more memory than it actually needs.

Because the workload inside a virtual machine is constantly changing, and we are constantly moving memory around in response to these changes, you can expect the memory available figure for your virtual machines to keep on moving as the virtual machine is running as well.  It is also possible for a virtual machine to report a negative figure for memory available:

What this means is that the virtual machine has less memory than it needs.  Note that in this case the virtual machine is still running – but it is likely that the guest operating system is now needing to page heavily in order to make forward progress.

You should always keep an eye on the memory availability of your system.  As a general rule of thumb you want to see this value at the level of your configured memory buffer (which is 20% by default).  Once you see this value start to dip under 10% that is a good warning that you should not be starting new virtual machines.  If this value starts to get close to 0% (or even into the negatives) you should really think about stopping some virtual machines or migrating them to another server.

Cheers,
Ben

I am a bit late in getting this post up (due to being on the road at TechEd Australia & TechEd New Zealand); but last week we released a hotfix rollup package.

This package includes the fixes for three of the five issues that I recently blogged about.  The specific issues that are addressed are:

KB Number: KB975530
Title:Stop error message on an Intel Xeon 5500 series processor-based computer that is running Windows Server 2008 R2 and that has the Hyper-V role installed: "0x00000101 - CLOCK_WATCHDOG_TIMEOUT"
Description:This is fairly simple.  If you have a computer with an Intel Xeon 5500 series processor or an Intel Core-i series processor and you see this blue screen – install this hotfix.
Extra detail: I blogged about this back in October.  Some of you reported that this did not solve the problem for you.  The hotfix has since been updated to address the problem on these systems that were missed with the original fix.
Link: http://support.microsoft.com/kb/975530

KB Number: KB981791
Title:"STOP: 0x0000001a" error message on a computer that has an Intel Westmere processor together with the Hyper-V role installed on Windows Server 2008 SP2 or on Windows Server 2008 R2
Description: Once again, if you have this processor (Intel Westmere) and see this blue screen – get this hotfix.
Link: http://support.microsoft.com/kb/981791

KB Number: KB974909
Title: The network connection of a running Hyper-V virtual machine is lost under heavy outgoing network traffic on a Windows Server 2008 R2-based computer
Description:This affects all guest operating systems.  The fix is applied to the hypervisor and while a reboot is required for installation, no updated need to be applied to the guest operating systems.
Link: http://support.microsoft.com/kb/974909

You can get the new rollup package from here: http://support.microsoft.com/kb/2264080 – alternatively it will be appearing as an optional update under Windows Update.

Cheers,
Ben

Today we released Microsoft Security Advisory 2269637. This is different from other Microsoft Security Advisories because it's not talking about specific vulnerabilities in Microsoft products. Rather, this is our official guidance in response to security research that has outlined a new, remote vector for a well-known class of vulnerabilities, known as DLL preloading or "binary planting" attacks.  We are currently conducting a thorough investigation into how this new vector may affect Microsoft products. As always, if we find this issue affects any of our products, we will address them appropriately.

Additionally, today we are providing a defense-in-depth update that customers can deploy that will help protect against attempts to exploit vulnerable applications through this newly identified vector. Finally, we are using our strong connections with researchers and partners in the industry to help address this new class of vulnerability. Our Microsoft Vulnerability Research program has been working to coordinate communication between the researcher who first brought this new vector to us and other application developers who are affected by this issue.

Technical Background

What this new research demonstrates is a new remote vector for DLL preloading attacks. These attacks are not new or unique to the Windows platform. For instance, PATH attacks that are similar to this issue constitute some of the earliest class of attacks against the UNIX operating system. The attack focuses on tricking an application into loading a malicious library when it thinks it's loading a trusted library. For this to succeed, the application has to call the trusted library by name instead of properly using its full path (for example, calling dllname.dll rather than C:\Program Files\Common Files\Contoso\dllname.dll). The attacker then has to place a malicious copy of the library in a directory that the system will search to locate the library and have that be a directory it will search before the directory where the trusted library actually is. For example, if an attacker knows that the application simply calls for dllname.dll (rather than using the full path) and it will look for dllname.dll in the current working directory before looking in C:\Program Files\Common Files\Contoso\. Then if the attacker can plant a malicious copy of dllname.dll in the current working directory, the application will load it first executing the attacker's code in the application's security context.

PATH or DLL preloading attacks have so far required the attacker to plant the malicious library on the local client system. This new research outlines a way an attacker could levy these attacks by planting the malicious library on a network share. In this scenario, the attacker would create a data file that the vulnerable application would open, create a malicious library that the vulnerable application would use, post both of them on a network share that the user could access, and convince the user to open the data file. At that point, the application would load the malicious library and the attacker's code would execute on the user's system.

Because this is a new vector, rather than a new class of vulnerability, the existing best practices that protect against this class of vulnerability, automatically protect against this new vector: ensuring that applications make calls to trusted libraries using full path names.

While the best protection is following best practices, we are able to provide an additional layer of defense by offering a tool that can be configured to disable the loading of libraries from network shares. In particular, because this is altering functionality, we encourage customers to evaluate this tool before deploying it. As part of your evaluation, we encourage you to review the information at the Security Research and Defense (SRD) blog.

We will continue our work with the researchers and the industry to identify and address vulnerable applications. And as always, we will update you with any new information we have through our security advisories, security bulletins and the MSRC weblog as appropriate.

Thanks

Christopher