Message-ID: <43FE243A.1010005@science.org>
Date: Thu Feb 23 21:07:37 2006
From: jasonc at science.org (Jason Coombs)
Subject: Re: How hackers cause damage... was
 Vulnerabilites in new laws on computer hacking

Craig Wright wrote:
 > Cyber-trespass leaves one in a state of doubt. It is commonly stated
 > that the only manner of recovery from a system compromise is to
 > rebuild the host.

Don't you mean that the trespass disrupts the condition of denial and 
neglect that normally exists surrounding any network of programmable 
computers?

The 'state of doubt' is no different post-trespass than it was 
beforehand, what has changed is the emotional condition of the property 
owner. After recovery steps to rebuild the host, there is again a 'state 
of doubt' and it is just as substantial as it was before the trespass 
incident caused everyone emotional trauma.

We must build computer systems that separate the act of installing and 
executing software from the act of depositing data on read/write media.

Executable code must not be stored on read/write media. At least not the 
same media to which data is written, and access to write data to 
software storage must not be possible through the execution of software; 
at least not software executing on the same CPU as already-installed 
software.

Our CPUs need a mechanism to verify that the machine code instructions 
being executed have been previously authorized for execution by the CPU, 
i.e. the machine code is part of software that has been purposefully 
installed to a protected software storage separate (logically, at least, 
and both physically and logically separated at best) through actions 
that could not have been simulated or duplicated by the execution of 
machine code at runtime on the system's primary CPU.

The worst-case scenario of 'repair' and 'recovery' from any intrusion 
event should be verification of the integrity of protected storage, 
restore from backup of data storage, analysis of data processing and 
network traffic logs to ascertain the mode of intrusion (if possible) 
and reboot of the affected box with a staged reintroduction of the 
services that box previously provided (if you just re-launch all of the 
services being exposed by the box then it is just as vulnerable as 
before to whatever attack resulted in the intrusion, so you start from 
the most-locked-down condition and add services one at a time, 
monitoring for a period of time at each step).

Depending on the length of time one is willing to monitor the box as it 
is staged into deployment again after recovery, and depending on the 
tools put into place to enable verification of the authenticity and 
'correctness' of the machine code found to be present on the protected 
storage where software is installed, 'recovery' from any incident can be 
almost immediate, requiring little more than a reboot (the steps for 
which could also be optimized in a well-built secure computer system, 
since the objective really is nothing more than wiping all RAM and 
re-reading machine code from the protected storage after integrity 
verification is complete) ...

All of the 'damage' and 'vulnerabilities' you're talking about stem 
directly from very bad business decisions made by owners of computer 
systems and from authors of software made to run on those computer 
systems. Hackers can be made irrelevant, and virtually all significant 
damage from 'intrusion' can be prevented in advance, by putting a stop 
to the world's addiction to the installation and execution of arbitrary 
code. The problem is that the computer industry has been built around 
providing financial rewards to the businesses that can get as many 
copies of their code executing as possible, and security barriers that 
curtail access to this cash generating machine would kill 75% of the 
existing computer industry.

I say let 'em die. Give us secure computing, and may every company that 
intentionally harms people for profit die a horrible and painful death 
that takes as many of its investors with it as possible in the process!

Sincerely,

Jason Coombs
jasonc@...ence.org

Powered by blists - more mailing lists