lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1093201004.28985.711.camel@localhost.localdomain>
From: dave at immunitysec.com (Dave Aitel)
Subject: Windows Update

Just as a point of reference, we actually do have a lot of Fortune 100's
doing similar things with CANVAS. (I.E. running a scan across their
entire space, and automatically patching any potentially vulnerable
hosts). Just so you don't think it's just HP. :>

-dave


On Sun, 2004-08-22 at 09:01, joe wrote:
> If that is your stance, you should probably have it for AV updates as well.
> There have been various AV updates that have been known to break
> functionality and blue screen boxes. I recall one update for one of my
> customers that had blown up a good many web servers and local site file and
> print servers (hundreds of servers) and this is with an AV Update that was
> approved by and placed on the distribution server by central security. 
> 
> Anyway, versus completely shutting down WU, you can configure to automatic
> download without installation. 
> 
> All that being said, actively professionally maintained servers are in a
> different boat than most machines that will be running WU. In a large
> properly firewalled and protected corporate environment, I don't think the
> client support group would really depend on automatic updates from outside
> the company, they would use SUS or some other deployment mechanism. If using
> some other deployment mechanism, WU would be off. Either way, patches would
> be tested before being deployed, it wouldn't be automatic. 
> 
> That being said, once you get to x machines with x being a function of your
> resources available to do testing, the number of LOB apps you have running,
> and how bad the hole is being plugged you will run into occasion where you
> can not test everything and simply have to release. One would hope that this
> will be less frequent if you have XP SP2 deployed and have the firewall up
> and running without turning it into swiss cheese but until we see the next
> worm type attack and see if XP SP2 is safer we can't for sure say anything.
> If the biggest issues end up requiring some sort of people interaction, then
> that is quite a win in and of itself. 
> 
>   joe
>  
> 
> -----Original Message-----
> From: full-disclosure-admin@...ts.netsys.com
> [mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of ?ber GuidoZ
> Sent: Saturday, August 21, 2004 7:56 PM
> To: FD
> Subject: Re: [Full-Disclosure] Windows Update
> 
> Umm, hold on a sec here... 
> 
> (snip from "James Tucker"):
> > There really should be no reason why you would want to disable the  
> >Automatic Updates service anyway, unless you are rolling out updates  
> >using a centralised distribution system, in which case you would not 
> >need it anyway.
> 
> I believe you are missing one fundamental point: SPs and updates are
> notorious for breaking something else. (Especially from Microsoft.) Granted,
> if fixing a security weakness breaks something you're using, then that
> aspect could have been written better. However, that still doesn't fix it
> when an entire business network goes down and YOU are the one responsible. I
> do not allow ANY automatic updates (except for virus definitions) to run on
> ANY networks I am in charge of. I take the time (like every good sysadmin
> should) to look over each update before applying it so I know three things:
> 
> 1. What it's fixing/patching
> 2. Why it's fixing/patching it
> 3. What will be the end result of the fix/patch
> 
> If you would simply allow updates and SPs to have free reign over your
> system(s) without taking any time to look over those updates, you're going
> to be one busy and irritated sysadmin. That is, if you still have a job
> after a little bit.
> 
> ~G
> 
> P.S. Don't take my word for it. Look here:
>  - http://www.infoworld.com/article/04/08/12/HNdisablesp2_1.html
>  - http://www.pcworld.idg.com.au/index.php/id;1183008015;fp;2;fpid;1
>  - http://www.integratedmar.com/ecl-usa/story.cfm?item=18619
>  - http://www.vnunet.com/news/1157279
>  - Or, find the other 200+ articles by searching Google News
>     for "disable automatic update sp2"  =)
> 
> On Sat, 21 Aug 2004 18:51:40 -0300, James Tucker <jftucker@...il.com> wrote:
> > Here I found that I can have BITS and Automatic Updates in "manual", 
> > Windows Update works fine here. It may be a good idea to refresh the 
> > MMC console page, as you will probably find that at time the service 
> > had shut down if and when BITS was stopped prematurely (i.e. when it 
> > was in use).
> > 
> > There really should be no reason why you would want to disable the 
> > Automatic Updates service anyway, unless you are rolling out updates 
> > using a centralised distribution system, in which case you would not 
> > need it anyway.
> > 
> > If you are worried about system resources, you should look into how 
> > much the service really uses; the effect is negligable, in fact there 
> > is more impact if you select (scroll over) a large number of 
> > application shortcuts (due to the caching system) than if you leave 
> > Automatic Updates on. If you are worried about your privacy and you 
> > dont believe that the data sent back and forth has not been checked 
> > before, then you surely dont want to run Windows Updates ever. If you 
> > want to cull some real system resources and have not already done so, 
> > turn the Help and Support service to manual, that will save ~30mb on 
> > boot, up until the first use of XP help; this will stop help links 
> > from programs from forwarding to the correct page, until the service 
> > has loaded once.
> > 
> > As for worry over using bandwidth on your internet service, again, you 
> > want to check this out as its a trickle service, not a flood. BITS 
> > does not stand for Bloody Idiots Trashing Service; it means what it 
> > says on the tin.
> > 
> > On Fri, 20 Aug 2004 14:30:22 -0700, David Vincent
> > 
> > 
> > <support@...epdeprived.ca> wrote:
> > > joe wrote:
> > >
> > > >Yep, this is how it works now.
> > > >
> > > >You control whether Windows Update is updating or not via the 
> > > >security panel in the control panel applets (wscui.cpl).
> > > >
> > > >
> > > To eb complete, I should have mentioned I have Automatic Updates 
> > > turned off in the control panel.  I also had the service disabled 
> > > before applying SP2 and venturing to Windows Update v5.
> > >
> > > >Of course if you aren't using automatic update you could always 
> > > >disable the service and just reenable when you go to do the update, 
> > > >or don't use windows update at all and just pull the downloads 
> > > >separately. We are talking about a single command line to reenable 
> > > >that service
> > > >
> > > >
> > > Yep.
> > >
> > > >Is it a pain? Yes, for those who like to run minimal services. Is 
> > > >it a security issue or life threatening, probably not.
> > > >
> > > >
> > > Agreed.
> > >
> > > -d
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> > 
> 
> 
> --
> Peace. ~G
> 
> _______________________________________________
> 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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ