full-disclosure - Cisco IOS Shellcode Presentation

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat Jul 30 02:02:10 2005
From: jasonc at science.org (Jason Coombs)
Subject: Cisco IOS Shellcode Presentation

J.A. Terranson wrote:
> Also, that Cisco must fix was not the point of my argument.  I was trying
> to point out that Jason's basic premise that this was a grossly negligent
> act by Cisco is pure fiction.

Not at all -- you're simply constraining the discussion to all known 
CPUs and I'm referring to the duty that a company like Cisco obviously 
has to make a better mousetrap if they intend to sell it to millions of 
people and coax billions of people to rely on the devices.

There are any number of technical solutions that one could use to 
redesign, fundamentally, the turing machine so that before each 
operation is performed a verification step is employed to ensure that 
the operation is the correct one in the correct sequence given prior 
configuration settings loaded into memory at the time the device was 
activated.

Store the necessary security profile, which could very well be just 
another copy of the entire machine code, in a separate memory that can 
be accessed in parallel and used solely to verify that the operation 
about to be performed matches the operation that is supposed to be 
performed. Require a physical act by the owner of the device to populate 
the security profile data storage so that it cannot be automated through 
the execution of code, and you enable both the software 
reprogrammability of the computing device and the non-programmability 
feature that provides the proper security safeguard.

This is a very high-level explanation, to be sure, but there's no reason 
not to redesign the CPU if you're Cisco. Or if you're Microsoft, or 
Intel, or AMD, for that matter.

CPUs are unnecessarily-insecure by design, as a result of people running 
around saying that you just can't change the way that a turing machine 
operates. That's what's pure fiction. Turing machines don't need to be 
allowed to operate in a vacuum, they can be sanity-checked at runtime if 
anyone cares to do so.

I am not suggesting that such CPUs exist today, only that they should 
and that a company like Cisco knows this very well and chooses not to 
undertake this engineering challenge, presumably because it would cut 
into profits.

Regards,

Jason Coombs
jasonc@...ence.org