http://blogs.msdn.com/ericlippert/archive/2003/09/23/53076.aspxThe other day I mentioned my worst customer-impacting mistake ever -- marking a heavily used object with the wrong threading model. A number of people commented to me that it was unusual to see a developer own up to such a mistake in a public forum. (Surprisingly,en-USCommunityServer 2.1 SP1 (Build: 61025.2)http://blogs.msdn.com/ericlippert/archive/2003/09/23/53076.aspx#53077Tue, 23 Sep 2003 23:43:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:53077DeadprogrammerEvery time I look at the Citicorp building I think that the <a href="http://deadprogrammer.livejournal.com/2003/04/15/">only thing that is holding it up</a> is the integrity of it's architect. By the way dictionary object thing is nothing compared to ::$DATA thing. I had a lot of fun looking at other people's code when that happened.http://blogs.msdn.com/ericlippert/archive/2003/09/23/53076.aspx#53078Wed, 24 Sep 2003 00:23:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:53078BlakeDespite how easy it was to exploit, ::$DATA was really a pretty subtle bug to catch. The fact that NTFS supports multiple named streams per file has always been little known or understood. The fact that the 'main' stream is named :$DATA was never documented at all as far as I'm aware. I'm sure the people on the IIS team who wrote the URL cracking code had no reasonable way to know that it was named such.http://blogs.msdn.com/ericlippert/archive/2003/09/23/53076.aspx#53079Wed, 24 Sep 2003 02:57:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:53079Eric LippertThe fundamental problem wasn't the $DATA vulnerabilty. The fundamental problem was that the guys who wrote the URL cracking code _failed to an insecure mode due to a canonicalization error_. The fact that $DATA happened to be the vulnerability that was found is actually kind of irrelevant -- when you make decisions based on noncanonical data you invite these kinds of problems. I talked about this quite a bit in my book actually.http://blogs.msdn.com/ericlippert/archive/2003/09/23/53076.aspx#53080Wed, 24 Sep 2003 07:57:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:53080BlakeI agree whole heartedly about 'fail safe', in the original sense of the phrase. The importance of that as a design point can't be overstated. That said, I don't follow why that was strictly a canonicalization error. They are valid path characters per rfc1738 and it's updates. It's a valid Win32/NTFS path as well. Why _should_ they be canonicalizing it? Hmm, on the other hand, what is broken is when I think about it is extracting the extension and hence type. Actually, there's lots of interesting questions there... clearly the streams within a file have different types. The stream containing document properties shouldn't be passed to the ASP engine even thought it's file extension is .ASP. Okay, I'm just rambling now, ignore me.http://blogs.msdn.com/ericlippert/archive/2003/09/23/53076.aspx#53081Fri, 26 Sep 2003 04:05:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:53081Peter TorrI thought we transformed code into money...? :-) As to the :$DATA thing. I was actually thinking the other day (for reasons that are beyond me) that it would be "cool" to get IIS to scan the entire wwwroot folder (and any other vroots) and keep all known filenames in memory. Then whenever it got a request, it would merely check if the name was in its list, return it if it was, or reject it if it was not. This (in theory) would stop many information leakage errors, because (i) there's no attempt at canonicalisation, and (ii) IIS never says "Oi! Mr. Windows, Can you load this 'ere file for me?" It only loads files that it knows are good and safe, using the exact same filenames it retrieved from the filesystem search itself. Just a thought, although the perf / memory impact is probably quite bad..http://blogs.msdn.com/ericlippert/archive/2003/09/23/53076.aspx#107380Sun, 04 Apr 2004 20:59:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:107380Fabulous Adventures In Coding