full-disclosure - Avoiding being a good admin - was DCOM RPC exploit (dcom.c)

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: <3F27FE50.22992.8C144DF@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Avoiding being a good admin - was DCOM RPC
 exploit (dcom.c)

Valdis.Kletnieks@...edu replied to Jason:

> You can harp on "best practices" all you want - hell, *I* certainly do

8-)

> it enough.  However, you have to come to some realizations here.  All
> "best practices" cost something to implement.  And at some point, the
> cost of prevention is going to exceed the cost of cleaning up.

That does tend to be the way things are now.

In turn, this may be because of Redmond's historic view that "so easy 
any idiot can make it work" was _the_ way to do things.  Remember all 
that "total cost of ownership" rubbish^H^H^H^H^H^H^Hpromotional 
material from back around the time of the Win95 launch through sometime 
after NT 4.0 shipped?  What that was about was "we have realized that 
many of the  people we really want running this stuff are too lazy/ 
stupid/etc to learn how to do it properly so we just turned everything 
on" (and, credit where it's due, they did improve the installers no end 
compared to pevious versions and much of the "competition" -- OS/2 was 
arcane in the extreme to install, even on half of IBM's own machines 
and most Linux distros were downright painful...).

Of course, that was before the much-heralded chest-beating known as 
"Trustworthy Computing".  Reputedly TC means that much of the stuff 
that was previously enabled by default (so the 3.917% of users of each 
feature wouldn't have to think about looking in a manual or on a web 
page to see what they had to do to enable some feature) will now be 
disabled "out of the box".  This change (if it really happens!) will 
alter the TCO in interesting ways, such that the initial minimum cost 
of "designing" anything but the most basic and straightforward desktop 
configuration machine will increase (i.e. many of the folk who run 
large networks of "out of the box" installs today will actually have to 
do some pre-rollout design to justify their pay-checks when Longhorn 
(??) eventually hits).  What the longer-term effects on the perceived 
additional costs of on-going patching, etc are is very much an open 
guess at this point...

<<snip much more good stuff...>>

Regards,

Nick FitzGerald