Full Disclosure mailing list archives
Re: Who's to blame for malicious code?
From: Tobias Weisserth <tobias () weisserth de>
Date: Wed, 21 Jan 2004 19:53:46 +0100
Hi Paul, Am Mi, den 21.01.2004 schrieb Paul Schmehl um 06:53:
...The two examples I gave in my initial answer to you actually contain that. I wonder why you didn't comment on them. What's your opinion on an enabled RPC port by default in consumer OSs?Precisely the same as my opinion of shipping the OS with inetd running and chargen, finger, et. al. enabled. It's stupid.
We agree. But shouldn't you point out that the Unix system administrator as targeted end user of Unix servers or any server OS in general has a different level of education than the consumer end user who is confronted with the same problem? The administrator _does_ know what kind of attention security deserves. The end consumer doesn't even know what a "port" is. That's what you missed here.
But we know that *now*, don't we? We obviously didn't know that a few years ago, or all the *nix vendors wouldn't have done that years ago, right?
Again: consumer end users != Unix system administrator And yes, we know by now. Then why is it so hard to demand "secure by default" from MS for millions of consumer end users?!
Don't you think the simple measure of shipping Windows XP Home without such a service enabled would have stopped the spread of Blaster cold? I do.Of course it would have, but so would have appropriate OS maintenance.
No. By the time Blaster and its variants were on the way there didn't exist a patch. Besides, you didn't even have to _do_ something to catch it. I had a case where I couldn't even reach the MS update site before I already had it again by sheer presence on the Internet. Patch maintenance is good but it doesn't replace "secure by default" settings.
The only machines we had that got infected by Blaster and friends are those that ignored my many warnings *and* refused to participate in our push-patching program (either through ignorance or belligerence.) So, while Microsoft may be criticized for shipping RPC on by default, you really can't blame them for the results of the Blaster worm, simply because it was possible to be unaffected by it by updating properly.
You still don't understand the issue. If software requires action on behalf of the end users to avoid disaster and if this same disaster could have been avoided by proper software delivery (secure by default) then of course it is the vendors fault.
We have thousands of Windows machines running RPC, and none of them are infected because they've all been patched.
Well, then explain to me why Blaster was such a big hit on the net then? It can't be the end consumers fault. It's never the end consumers fault. Blaster could have been avoided by simply delivering Windows XP/2000 with a disabled RPC port by default.
It's high time for us to stop making excuses for stupid behavior simply because Microsoft is an easy target.
There is no stupid behaviour. When a user blindly runs an email attachment or forgets to patch his machine then this is not the users fault. The fact that such an uneducated user can actually use the product this way is to blame on the vendor. Products have to be fool-prove. It isn't the end consumers who have to be fool-prove.
*None* of the famous exploits and worms (Code Red, Nimda, Slammer, Blaster, Nachi, et. al.) would have ever happened had people simply updated their machines in a timely and regular manner.
Well, why don't they do it? Ever wondered if this whole problem isn't being caused at the users end?
We expect people to change the oil in their cars regularly.
People return their car to the garage when the little red indicator inside the cockpit blinks. I haven't seen a little red indicator in any MS product the way it is shipped by default. There isn't one single indicator inside MS Windows XP Home that tells consumers they are working with administrative access and that they have an open RPC port they should close.
Why don't we expect similar behavior in the computer world?
It isn't the same. That's the problem. Look at liability. A car manufacturer is always liable up to a certain amount and within a certain period of time. Software manufacturers aren't liable. They dismiss liability in numerous different EULAs.
Would you blame OpenBSD if a user got hacked because he hadn't bothered to patch?
OpenBSD isn't aimed at the consumer, it is aimed at the system administrator. The point why I brought up OpenBSD is that even if the Apache ports package shipped with OpenBSD causes the risk of system compromise due to a bug then this isn't tragic because only those users actually running Apache have to care. Other users don't bother since OpenBSD comes with minimum enabled services. That's what makes it different from MS. You fail to recognise that.
I'm not arguing that Microsoft has done the right thing or even that their OS is secure. (It isn't, and I refuse to use it as a server unless forced to. I prefer to use FreeBSD whenever possible.)
This is a totally different matter, but I agree with you ;-)
I'm arguing that you can't blame Microsoft for malicious code that takes advantage of weaknesses for which they have already issued patches, sometimes 12 months in advance of an outbreak.
But sometimes weeks after first exploits have shown up. There are still numerous unfixed flaws in IE6 and beneath that can be exploited. And I have to say it again: if an exploit could have been avoided by simply shipping the OS with minimum enabled services, reducing the need for immediate end user involvement, then the vendor has utterly failed. There is no compromise to this.
*That* is a problem directly attributable to users.
No. Users are never wrong. Get that into your heads techies. THEY are the customers, WE have to supply products THEY can use WITHOUT making these mistakes. If THEY fail to use OUR product the way WE intended to then it is OUR fault not THEIRS. It's as simple as that. I'm not talking about administered company LANs here, I'm talking about the consumer end user who wants things as smooth as possible. Products have to be fool-prove not the end user. This is an ideal and may never be reached. But nevertheless this has to be the essential design philosophy of ANY product.
What you're trying to argue is that, if OS vendors would simply do the right thing from the start, users would be protected despite their lack of patching, and I am saying that is preposterous.
It's not 100% that way but I stand by my statement that more than 75% of viral and worm outbreaks could have been avoided if attachments weren't executable out of email applications, if email applications didn't use the IE's buggy rendering engine together with scripts enabled and AvtiveX and if ports of unnecessary services were closed by default. The latest thing, Win32/Bagle-A wouldn't be possible if email client vendors and MS wouldn't allow the execution of attachments by default. There is no user "too stupid" to do the worst possible thing with his PC yet not realising it. This must be in developers mind when designing software, nothing else. MS has failed utterly at this.
*No* OS is so secure that you can simply leave it on the Internet, never patch it, and still be secure.
I am not propagating against patching. I am propagating against "opting into security". cheers, Tobias _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- Who's to blame for malicious code? Schmehl, Paul L (Jan 20)
- Re: Who's to blame for malicious code? Tobias Weisserth (Jan 20)
- Re: Who's to blame for malicious code? Paul Schmehl (Jan 20)
- RE: Who's to blame for malicious code? Steve Wray (Jan 21)
- Re: Who's to blame for malicious code? Ron DuFresne (Jan 21)
- Re: Who's to blame for malicious code? Tobias Weisserth (Jan 21)
- Re: Who's to blame for malicious code? Paul Schmehl (Jan 20)
- <Possible follow-ups>
- Who's to blame for malicious code? Schmehl, Paul L (Jan 20)
- RE: Who's to blame for malicious code? Brent Colflesh (Jan 20)
- RE: Who's to blame for malicious code? Schmehl, Paul L (Jan 21)
- RE: Who's to blame for malicious code? Tobias Weisserth (Jan 21)
- Re: Who's to blame for malicious code? Vlad Galu (Jan 21)
- RE: Who's to blame for malicious code? Ron DuFresne (Jan 21)
- RE: Who's to blame for malicious code? Schmehl, Paul L (Jan 21)
- RE: Who's to blame for malicious code? Tobias Weisserth (Jan 21)
- Re: Who's to blame for malicious code? Tobias Weisserth (Jan 20)