Re: Trusting the Tools - was Re: Open Source ...
On Sun, Oct 12, 2003 at 08:25:21AM -0600, Anne Lynn Wheeler wrote: It wouldn't have been impossible ... but quite unlikely. It is somewhat easier in C-based programs since there are additional levels of indirection and obfuscations between the statements in a C program and the generated machine code. Hmm. While I agree with your assessment of likelihood, I think you understate the seriousness of the issue in both the C case and the assembler case -- they are not really that different. It's not just a matter of indirection and obfuscation -- there can be large blocks of code generated for which there is no external visibility whatsoever (ie, the map files and other traces of generated code can simply not show the hidden code. This is true both for C and assembler. The only way you can really tell is if you capture *all* of the live memory of the computer, and disassemble it with a verified disassembler. (eg, what shows as bss 0 in the assembler listing is really code; what shows as one set of instructions in the listing is in reality different.) Kent -- Kent Crispin Be good, and you will be [EMAIL PROTECTED],[EMAIL PROTECTED] lonesome. p: +1 310 823 9358 f: +1 310 823 8649 -- Mark Twain - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Trusting the Tools - was Re: Open Source ...
At 03:48 PM 10/12/2003 -0700, [EMAIL PROTECTED] wrote: Hmm. While I agree with your assessment of likelihood, I think you understate the seriousness of the issue in both the C case and the assembler case -- they are not really that different. It's not just a matter of indirection and obfuscation -- there can be large blocks of code generated for which there is no external visibility whatsoever (ie, the map files and other traces of generated code can simply not show the hidden code. This is true both for C and assembler. The only way you can really tell is if you capture *all* of the live memory of the computer, and disassemble it with a verified disassembler. (eg, what shows as bss 0 in the assembler listing is really code; what shows as one set of instructions in the listing is in reality different.) well ... you can take and compare the listing file against the txt deck output of the assembler listing for each module . Each txt: deck is input to the loader which builds the actual executable (almost) memory image. past discussion of the TXT file format: http://www.garlic.com/~lynn/2001.html#14 IBM Model Numbers (was: First video terminal?) http://www.garlic.com/~lynn/2001c.html#87 Bootstrap http://www.garlic.com/~lynn/2001k.html#31 Is anybody out there still writting BAL 370. http://www.garlic.com/~lynn/2002f.html#41 Blade architectures http://www.garlic.com/~lynn/2002o.html#26 Relocation, was Re: Early computer games then the issue isn't if the assembler has been compromised ... it is whether the loader has been compromised. then you compare the memory image file against the aggregate of the txt decks ... if you've done the assembler listing comparison against the txt deck correctly then the memory image comparison is looking for a loader compromise ... not an assembler compromise. some past discussion of memory/debugger analyser from approx. period that gnosis started (precursor to keykos): http://www.garlic.com/~lynn/subtopic.html#dumprx which also had some capability to work from memory image of the program in conjunction with assembler listing files. of course it primarily relied on the REXX interpreter for its functionality so if there was a compromise in the REXX interpreter or any of the utilities written for analyses and comparison were compromised from the standpoint of masking compromise in other components related to insertion of malicious code. -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Trusting the Tools - was Re: Open Source ...
On Thu, Oct 09, 2003 at 07:45:01PM -0700, Bill Frantz wrote: At 8:18 AM -0700 10/7/03, Rich Salz wrote: Are you validating the toolchain? (See Ken Thompson's Turing Aware lecture on trusting trust). With KeyKOS, we used the argument that since the assembler we were using was written and distributed before we designed KeyKOS, it was not feasible to include code to subvert KeyKOS. How do people feel about this form of argument? Not too good. If I knew what the target processor were, I think I could arrange to do some damage to most general-purpose operating systems; they all have to do some of the same fundamental things. This is a bit more sophisticated than what Thompson's compiler did, but it's the same basic idea. There are some basic operations (in particular on the MMU) that you can recognize regardless of their specific form and subvert in a progammatic manner such that it's highly likely that you can exploit the resulting weakness at a later date, I think. Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Trusting the Tools - was Re: Open Source ...
At 8:18 AM -0700 10/7/03, Rich Salz wrote: Are you validating the toolchain? (See Ken Thompson's Turing Aware lecture on trusting trust). With KeyKOS, we used the argument that since the assembler we were using was written and distributed before we designed KeyKOS, it was not feasible to include code to subvert KeyKOS. How do people feel about this form of argument? Cheers - Bill - Bill Frantz| There's nothing so clear as a | Periwinkle (408)356-8506 | vague idea you haven't written | 16345 Englewood Ave www.pwpconsult.com | down yet. -- Dean Tribble | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
