MSDN Magazine - November 2008 - (Page 47)

Bug #3 (could be any language—example is in C#) byte[] GetKey(UInt32 keySize) { byte[] key = null; try { key = new byte[keySize]; RNGCryptoServiceProvider.Create().GetBytes(key); } catch (Exception e) { Random r = new Random(); r.NextBytes(key); } } return key; compiled with /analyze. If you said, “Not a security bug,” give yourself one point. Bug #5 public class Barrel { // By default, a barrel contains one rhesus monkey. private static Monkey[] defaultMonkeys = new[] { new RhesusMonkey() }; // backing store for property. private IEnumerable monkeys = null; public IEnumerable Monkeys { get { if (monkeys == null) { if (MonkeysReady()) monkeys = PopulateMonkeys(); else monkeys = defaultMonkeys; } return monkeys; } } Answer There are two bugs in this lousy key-generation code. The first is pretty obvious: if the call to the cryptographically sound random number generator fails, the code catches the exception and then calls a truly lousy and predictable random generator. If you spotted this, give yourself a point. It’s an SDL requirement to use cryptographically random numbers to generate keys. But there’s another bug: the code catches all exceptions. Other than in rare instances, catching all exceptions—whether they are C++ exceptions, Microsoft .NET Framework exceptions or structured exception handling on Windows—hides real errors. So don’t do it. A structured exception handler in C or C++ that catches all exceptions (including access-protection faults such as buffer overruns) will yield a C6320 warning when compiled with /analyze. It was this kind of design that let attackers reattempt their attacks against the animated cursor bug MS07-017 (see blogs.msdn.com/sdl/archive/2007/04/26/ lessons-learned-from-the-animated-cursor-security-bug.aspx). If you spotted the exception-handling bug, give yourself one more point. } Answer This is a hard one. The author of this class thinks that Bug #4 void func(const char *s) { if (!s) return; char t[3]; memcpy(t,s,3); t[3] = 0; } they are being both safe and efficient. The backing store is private, the property is read-only, and the property type is IEnumerable , so the caller cannot do anything but read the state of the Barrel. The author has forgotten that a hostile caller can try to cast the return value of the property to Monkey[]. If there are two Barrels and each one has the default Monkey list, then a hostile caller that has one of them can replace the RhesusMonkey in the static default list with any other Monkey, or null, thereby effectively changing the state of the other Barrel. The solution here is to cache a ReadOnlyCollection or some other truly read-only storage that protects the underlying array from mutation by a hostile or buggy caller. If you got this, give yourself two points. Bug #6 (C#) protected void Page_Load(object sender, EventArgs e) { string lastLogin = Request["LastLogin"]; if (String.IsNullOrEmpty(lastLogin)) { HttpCookie lastLoginCookie = new HttpCookie("LastLogin", DateTime.Now.ToShortDateString()); lastLoginCookie.Expires = DateTime.Now.AddYears(1); Response.Cookies.Add(lastLoginCookie); } else { Response.Write("Welcome back! You last logged in on " + lastLogin); Response.Cookies["LastLogin"].Value = DateTime.Now.ToShortDateString(); } } Answer We found a bug like this one a few years ago in Windows Vista while it was still in the process of being developed. But is this a security bug? Obviously it’s a coding bug because the code writes to the fourth array element, and the array is only three elements long. Remember, arrays start at zero, not one. I would contend that this is not a security bug because the attacker has no control whatsoever. If the bug looked like this where the attacker controls i, however, then that would mean the attacker could write a zero anywhere in memory. And that’s a card-carrying security bug: void func(const char *s, int i) { if (!s) return; char t[3]; memcpy(t,s,3); t[i] = 0; } Answer This is a straightforward, cross-site scripting vulner- This code yields a C6201 “out of valid index range” warning when msdnmagazine.com ability, the most common vulnerability on the Web. Although the code seems to imply that the lastLogin value always comes from a cookie, in fact, the HttpRequest.Item property will prefer a value from the query string over a value from a cookie. To put this another way, no matter what the value of the lastLogin cookie happens to be set to, if an attacker adds the name/ value pair lastLogin= to the queNovember 2008 47 http://blogs.msdn.com/sdl/archive/2007/04/26/lessons-learned-from-the-animated-cursor-security-bug.aspx http://blogs.msdn.com/sdl/archive/2007/04/26/lessons-learned-from-the-animated-cursor-security-bug.aspx http://www.msdnmagazine.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - November 2008

Contents MSDN Magazine - November 2008 Toolbox CLR Inside Out Data Points Cutting Edge Security Briefs Test Your Security IQ Agile SDL Access Control Utility Spotlight RIA Test Run Wicked Code Foundations Team System End Bracket

MSDN Magazine - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.