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
| ||
|
Message-ID: <200507300339.j6U3dpH5009372@turing-police.cc.vt.edu> Date: Sat Jul 30 04:40:07 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu) Subject: Cisco IOS Shellcode Presentation On Fri, 29 Jul 2005 16:28:31 -1000, Jason Coombs said: > 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" ? Actually, it does. Consider if the opcode is the one that moves the one byte into an apparently innocuous location that eventually causes a program malfunction. Remember the ntpd exploit? That started as a one-byte overlay ;) LOAD R7,DATA Move the contents of the storage location 'DATA' to R7. Should it do it? It seems reasonable, right? What if the *entire* code looks like: LOAD R7,DATA LOAD R3,FOO LOAD R9,OTHER TEST R9,23 Is it 23? BNE AROUND If not, go around DIVIDE R3,R7 If it was 23, divide R3 by R7.. AROUND ... Have a nice divide-by-zero, on the house, complements of Alan Turing. You certainly can't suggest that the DIVIDE do the checking - because that's the operation that will finally detect the problem *ANYHOW*. So where do you want to flag it? When R9 is loaded? When R3 is? When R7 is? When the program failed to check for non-zero before it *stored* into DATA? (And that one is only a few opcodes away - I once had the thrill of chasing down a bug that didn't cause a problem on one system, and only caused a problem on another after an intervening 6 million malloc() calls had allocated 200M more heap. And even then, it was data dependent and only failed sometimes....) But yeah - hardware can check for that, no problem... ;) > 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. Just store the program in a frikking *ROM*, and disallow execution of opcodes from RAM. It's called a Harvard architecture. It can still be buggy and exploitable (although a lot harder - you're essentially restricted to return-to-libc style attacks). > 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? Actually, Turing didn't try to defend against buffer overflows because he was busy working on much more subtle attacks. Why do people invoke him as a sage? Because he pointed out the very basic issues of "data as programs" and "programs as data" that cause us so many problems today. For instance, if you understood what Turing was talking about, you'd have been able to just *know* that Javascript was going to be a continual source of security headaches (how many Javascript bugs were because somebody didn't keep straight if something was "code" or "data"?). Or why Microsoft Word macros can be viruses, even though Word documents are usually thought of as "data" - the problem is that the macro is allowed to be introspective (and of course, a Word macro that *isn't* allowed to be introspective is just *useless*.. ;) But no, other than that, Turing didn't have a *clue* :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050729/ba8185f0/attachment.bin
Powered by blists - more mailing lists