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]
Date: Fri Aug 19 00:01:38 2005
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: It's not that simple... [Was: Re: Disney Down?]

fd@...nsci.us to Ron DuFresne:

> > Perhaps it does realte considering the above and considering that the unix
> > world learned many of the evils of RCP services over ten years ago that
> > seem to hit the M$ realm every few months, repeatedly...
> 
> We used to call them rsploits when it was common in unix.  Friends and I
> had a good chuckle when MS started repeating history, having rsploits of
> its own.  I would love to deny all port 445 with layer-3 switches but this
> would be like blocking portmap and expecting NFS to still mount.
> 
> What have we learned from the past that we can apply to our MS networks,
> since they have become a (un)necessary evil?  How neutered does an MS
> workstation become if the RPC port is completely blocked from the outside?  
> Perhaps "mostly harmless" ? 
> 
> What would it take to write an RPC filter to only accept RPCs which we
> actually care about?  In addition, why is PnP even an RPC accessible from
> the outside (no, upnp is not a good reason)!?  Most importantly, we need
> to eliminate the entire RPC attack vector in the future for Microsoft
> systems -- this is not the first MS rsploit and we will certainly see
> more.

Why don't folk -- well, sys-admins anyway -- actually take the time to 
bother to learn what their systems do and how they work???

OK, MS does not make this astoundingly easy in many cases, but there 
are some very good (amongst some very, very poor) "hardening guides" 
out there written by folk who do know what they are talking about AND 
that explain why you should use, or at least might consider, each 
option, and why some options are only suitable in certain scenarioes.

Of course, when it comes to OSes like XP Home, the security stance has 
always been "everything that has worked before must keep working" so, 
rather than learning from their long history of mistakes and fixing 
things, MS compounded those mistakes by rolling them all together in a 
nice shiny new box with an even bigger marketing budget...

SP2 shows that, in fact, after too many, too embarrassing, too big to 
hide from the media virus and worm outbreaks due largely to the fact 
that it had been taking this entirely irresponsible approach to 
security (especially for those of its customers who needed the most 
help with such things), even the 800lb Gorilla known as Microsoft _can_ 
change.  We won't debate how much and whether it's enough, though I 
doubt few here would disagree that "there's a fair way to go yet" 
pretty much covers it...

Instead of making an everything on, working out of the box, approach 
even MS may be working its way to the "only enable it if it's needed 
for basic functionality" approach.

Of course, when MS gets to that position, there will then be hell to 
pay when the installation scripts for most third-party apps, drivers, 
etc start undoing all MS' good work and do the "set everything on 
because we know our cr*ppy product works if it is set that way".


Regards,

Nick FitzGerald

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ