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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <42EAE5CF.9080908@science.org>
Date: Sat Jul 30 03:27:47 2005
From: jasonc at science.org (Jason Coombs)
Subject: Cisco IOS Shellcode Presentation

Valdis.Kletnieks@...edu wrote:
> On Fri, 29 Jul 2005 15:02:51 -1000, Jason Coombs said:
>>redesign, fundamentally, the turing machine so that before each 
>>operation is performed a verification step is employed to ensure that 
> 
> Ahem. No.  You *can't* "ensure" it (although you *can* do things like bounds
> checking to *minimize* issues).
> 
> It's called the Turing Halting Problem

We're not talking about proving/disproving the result of computation 
here, we're talking about a simple logical step inserted prior to 
transmission of operating instructions and data to a turing machine.

It does not invoke the Turing Halting Problem to ask the question 
"should the following opcode be sent to the CPU / should the opcode be 
read from memory and acted upon" ?

The simplest solution is to duplicate the machine code, placing one copy 
in a protected storage and requiring the CPU to confirm that both the 
active/RAM-resident copy and the protected storage copy match before 
proceeding with computation.

This is superior to simply reading machine code from a protected storage 
because the point is that malicious arbitrary code that overwrites or 
reprograms or inserts itself into the runtime memory space of an active 
process would easily defeat a volatile copy of a non-volatile protected 
storage image of some machine code. Only by requiring the CPU to perform 
a validation of each opcode instruction but allowing the CPU to continue 
to behave in all other respects as it behaves today does the protection 
arise. Other approaches are possible, but the basic idea of a separate 
supply of bits useful for the runtime authentication of opcodes remains 
the same.

Turing has nothing to say on this subject because he never contemplated 
it, to the best of my knowledge. Turing never tried to defend against 
buffer overflows back in the 1930s, yet people invoke him as a sage 
unerring philosopher of our time. Why?

Regards,

Jason Coombs
jasonc@...ence.org