Re: MS Anti Virus?

[Steffen Schumacher <ssch () wheel dk>]

On 17.06.2004 11:51:46 +0000, joe wrote:
> However the worms would be blocked if people had patched their machine or
> otherwise properly administrated the machines they were responsible for. All
> of the worms that I think you are probably referring to all had patches well
> in advance of the worm that impacted it, blaster, slammer, sasser, etc. 

Agreed.
I'm not saying that MS doesn't provide patches - they do.
I simply think that the amount of bugs in MS' OS' are to great. 
If you install windows and attempt to either patch it or install firewall
afterwards while on the live internet - Your chances of getting infected
are quite high. The time it takes to install patches or a firewall may in
some situations be longer then it would take for a user to get infected.

I picture it a bit like a para trooper which has noo means of defense until
he lands and can take cover.
Other OS' like FreeBSD take a different approach. All non vital services are
disabled until the user explicitly installs or enables them.

Microsofts products should provide the means to a secure patch before risky
services like DCOM are enabled.
This should in fact be the case everytime a MS pc starts up.
Otherwise a pc which has been offline for a period may become infected while
patching. 

But ultimately MS have to catch more of their serious bugs before releasing 
their software. Consider how many resources that are spent on patching.
Could they have been spent revising code in stead?
I wonder what the average load on the windows update server park is...


> Home users never should have been impacted as they should be running
> firewall software on the internet connections. The fact that they don't
> isn't MS's fault, however MS is stepping up with XP SP2 to help out. On top
> of that they should be patching when necessary.
>
> Corporate users shouldn't have been impacted either and were only because
> the IT department didn't keep the machines patched properly. Too many
> companies run on a deploy and forget strategy, this doesn't work for any OS
> be it Windows, *nix, or ios. I am not saying keeping them patched is an easy
> task, I managed 400 servers in a Fortune 5 company that were distributed
> around the world. None of them ran antivirus, none of them got infected by
> either viruses nor worms, none of them allowed any but only a small number
> of people to have admin rights to do harm to them. When a patch came out
> that affected those servers, it was on the machines in a rather quick
> fashion, generally within 72 hours depending on testing times. 
>
>
> Thinking that there will never be code patches required isn't realistic. It
> is humans writing the code and even the humans writing the other Oses make
> mistakes and need to release patches. If the people who manage the machines
> don't take the time to apply the patches then the issue isn't an MS issue,
> it is an admin issue. 
I know. I just wan't fewer. When you sell these amounts of functionality
which is reused in multiple future software, then one should *REALLY* test
it better, or lower the prices.
 
> > The *real* IT department could then link to the 
> > executeable and place it on an intranet server 
> > which would be secure.
>
> This is an interesting idea but I can't see how one could do it in a
> feasible manner in a large company that is receiving hundreds of thousands
> of emails from the outside a day. Also you would have to watch for internal
> emails and attachments as well because you could get an infected machine on
> the inside. Now in large companies you are up to millions of emails. 
>
> My recommendation to the email manager at the time of the last major
> outbreak where they started just stipping all ZIPs from emails was that they
> strip ALL attachments that didn't have a specific internally defined
> extension on them, that way they knew it was a purposeful thing that that
> attachment was there. The extension would be something specific to a company
> and people involved know that extension. Obviously this is just a crutch to
> block the issue with well known executable file extensions. 
>
> The file associations are a tough thing to repeal since they are so deeply
> embedded in how things are done on Windows and people have gotten so used to
> them; it made life easier for a majority of the users and was a great idea
> at the time. Now however, if you, for instance, removed the DOC extension
> from the file associations half the corporate Windows Admins out there would
> be at a complete loss as to why Word wasn't working... Those bad Windows
> Admins are partially MS's fault, but mostly the fault of companies who look
> for cheap admins versus good admins. 
>
>   joe
>  
>
> -----Original Message-----
> From: Steffen Schumacher [mailto:ssch () wheel dk] 
> Sent: Thursday, June 17, 2004 10:43 AM
> To: joe
> Cc: full-disclosure () lists netsys com
> Subject: Re: [Full-disclosure] MS Anti Virus?
>
>
> While I have no numbers to back this up, I do think that worms are far worse
> when it comes to the extent of which viruses spread, and speed.
> It is my belief that most worms are based upon MS exploits, rather then
> social engineering. 
>
> It is my belief that we will simply have to wait untill MS cleans up their
> act, which they should be doing, before the world becomes a better place to
> live.
>
> I realize that this doesn't clear situtations like the one above, but in
> general such situations can't really be solved unless all mails are scanned
> extensively, and / or the people are educate enough so that they never
> should run executeables recieved from mail (its actually quite simple to
> me). The *real* IT department could then link to the executeable and place
> it on an intranet server which would be secure.
>
> /Steffen
>
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html