More on Service Pack 1 & VMware ASLR Guidance

More on Service Pack 1 & VMware ASLR Guidance

  • Comments 12
  • Likes

Virtualization Nation,

In my last blog, we announced the RTM (Release to Manufacturing) of Service Pack 1 for Windows 7 and Windows Server 2008 R2 SP1. The bits will be available for download on Feb. 22, so mark your calendars.

A frequent follow-up question to hit my inbox was from folks interested in a list of documented changes included in Windows 7 and Windows Server 2008 R2 SP1 in addition to Dynamic Memory and RemoteFX.

No problem.

Here’s the link to the documentation for Windows 7 and Windows Server 2008 R2 SP1 (KB976932). This KB includes:

  • Hotfixes and Security Updates
  • Notable Changes
  • Test Guidance

While the current version posted is for the Service Pack 1 Release Candidate, the final version will be available shortly for the RTM version.

VMware and ASLR Follow-Up

In my last blog, I discussed the importance of Address Space Layout Randomization (ASLR) as an effective, transparent security mitigation built-into Windows 7. I noted that independent security analysts wholeheartedly agree on the importance of ASLR. I also stated we have serious concerns that VMware was recommending customers disable ASLR to achieve better density.

Following that blog post, we were contacted by Jeff Buell from VMware.

From Jeff Buell, Perf Engineering at VMware

I'm from the performance engineering team at VMware.  We take both performance recommendations and security very seriously.  As you state, ASLR is a good security feature. VMware has never recommended disabling it.  If you have a reference saying otherwise, I'd love to see it.  

First, let me say thank you to Jeff Buell for his swift response. I’m glad to see that Microsoft and VMware Engineering agree that ASLR is a good security feature and that disabling ASLR is a terrible suggestion. Jeff appears to be concerned and willing to rectify this situation. Again, thank you Jeff. Here are the specifics.

Looks Like It Started Here…

It appears that the suggestion to disable ASLR began right here on VMware’s public blog page.

http://blogs.vmware.com/view/2009/04/vista-and-vmware-view.html

The post casually mentions that disabling ASLR will “lower overall security,” and then continues to make things worse by telling people to disable NX and DEP, two additional security mitigations. Because of this post, others picked up on this recommendation (such as in VMware’s community forums) and promoted this idea without anyone from VMware disputing this unfortunate suggestion:

http://communities.vmware.com/message/1294525#1294525

At first, I thought these were isolated incidents, but then I started receiving regular inquiries from customers who said they were considering a VDI deployment and specifically asking if Microsoft had a recommendation or support stance regarding ASLR. Considering the fact that ASLR is transparent and you have to go out of your way to disable it (you have to be admin and then go to the Registry), I knew this wasn’t isolated anymore.

Finally, at VMworld 2010 in Europe, VMware Director of Product Marketing, Eric Horschman, delivered session TA8270 titled, Get the Best VM Density From Your Virtualization Platform.

 In this session, a slide was presented with the following:

Best practices

> Blame storage first - avoid bottlenecks
> Upgrade to vSphere 4.1 for memory compression
> Install VMware tools in guest OSes to enable ballooning
> Protect your critical VMs
> Add VMs until “active” memory overcommit is reached
> Allow DRS to balance VMs across your cluster

Advanced techniques

> Use flash solid state disks for ESXi swapfile datastore (for overcommitted hosts)
> Adjust HaltingIdleMsecPenalty (KB article 1020233)
> Consolidate similar guest OSes and applications to assist Transparent Page Sharing
> Disable ASLR in windows 2008/Windows 7 guests for VDI workloads

When a VMware Director is promoting such poor advice, we were concerned our customers were putting themselves in undue risk and wanted to clearly articulate the Microsoft position. There is an apparent disconnect between VMware engineering and marketing on this topic, and I’m glad to see the engineering team speak out.

Again, my thanks to Jeff Buell from VMware Engineering for his quick response to this matter. I’m going to assume that VMware will clarify their position internally and appropriately message their position externally by fixing these external links. I’d be relieved to see VMware no longer recommend users disable fundamental security mitigations, such as ASLR, any further.

In my next blog, I’ll discuss some points you should consider make when determining what guest OS to deploy for VDI.

Cheers,

Jeff Woolsey
Group Program Manager, Hyper-V
Windows Server & Cloud

 

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Any chance you guys could finally fix the formatting of this site in non-IE browsers?  I get that you love IE, but most people that I know in IT don't, and it's a pain in the rear to read this page when half of the text ends up jumbled on that dark grey background.  Rule #1 of usability...if people have to switch browsers to use your web site then they probably won't.

  • How about you rectifying the original article and comparing "Dynamic" Memory with Ballooning instead of TPS so that it is a fair game?

    Duncan

    Yellow-Bricks.com

  • @Otherkevin  odd, this renders well for me in Firefox 3.6 and Safari

  • Looks like in both camps silly recommendations are 'suggested'.

    Don't you recommend to turn off ballooning on virtual machine running, for instance, SQL server?

    Cheers,

    Didier

    deinoscloud.wordpress.com

  • I love how now that you have linked to the VMware pages suggesting stupidity the vmware people try and change the subject like Duncan above after the rather engaged call out on your previous posting about vmware suggesting ASLR being disabled.

  • jlGGY,

    I think you are misinterpreting my comment. I am not disregarding it but ignoring it as it is regular FUD. In the first post Jeff talks about "recommendations" and now he refers to two separate statements where advanced techniques are discussed to push the boundaries including a warning and the possible impact. This is something totally different than he initially insinuated.

  • Jeff,

    Your version of my talk at VMworld 2010 Europe leaves out some important warnings I provided on my slide and verbally during the session.  When I brought up the Project VRC findings showing that disabling ASLR could boost vSphere VM density, I cautioned that it would weaken Windows security and should be done only in isolated testbeds.  The bullet point on my slide clearly stated, "Testing shows up to a 16% VDI score gain, but lessens security."

    I'm not sure how you construe that as a VMware recommendation that customers put their VMs at risk.  Your readers can get more background here: blogs.vmware.com/.../hypervisor-memory-management-done-right.html

    You might also mention that ASLR doesn't seem to be slowing down malware authors.  This paper by Microsoft's own security team acknowledges that the bad guys can easily bypass ASLR: blogs.technet.com/.../on-the-effectiveness-of-dep-and-aslr.aspx

    Eric

  • @Otherkevin, I suggest you check your browser settings - I can view this page in Opera 11 and Firefox 3 & 4 with problems...

  • The site doesn't work for me -- I'm in webkit-based Google Chrome. I imagine webkit-based Safari also has this issue.

    Debugging briefly, it appears to be the margin-left: -58px applied to .layout-content.header-top-sidebar-left-content-right .layout-region.content on line 51 of /themes/blogs/wireframe/css/DynamicStyle.aspx. Unchecking the margin-left in Web Inspector fixes the error and puts the blog's body where it belongs -- flush with the right border of the header.

    As to reasons for disabling ASLR -- what about nginx and similar caching tools which can't share memory reliably without disabling ASLR? nginx.org/.../windows.html Note that if there's a way to disable ASLR on an application-by-application basis in a way that could be supported by nginx, I'd love to hear it. Our sysadmin is much more versed in Windows than Linux, yet most memory caches require Linux.

    This blog also highlighted for me how we probably shouldn't try to run a memory cache off Hyper-V, as there could be other issues involved. It's kind of sad, though, because most websites could be held in no more than 2 GB of RAM and the speed-up is enormous over HDD access (though perhaps not SSD).

  • Isn't saying disabling ASLR makes Windows less secure kind of like saying pouring a bucket of fresh water in the ocean makes it less salty?

  • I found Eric Horschman comment to be perfectly accurate. Microsoft tends to be PR only, and “forget” to mention well-known fact like that ASLR is no longer being effective.

    I have actually never seen VMware memory management and by reading MS posts only I thought it can only perform Page-Sharing and its capabilities are limited. Obviously I was wrong, thank you for the link.

    Btw;

    I am aso using Chrome and having troubles viewing this page since always.

  • It's a tradeoff - lose the security provided by ASLR (there seems to be some documentation questioning exactly how much security this adds) vs. cost savings in large deployments by achieving approximatly 16% greater VM density.  In many Enterprise deployments where thousands or even 10k+ VDI VMs are deployed the 16% can translate to some real dollars which management may not want to ignore.  Additionaly these larger enterprise deployments are often engineered well beyond the hypervisor layer with network hardware security devices such as enterprise class firewalls, IPS devices and gateway antivirus applainces which are capable of providing sigificantly more protection to the VDI network than a typicaly windows PC will get from localy loaded software and OS features.  In such a purpose built VDI environment it may not be unreasonable to disable ASLR to attain cost savings on large scale VDI deployments though security risk need to be preseneted to management and internal security teams for evaluation.