Full Disclosure mailing list archives
Re: Cisco IOS Shellcode Presentation
From: Bart.Lansing () kohls com
Date: Mon, 1 Aug 2005 10:10:41 -0500
full-disclosure-bounces () lists grok org uk wrote on 07/29/2005 09:28:31 PM:
Valdis.Kletnieks () vt 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 thatAhem. No. You *can't* "ensure" it (although you *can* do things like
bounds
checking to *minimize* issues). It's called the Turing Halting ProblemWe'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 () science org _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Pardon my intrusion (or don't, either way...) It occurs to me that your solution is flawed as well. What assurance do we have that your "protected storage" is future-proof (i.e. unbreachable by an means whatsoever)? Assuming it is not, you'll need to be prepared to have the "protected storage" verify itself against the "really protected storage", which has validated itself against the "exceptionally well looked after" storage, which was tested against the "superbly vaulted super-secret storage"...ad nauseum...before you can send instructions to the cpu with any absolute guarantee that the code it wants to run is legit. As the ability to break into/compromise your vaulted storage and its children improves, one can logically project a situation where your proposed system is burning far more cycles validating itself than it can possibly spend doing its job. Jason, et al, I appreciate that from a theoretical standpoint I am wildly out of my depth...but the underlying flaw in the logic of your premise has nothing to do with the technologies and everything to do with your basic assumptions. CONFIDENTIALITY NOTICE: This is a transmission from Kohl's Department Stores, Inc. and may contain information which is confidential and proprietary. If you are not the addressee, any disclosure, copying or distribution or use of the contents of this message is expressly prohibited. If you have received this transmission in error, please destroy it and notify us immediately at 262-703-7000. CAUTION: Internet and e-mail communications are Kohl's property and Kohl's reserves the right to retrieve and read any message created, sent and received. Kohl's reserves the right to monitor messages by authorized Kohl's Associates at any time without any further consent. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Cisco IOS Shellcode Presentation moshe (Aug 01)
- Re: Cisco IOS Shellcode Presentation ad () class101 org (Aug 01)
- Re: Cisco IOS Shellcode Presentation milw0rm Inc. (Aug 01)
- Re: Cisco IOS Shellcode Presentation John Kinsella (Aug 01)
- Re: Cisco IOS Shellcode Presentation milw0rm Inc. (Aug 01)
- Re: Cisco IOS Shellcode Presentation John Kinsella (Aug 01)
- Re: Cisco IOS Shellcode Presentation Andre Ludwig (Aug 01)
- Re: Cisco IOS Shellcode Presentation Ron DuFresne (Aug 02)
- Re: Cisco IOS Shellcode Presentation milw0rm Inc. (Aug 01)
- Re: Cisco IOS Shellcode Presentation ad () class101 org (Aug 01)
- Re: Cisco IOS Shellcode Presentation Ivan C (Aug 01)
- Re: Cisco IOS Shellcode Presentation J.A. Terranson (Aug 01)
- <Possible follow-ups>
- Re: Cisco IOS Shellcode Presentation Bart . Lansing (Aug 01)
- Re: Cisco IOS Shellcode Presentation Jason Coombs (Aug 01)
- Re: Cisco IOS Shellcode Presentation David Chastain (Aug 02)
- Re: Cisco IOS Shellcode Presentation Thierry Zoller (Aug 03)
- Re: Cisco IOS Shellcode Presentation Jason Coombs (Aug 01)
- Re: Cisco IOS Shellcode Presentation Technica Forensis (Aug 01)
- Re: Cisco IOS Shellcode Presentation Jason Coombs (Aug 01)
- Re: Cisco IOS Shellcode Presentation Valdis . Kletnieks (Aug 01)
- Re: Cisco IOS Shellcode Presentation Michael Holstein (Aug 02)
- Re: Cisco IOS Shellcode Presentation Michael Holstein (Aug 02)
- Re: Cisco IOS Shellcode Presentation bkfsec (Aug 02)