Michael Howard on Safer CRT

Mike Howard posted a little item on Safer CRT and the relationship between DevDiv (Developer Division) and SBU (Security Business Unit). He promises more posts on security features in Whidby. I get to work with both groups on a regular basis and it's nice to see the great stuff that can come from this sort of cross-group collaboration. The post is here:

Security Stuff in Whidbey - The Safer CRT

There has always been a very strong relationship with our team and the developer division (aka DevDiv), in part because they take some of our ideas and turn them into solutions that can be used by our developer customers. And I want to take an opportunity over the next few days to outline some of the excellent security stuff added to Whidbey, most of which you will see when beta 2 ships.

One of my favorites is a more up-to-date C runtime library, dubbed the Safer CRT. Let's face it, the CRT of 20 or so years ago has turned out to be a little, well, challenging to use from a security perspective. When David and I wrote Writing Secure Code we wrote an appendix describing "issues" with certain functions in Windows and the CRT. The CRT library folks, under the watchful eye of Martyn Lovell, decided to fix the "Appendix A Problem" and they did so with the Safer CRT.

Comments (2)
  1. Brian,

    We’ve known for years how to make a Safer CRT. What we don’t know how to do, though, is to get rid of all the programs that are using the existing CRT. This is a problem for both Windows and for Unix.

    Remember Sun’s proposal a few years ago to rewrite Unix in Java? It failed. The reason is that there is extremely little incentive to undertake the massive rewriting effort needed for what seem like largely pedagogical reasons.

    There are many cases where the printf() and sprintf() and memcpy() and strcpy() calls in existing programs will never fail. Why should they be rewritten to use safer constructs?

    This is what is behind Microsoft’s code annotation effort, of course. The idea that "safe" invocations of "unsafe" function calls are checkable. (You can’t tell if something is always unsafe, you can’t tell if all things are safe, but you can say that some times are always safe. This is an application of Turing and Rice.)

    Personally, I’m on the other side of the fence. I believe that we should be systematically removing things from CRT and other widely used platforms. This is the best way to deal with the legacy code problem: kill it. But that takes discipline that Microsoft, Sun, Linus, Stallman and others have been unwilling to push onto their customers.

    How is the weather out in Redmond?

  2. Hi Simson,

    The weather has been cold, rainy, and sunny at the same time. Very mixed. 🙂

    While I understand your thoughts on this, I personally think we need to remain pragmatic about the large amount of legacy code that gets recompiled into updated applications. By depreciating some of these functions we can spit out compiler warnings and developers can decide whether they want to rewrite the affected code in their applications. (I believe that the next version of MFC is being compiled using some of these updated functions.) While this approach wont guarantee that you’ll write completely safe code, it does make it easier to write safer code. You should check out the comments in Mike’s series on this subject. He’s studied this a lot more deeply than I have.

    While I agree in principle that re-engineering sounds like a good idea, I don’t think it works that well in practice. We (developers) end up having to relearn everything that the original code writer had to learn to write the code in the first place. These are some of my favorite articles on that subject:




    I really appreciate you taking the time to share your thoughts on this. Please feel free to drop me a note anytime at brianjo@microsoft.com if you want to contact me directly.



    BTW: Go Patriots! 🙂

Comments are closed.

Skip to main content