>interesting article, and yet, I can't see a reason to fault either >guninski or danka at this point in the game. M$ is not known for it;s >handeling of researchers caught falws in itps codes and apps well,
No reason to fault either of them, even though Danka completely failed to use the security contact that is linked at http://www.microsoft.com/security/, and Guninski has repeatedly failed to offer vendors anything more than mere days to fix bugs -- if they are notified at all! You may remember that Guninski completely failed to notify the VIM development team of security vulnerabilities in its product, and these were brought up by a third party on VIM-DEV for the first time. I would have understood CC'ing the major security lists with the post *in addition to* vim-dev, as it *is* a public channel. However, there simply is no excuse for the pathetic practice of ignoring useful communication channels, when provided, in favor of saying that "vendors need to step up to the plate". There simply is no defense for complete lack of notification attempts, particularly as Guninski has *no history* of reporting bugs to vim's maintainers, and would therefore have *no idea* of how responsive the vendor was. Karsten Hopp's message to the vim-dev list regarding Guninski's find is available at: http://marc.theaimsgroup.com/?l=vim-dev&m=104039305513986&w=2 and contains the following message, entitled, "vim security bugs": "Hello, Georgi Guninski has published the modeline exploit at http://www.guninski.com/vim1.html Is anyone working on that or is there already a patch available to fix this ? I couldn't find any reference to such a patch in the list archives or in the README for the official patches." with the response from Christian J. Robinson a mere four days later, which contains an interesting quote: "I think this is the first time it's been mentioned here. I tried my hand at fixing it (patch against 6.1.263):" The message also includes a preliminary patch -- its full content is available at: http://marc.theaimsgroup.com/?l=vim-dev&m=104041876306910&w=2 Secondly, he writes in his advisories, things like "Some vim problems, yet still vim much better than windows" -- comparing an OS to text editor -- even as he admits that major security vulnerabilities exist in the product! If this isn't self-publicist behavior, nothing is. Guninski also bashes Microsoft and other proprietary vendors by saying "Microsoft was notified on 17 March 2002. They had 2 weeks to produce a patch but didn't." The simple fact is, even issues as simple as allowing script execution (which, in and of itself, cannot compromise a machine), are eventually fixed. The truth is that Guninski needs a variety of targets, and feels that he can do his part to insure the survival of open source by blasting Microsoft. After all, Guninski has not produced an advisory detailing a security vulnerability of any kind in a Microsoft product since July 31, 2002, so what right does he have to say that trustworthy computing is a flop? Clearly, Georgi Guninski couldn't get a job, and relying on the Apache 1.3 descriptor leak (shudders), or perhaps a local command execution bug in vim, or worse, a format string in the Etheral socks dissector, wouldn't get him anywhere. So, he has slanted every story he could get a hold of, turning a non-issue of one-month delays into ridiculous, childish, kiddies' rhetoric about MS' irresponsibility. Even funnier is that while he was making a major deal out of MS security being unresponsive, he wasn't even notifying open-source vendors of security vulnerabilities! Also, Bruce Schneier has little or no room to talk, as his "Password Safe" tool was unable to keep local passwords safe, let alone a large product base of network applications: http://www.safermag.com/html/safer41/alerts/29.html >and until vendors can stepup to the plate in the process, meaning that they >take reported accounts seriously enough to be 'part of the process', >which they tend to now avoid for various reasons and in various ways, they >can't expect the need for full disclosure to abate or diminish. No matter >how one views the whole disclosure debate, those holding most the cards >tend to be the vendors. And vendoor shell games tend to be the most >debilitating factor in the present standing and long debated disclosure >issue. Once again you rely on the assumption that vendors are irresponsible with security reports. While there have been instances of what some would consider lengthy delays on vendor responses, most of these are easily explained by the fact that the vulnerability is of negligable impact to the vast majority of the computing public, such as wildcard "A" records in FTP sites causing XSS. Even *I* will admit that the flaw was of a nature that meant it most likely could not be used to cause any serious damage that an attacker could not have caused without the vulnerability. Particularly given the existing security integrations of IE that prevent sub-domains and parent domains from interacting (as well as programs on different ports) without explicitly setting compatible document.domain values (not possible for services on different protocols/ports). >And we've not even mentioned the issue of 'responsibility' to >produce cleaner code, nor who should be held 'liable' for some of the >crappy applications that vendors push onto the public. Oh, please. You obviously have not attempted to develop any kind of software project, or if you have, if didn't get out of the planning stage. If you had ever developed any good piece of software, you'd realize that bugs *do* happen, no matter how many auditors and other developers peer review the code, and no matter what other steps you take. I'm sure Bruce Schneier could attest to that, unless of course crypto is always perfect the first time. Not only has Schneier failed disprove the fact that bugs *are* an inevitable part of software development, he has proven it himself. Now, if Schneier could at least be honest, and not insist that he is perfect (we all know he's not), this debate would be less about slanted, ridiculous spin, and more about the realities of software development. I also ask you to take into account the fact that altering a mindset takes time. Security vulnerabilities were all but ignored in the early days of single-user non-networked Win16. Those early days are the source of some of the Win32 message routines implicated in the recent "Shatter" attacks. Microsoft has had to work against buggy base code, and teams of developers who were never taught a bit about security. Essentially, Microsoft is working against its own history. For a company of Microsoft's size, this is not easy. For all of the work that requires, I'd say that Microsoft is doing a damn good job. And, in the meantime, instead of sitting and griping about how terrible Microsoft's code is, why don't you apply for a position as a project manager and fix it all? Oh wait, you wouldn't be able to deal with whiny sysadmins who never coded "Hello world" griping about your security? I understand. Well, maybe it'll help to remember that you were the same way once. Of course, you probably wouldn't even *GET* the position, as companies usually don't like project managers who sit and gripe all day long instead of proposing solutions and getting things done. As for your clueless ramblings about Microsoft's security practices, keep those to yourself -- unless of course, you enjoy showing people your complete lack of knowledge on the subject. P.S. - Haven't you learned how to trim a message yet, Mr. Dufresne? -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html