News and commentary from the cross-platform scripting community.
|
||
|
Mail Starting 7/1/98 | |
Great DaveNet today. I'm glad you decided to send it out. Personally, I'm amazed that the other web server vendors didn't jump in immediately to test their software when this exact problem was discovered in IIS over a year ago. I remember it being a pretty big deal, and it seems to me that Microsoft's problem with it would be notice enough. Hopefully they learned their lesson, and they'll watch for bugs in IIS for more than just marketing rhetoric.
From: adams@csc.smsu.edu (David Adams);
Sent at Wed, 1 Jul 1998 13:58:06 -0700;
Re:Security Hole in Windows Web ServersHere's what really happened on the March 11. When Netscape and AOL were signing the deal, the Netscape lawyer asked AOL if they were talking to Microsoft regarding a similar deal.
From: anonymousSource@random.net (Name withheld);
Sent at Wed, 1 Jul 1998 12:46:50 -0700 (PDT);
The AOL-Netscape dealHe said they heard that AOL was considering using Microsoft's browser too, but the AOL guys denied any discussions with Microsoft and assured them that there were no talks between AOL and Microsoft.
The Netscape people were confident. A few hours later, AOL fucked Netscape so hard, you could hear the scream all the way to the Orion galaxy.
Just so you know (and you might want to pass this on as well) this "hack" doesn't work with Cold Fusion pages. I have several login systems that use Cold Fusion and none are susceptible to this trick
From: zac@pixelgeek.com (Zac Belado);
Sent at Wed, 1 Jul 1998 11:00:17 -0700;
Re:Security Hole in Windows Web Servers
Regarding the Windows web server security hole, I honestly don't understand how anyone can characterize this as anything other than a bug in the Windows file system. The sheer fact that it shows up in so many places (historically in IIS, currently in Netscape's, O'Reilly's, and Sun's products) rather strongly suggests that these various vendors didn't do anything wrong as we commonly understand that notion in software engineering today. In fact, the fact that IIS had the problem suggests that even within Microsoft, the IIS engineering group made the same perfectly reasonable assumption about how the file system works that other engineering groups have apparently made.
From: psnively@rdoor.com (Paul Snively);
Sent at Wed, 01 Jul 1998 10:46:49 -0700;
Security HoleTo my way of thinking, it's nothing short of astonishing that a file system would report that "foo.bar" and "foo.bar." both exist, let alone that they both, in fact, name the same file but give the two "notions" of the file differing types! Does *any* other file system exhibit this behavior--even other file systems that use extensions to determine the type of the file, such as UNIX? I don't know of any. Microsoft says that developers should be familiar with this aspect of their platform's functionality, but is this behavior of the file system documented anywhere? Does this only affect the FAT file system, or does this affect NTFS as well?
I also have sympathy for the people who have responded to this by saying "we need some time to assess how best to address this issue," as opposed to rushing a "fix" for a problem that isn't clearly theirs out the door that may prove to not completely cover the issue (e.g., what if it turns out that there are other special characters that have the same effect)? It's extremely unlikely in important software such as server software that serious holes can be plugged in a timeframe measured in hours, and I frankly would respond to any vendor's claim to have done so with *extreme* skepticism as to whether they had, in fact, done their due diligence with respect to the issue.
As for the finger-pointing issue, it'd be nice to think it wasn't necessary, but to the extent that people rely on Netscape, O'Reilly, and Sun software, the customers' perception of the quality of that software is paramount, and those organizations have not only the right, but the responsibility to their investors, to reassure their customers that this is, in fact, not a bug in their software.
I think it's time to stop letting system software vendors off the hook over issues like this, to stop forgiving them when there's an obvious bug in their system that affects their own software development teams as well as external teams. The fact that the affected application team was able to apply a workaround early hardly comes as a surprise; the collusion between Microsoft system software and Microsoft applications hardly comes as a surprise, and given the increasingly blurry distinction between system software and applications could hardly be avoided anymore anyway. It's hard to see why external development groups should be expected to show the same rapid resolution of the problem
Why are people waffling as to where the problem lies and whose responsibility it is to fix it, and where?
Under Windows, the last period in a filename is not really a part of the filename -- it's a metacharacter, like the colon that separates the drive specifier from the rest of the name, or the slashes and backslashes that separate directories and server names. The last period separates the filename from the filetype, a holdover from TOPS-10 and CP/M, from which early MS-DOS derived file-handling routines. (These CP/M-derived file-handling routines are responsible for the current hole in MS Office 98 for Mac in which Word ignores "logical end-of-file" and doesn't clear certain bytes on disk, so if you e-mail a Word document to someone, you may unwittingly include whatever was previously on the disk, such as an old Quicken file -- logical end-of-file is a CP/M-ism.)
From: petej@clickvision.com (Peter M. Jansson);
Sent at Wed, 01 Jul 1998 13:13:05 -0400;
CP/M still haunts us!Unix doesn't suffer the web server problem because a period in the file name is just that -- a period in the file name. Should the web server vendors have realized this and handled periods-as-metacharacters? Probably, but in practice, most programmers no longer treat periods as metacharacters (Unix wins!), so most programmers have forgotten about it. Meanwhile, it means developers must have special code in Windows versions of software to deal with periods-as-metacharacters, unless Microsoft finally does away with the little-used periods-as-metacharacter behavior. In short, if MS "fixed" the periods-as-metacharacters thing, then there wouldn't be an issue for IIS or Netscape or Website (or Frontier?) on Windows. Meanwhile, the server vendors will have to compensate. Customers aren't winning yet.
[DW: This is not a problem for Frontier.]
Fascinating, indeed. I remember when these events were unfolding: it seemed like the 'net business world was shifting, as indeed it was.
From: TuckerG@sandellmgmt.com (Tucker Goodrich);
Sent at Wed, 1 Jul 1998 12:24:43 -0400 ;
How Steve Case bought a browserThe lesson I draw from this morality play? MS and AOL are on top of the world for a reason. They're willing to eat there own, including their own words, if that will get them ahead in the bigger picture. Netscape let pride, greed, and emotion get in the way of doing business, and now they're paying the price. It wouldn't have cost them a dime to give Navigator to all the AOL users, and it could have shut out MS.
I hope Joel Klein at DOJ reads this--it demonstrates how MS really won the browser war--they fought harder, and listened to the customer better, than the competition.
If you run a Netscape or O'Reilly web server your LAN might be open to easy hacking. This was first reported on Saturday on News.com. And yesterday it was revealed that Java running on Windows has the same problem.
From: alex@stinky.com (Alex Chaffee);
Sent at Wed, 1 Jul 1998 07:52:05 -0700;
Re:Security Hole in Windows Web ServersWhoa! Hang on. It's not Java that has a problem. It's the Java Web Server, which is a product from Sun.
This is very clearly a problem with the web-server vendors, not Microsoft. This is an old bug they fixed in IIS a long time ago. The problem lies with web sites that have an architecture that requires passwords in ASP, instead of in a middleware layer, and in the vendors that are slow to release a patch.
From: bdrobert@Sage-Enterprises.com (Brian Robertson);
Sent at Wed, 1 Jul 1998 07:48:38 -0700;
Re:Security Hole in Windows Web ServersDon't be too hard on MS for this one--I remember when this exploit was publicized for IIS--all the MS haters said, "See! Microsoft can't do this! They screwed up!" All the people in the website development community were saying this is the reason you should stick w/ Netscape for server software. Oops!
From: TuckerG@sandellmgmt.com (Tucker Goodrich);
Sent at Wed, 1 Jul 1998 09:49:04 -0400 ;
Re:"Security Hole"I guess they never bothered to check and see if their own systems had the same problem. Pretty pathetic. What's the old saying? "Pride goeth before the fall?"
