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
- Anonymous
February 05, 2005
The comment has been removed - Anonymous
February 05, 2005
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:
http://www.igeek.com/articles/History/CoplandAndNeXT.txt
http://www.joelonsoftware.com/articles/fog0000000069.html
http://www.jwz.org/gruntle/nomo.html
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.
Cheers,
Brian
BTW: Go Patriots! :)