I just posted an article over on the SDL blog about security metrics in reponse to an analyst's criticisms of how we measure success/failure/progress.

Comments always welcome.

UPDATE David Litchfield just made a post on the subjet.

Eric Lawrence just posted some commentary about IE8 and DEP/NX. As you may know, IE7 supports DEP/NX, but it's disabled by default owing to compatibility issues. Well, DEP/NX is now enabled by default for IE8 when running on Windows Server 2008 and Window Vista SP1 and later :-)

If you build any form of extensibility mechanism for IE, you should read his post.

David LeBlanc and I (and a bunch of others) just had a little email exchange about some fascinating integer overflow vulnerabilities in gcc.

Long story made short: the code you add to detect integer overflows might actually be removed by the compiler because of assumptions made by the optimizer. I was going to write a post on the subject, but David did it for me :-) A frankly, no-one knows int-overflow science quite like LeBlanc.

I can't help but be reminded of another compiler optimization vulnerability we discovered a few years back. I wonder what else might be in store for us from the world of compiler optimizations?

These are pretty cool - I'm a big fan of highly focused, short education like this... http://msdn2.microsoft.com/en-us/security/bb896640.aspx

Update: Added Microsoft bulletin stuff.

I'm always looking up CVEs so I want to get to the data as quickly as possible, especially if I'm digging through a load of them. 

Three years ago I posted some code to perform CVE lookup using Smart Tags in Microsoft Office.

IE8 offers similar functionality to Smart Tags, but way more flexible, named Activities. So I did a bit of digging around, and found this article by Jane Kim in the IE8 team that explains how to use and create Activities (and provides links to all the appropriate documentation.)

So I decided to write my own activity to look up CVEs from within IE8. Here's the XML:

<?xml version="1.0" encoding="utf-8"?>
  <openServiceDescription xmlns="http://www.microsoft.com/schemas/openservicedescription/1.0">
  <homepageUrl>http://nvd.nist.gov</homepageUrl>
    <display>
    <name>Lookup CVE with NIST</name>
    <icon>http://nvd.nist.gov/favicon.ico</icon>
  </display>
  <activity category="define">
    <activityAction context="selection" >
      <preview action="http://nvd.nist.gov/nvd.cfm">
        <parameter name="cvename" value="{selection}" />
      </preview>
      <execute action="http://nvd.nist.gov/nvd.cfm">
        <parameter name="cvename" value="{selection}" type="text" />
      </execute>
    </activityAction>
  </activity>
</openServiceDescription>

 Here's the same code, but tweaked for Microsoft Security bulletins:

<?xml version="1.0" encoding="utf-8"?>
  <openServiceDescription
    xmlns="http://www.microsoft.com/schemas/openservicedescription/1.0">
  <homepageUrl>http://www.microsoft.com</homepageUrl>
  <display>
    <name>Lookup Microsoft Bulletin</name>
    <icon>http://www.microsoft.com/favicon.ico</icon>
  </display>
  <activity category="define">
    <activityAction context="selection" >
      <preview action="http://www.microsoft.com/technet/security/bulletin/{selection}.mspx">
      </preview>
      <execute action="http://www.microsoft.com/technet/security/bulletin/{selection}.mspx">
      </execute>
    </activityAction>
  </activity>
</openServiceDescription>

To install, copy the file(s) to a Web server, and then run the following from within IE8:

<button
  onclick="window.external.addService('http://localhost/<name>.xml')">
  CVE Lookup Activity
</button>

Now when you click a CVE, you'll have the option to do a CVE lookup: 

Voila!

Following on from my recent post about Windows Vista security and the SDL, a number of people have indicated to me that obvioulsy it's a fluke. It's important to point out that the reason I talk about Windows Vista so much is because I work in the Windows Division. The SDL was born in Windows.

But the SDL extends across Microsoft, not just Windows. So if the SDL works, wouldn't we see vulnerability reduction in other Microsoft products too? Er, yes!

Take a look at a blog post Jeff just made and you'll see what I mean.

Windows Server 2008 has shipped! And a fine product it is, too!

Windows Server 2008 is the first Windows Server to go through the full SDL process, making it the most secure version of Windows Server to date. We raised the security bar in Windows Vista, and we REALLY raised the bar in Windows Server 2008.

Windows Server 2008 is a prime product example of our ongoing commitment to Trustworthy Computing, and how the company is making good on its commitment to continue to build the most secure computing environment possible. After the Trustworthy Computing commitment was made a few years ago, we've has made great strides in the right direction, and last week's product launch (Windows Server 2008, SQL Server 2008, and Visual Studio 2008) clearly shows that security remains a top priority.

While I tend to focus on "Secure Features" Windows Server 2008 is full of "Security Features." Someone asked me for my favorite security features. In no particular order, they are:

• The various defenses we see in Windows Vista: stack defenses, heap defenses, ASLR, NX etc etc
• Server Core (ok, technically not a security feature, but a critical way to dramatically reduce a server's attack surface)
• Network Access Protection (NAP)
• Server and Domain Isolation
• Read-Only Domain Controllers
• Suite-B crypto support

Oh, the Windows Server 2008 Security Guide is now available!

2/19 - Added some Minor Tweaks

Perhaps it's the phase of the moon or something, but over the last few weeks I have received more email about correctly using the HeapSetInformation function than any other topic. I really don't know why! This was added last year as an SDL requirement.

So here's a quick FAQ:

Q: What does the HeapSetInformation function do?
A: It lets your application configure the Windows heap manager with a small number of options. The only security-related setting kills your application in case of heap corruption.

Q: What do you mean by "heap corruption"?
A: Anything that messes with data in the Windows heap, for example damaged caused by a buffer overrun, writing to a stray pointer or a double-free are examples.

Q: How do I use the function?
A: Like this:

BOOL f=HeapSetInformation(NULL, HeapEnableTerminationOnCorruption, NULL, 0);

Q: What should my code do if the function fails?
A: I think it's really up to you as this is not a critical failure, the call should only fail on a platform that does not support termination-on-corruption. This function offers a defense in depth, and is not required for successful operation of an application. So personally, I would just keep on running.

Q: What does this buy me?
A: Assume you code has a heap-based buffer overrun that you do not know about (because if you knew about it, you'd remove it!) If an attacker attempts to exploit it, there is a reasonable chance the attack might make the application crash rather than running exploit code.

Q: What if my code is Windows Vista and later only, can I use a linker option?
A: Yes, link with /SUBSYSTEM:WINDOWS,6.0

Q: Is this a "slam dunk" defense?
A: No. There is a no replacement for secure code, this is just a speed bump designed to make it harder for attackers to exploit heap-based vulnerabilities.

Q: When and where should I use this?
A: All the time - just add the code to your main() function.

Q: Which versions of Windows support termination on heap corruption?
A: Windows Vista and Windows Server 2008

Q: So what happens if I call HeapSetInformation with this option on a down-level version of Windows?
A: It's a no-op. you can call HeapSetInformation, but you simply won't get the defense.

Q: What about 64-bit Windows?
A: There is no need to call this API, the operating system enables termination-on-corruption by default. But you should call it anyway, because your code might run on 32-bit Windows.
A: By default, all 64-bit applications running on 64-bit Windows Vista or Windows Server 2008 get this defense by default, there is no need to call the function. A 32-bit application running on 64-bit Windows does not get the defense for free, the code must call the function.

Q: So if this is available on Windows Vista and Windows Server 2008 and later, do I need to use the Windows Vista (or later) SDKs?
A: No. The termination-on-corruption option is just a flag, so you could use code like the following if you're using an older SDK:

#ifndef HeapEnableTerminationOnCorruption
#     define HeapEnableTerminationOnCorruption (HEAP_INFORMATION_CLASS)1
#endif

Q: Is there a performance hit.
A: No.

Q: Is there an application compatibility hit?
A: Possibly, but in my analysis of real world code: no. If your application crashes because of this API, and it never happened in the past without this API, then I suppose technically, that's a compatibility issue. However, you just hit some form of heap corruption which you need to fix, so fix the bug and remove the application compatibility issue!

Q: Is this still of use if grab a hunk of heap, and then perform my own sub-allocations? In other words, I have my own memory allocation system, and only use the operating system to give me the first chunk.
A: Since this API activates extra checking in the Windows heap manager, your sub-allocator won’t necessarily get much benefit. If you want to harden your implementation, make sure your allocator doesn’t include complex control structures or pointers in each block header. While we’re on the subject, is it crucial for you to have a sub-allocator anyway?