full-disclosure - Gates: 'You don't need perfect code' for good security

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: <3FA648AA.31949.D053D74@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Gates: 'You don't need perfect code' for good
 security

"Matthew Murphy" <mattmurphy@...rr.com> wrote:

<<humungous snip>>
> > Really simple change MS could do that would instantly make ALL their
> > software more secure (not secure but more secure than it is). Have it
> > install to random paths. So instead of everyone knowing right where the
> > directories are, each program would install to a random named directory
> like
> > /program files/program88475 where the number is random. Now things like
> > codered would have failed along with dozens of other exploits that rely on
> > knowing the path. So simple yet this thought has escaped MS thus far..
> 
> Code Red wouldn't have failed -- possibly Nimda, but not Code Red.  In
> addition, this kind of thing inhibits the ability to quickly reproduce
> changes on multiple machines -- essential for patching.  And, if one was to
> install in such a manner, the information about the paths would have to be
> kept *somewhere* in order to locate the program again.  Once again, the
> system is exploitable.

True, but it is not being suggested as a panacea or fix-all.

It is yet another simple way to raise the bar.  Don't install the OS 
into (C:)\WINDOWS (or \WINNT or other "too obvious" things like 
WIN2000, WIN2K, WINXP, etc, etc, etc) and relocate "critical" install 
directories such as "Program Files and so on.  Yes, that information 
has to be stored in the registry and thus can (and must) be returned by 
all manner of APIs available to all manner of code, BUT it still beats 
lots of exploits "abstracted" from those APIs.  For example, an awful 
lot of IE vulns can only be easily (and thus "usefully") leveraged 
because it is (well, was -- this is a Win9x example) easy to assume 
that any kind of program code that could be dropped into 
c:\windows\start menu\programs\startup would be run next startup.  
Finding the actual location of the startup folder was beyond the 
exploit because it was running in an environment that could not query 
the registry or other system APIs that would reveal the location.

In short, it's about hardening against exploitation rather than about 
making a machine exploit proof as the latter is an ideal rather than a 
realistic goal.

Regards,

Nick FitzGerald