>> http://blogs.ittoolbox.com/emergingt...-thompson-and-
>> the-selfreferencing-c-compiler-16142
>>
> Sure, but it depends on a lot of things being 'just so' and is casually
> available as inspection to anyone who looks at the source.
You obviously didn't understand it. The trojanized compiler compiles the not
trojanized source code to iself, so reading the source code of the compiler
doesn't tell you anything.
> And people DIO look at source, especially when one compiler generates an
> object file markedly different from te last ne they compiled with
> another compiler.
Bullshit. Different compilers typically generate totally different object
code, and even different versions of the same compiler mostly do.
> And to dump the code in '.asm' form immediiately reveals most of what is
> going on.
Only true if there are only small changes, which happens at most when
compiling the same source with the same compiler multiple times.
> The security of open source, lies paradoxically, in the fact that it is
> completely open..
But this has nothing to do with the bootstrapping problem.
Sebastian G. wrote:
> The Natural Philosopher wrote:
>
>
>> Not te code that gcc compiles, teh code of GCC itself.
>>
>> And its libaries,.
>
>
> And a trojan can propagate itself by exactly this mechanism.
>
>> Anyway, you could almost certainly not store a trojan in a compiler:
>> It has to be at the least in the libraries, and those are all source
>> open for inspection. As is the compiler itself.
>
>
> No. It can be inside the compiler binary, and compile its very own code
> to itself.
So, inspect the compiler code. At some level it has to show up, and all
levels are open to inspection.
You will get some damned funny results if for example you use a compiler
trying to inject its own network access when you replace the standard
network access library stuff with something you have written yourself
for custom hardware. And shove it on a hardware debugger.
You can't subvert EVERYTHING to not notice unwarranted network access.
Fer chrissakes, even a semi decent firewall with packet logging is
going to notice that socket calls to unknown addresses are taking place.
> Sebastian G. wrote:
>> The Natural Philosopher wrote:
>>
>>
>>> Not te code that gcc compiles, teh code of GCC itself.
>>>
>>> And its libaries,.
>>
>> And a trojan can propagate itself by exactly this mechanism.
>>
>>> Anyway, you could almost certainly not store a trojan in a compiler:
>>> It has to be at the least in the libraries, and those are all source
>>> open for inspection. As is the compiler itself.
>>
>> No. It can be inside the compiler binary, and compile its very own code
>> to itself.
> So, inspect the compiler code. At some level it has to show up, and all
> levels are open to inspection.
You cannot easily inspect the compiler binary.
> You will get some damned funny results if for example you use a compiler
> trying to inject its own network access when you replace the standard
> network access library stuff with something you have written yourself
> for custom hardware. And shove it on a hardware debugger.
We're talking about a trojanized compiler which does almost nothing more but
compiling source code to a slightly modified version. And it does so by
working as a compiler, not by just writing itself into the binary.
Additionally it may decide to readjust the size of one in one million arrays
to introduce a buffer overrun vulnerability in the binary, or otherwise
semantically modify a program in a hardly detectable way.
Nico Kadel-Garcia wrote:
> The Natural Philosopher wrote:
>
>> Anyway, you could almost certainly not store a trojan in a compiler:
>> It has to be at the least in the libraries, and those are all source
>> open for inspection. As is the compiler itself.
>
> Kernighan and Ritchie disagree with you. They wrote C.
>
> Mind you, examining the assembly code in considerable detail should
> reveal the flaw, but that's far more work than most of us can do.
But its what a lot of us DO do, at some stage in our lives..
Gcc is used a lot for cross compilation work. With other peoples
assemblers. Its not likely that if it suddenly produced assembler code
that bore no relation to the C code it wouldn't alert someone somewhere
to what was going on.
The logical place to bury a trojan isn't in the compiler, its in some
part of the library..or some normal daemon.
I'd plump for a subverted inetd myself..But even so, unless you have
network access that is completely unmonitored and unfirewalled, what
good would it do?
You MIGHT be able to also hack the socket layer to allow opening a
socket on a non SYN packet for example..but you STILL have to send
packets in and out..and most firewalls in any establishment with any
pretense to security are going to notice traffic going to sites they
cant explain..
...and then even if you got it working, what wold be the POLITICAL impact
of having done so IF discovered.
Pretend itr was all some hacker? when standing at te far end is a NSA
computer?
It wold make watergate look like the Teddy bears picnic..
> It's a
> potentially deadly issue for Gentoo, where so many of the tools get
> recompiled on the fly.
Jean-David Beyer wrote:
> Sebastian G. wrote:
>> Jean-David Beyer wrote:
>>
>>
>>> Now imagine a black hat takes that compiler and puts in some code that
>>> generates back doors in any program it produces. The black hat then
>>> compiles
>>> the flawless examined compiler with it. He would also compile programs
>>> like
>>> cmp and sdiff with it. If this compiler was ever used at the the
>>> location of
>>> your distribution source, you would be compromised, and have no good
>>> way of
>>> determining that it happened.
>>
>> There is, as long as you can get your hands on at least one trustworthy
>> compiler.
>
> But how would you do that? I assert that unless you have a raw machine and
> bypass the BIOS (if you have one) and bootstrap everything from binary
> produced by yourself, you cannot do it. And even if you do that, you cannot
> know that the NSA did not prevail on Intel, etc., to sabotage you at the
> hardware level.
Even then, any access over the net is available for monitoring.
>
> You just have to trust.
>>> To guard against this, you would have to check the binary code of your
>>> compiler against a known good version (and how would you know that?). How
>>> would you do the comparison? How would you know that the source of your
>>> distro was not similarly compromised?
>>
>> To guard against this, we typically document development processes, do
>> cross-machine checks, and let the compiler output annotated assembler code.
>
> The black-hatted compiler would output annotated assembler code hiding
> whatever trojans it put in. Most compilers do not actually produce assembler
> code anymore unless you ask for it. So when the compiler puts out .o files,
> there is no reason to believe that that corresponds to what the .s files reveal.
>
> Since the kernel is compiled, the kernel, too, could be compromised, so you
> really must do everything in binary yourself assuming that you trust the
> hardware. I just think no one will do this.
>
Someone always will.
For the most obscure of reasons.
You may find it hard to believe, but there are people out there who
understand computers from gates to GUI.
Even microcode can be reversed engineered - and often is.
If Intel ever allowed something to happen to their microcode..you may be
sure that their stock would be down 75% teh day after someone discovered it.
ALL the most succeessful worms, viruse and trojans and hacks depend on a
huge number of things being 'just so' - vary one of them and at best the
bug does nothing, but most likely it causes behaviour that WILL have the
people who know burrowing further down the line until they DO get to
the bottom of it.
The risks of being found out hugely outweigh the benefits of doing it.
Jean-David Beyer wrote:
> Sebastian G. wrote:
>> Jean-David Beyer wrote:
>>
>
>>>> There is, as long as you can get your hands on at least one trustworthy
>>>> compiler.
>>> But how would you do that?
>>
>> There are many available.
>
> How do you know? If Red Hat, SuSE, and so on have ever been infected with a
> trojanized compiler, everything they ever produce will have it too.
>>> I assert that unless you have a raw machine and
>>> bypass the BIOS (if you have one) and bootstrap everything from binary
>>> produced by yourself, you cannot do it.
>>
>> I assert that you're talking nonsense. If at least one trustworthy
>> compiler exists, every hidden modification can be detected XOR
>> modification-free binaries created.
>
> Yes, IF at least one trustworthy compiler exists, but you cannot know that.
>>> And even if you do that, you cannot
>>> know that the NSA did not prevail on Intel, etc., to sabotage you at the
>>> hardware level.
>>
>> Indeed, but that's even less likely of a problem, since the hardware
>> rarely changes.
>
> Not so. It may change slower than software, but it sure changes. Even if you
> look at only Intel Xeon Hyperthreaded processors. Mine are
>
> CPU0: Intel(R) Xeon(TM) CPU 3.06GHz stepping 05
> CPU1: Intel(R) Xeon(TM) CPU 3.06GHz stepping 05 So they changed it 4 or 5
> times before I got mine.
>>>> To guard against this, we typically document development processes, do
>>>> cross-machine checks, and let the compiler output annotated assembler
>>>> code.
>>> The black-hatted compiler would output annotated assembler code hiding
>>> whatever trojans it put in.
>>
>> If so, then one could see in there a trivial inconsistency: Either the
>> assembler output is not semantically equivalent to the source code, or
>> the assembler output doesn't match the binary code. This intermediate
>> format is supposed to make this easy to spot.
>
> But it does not, since the sabotaged compiler puts out "correct" code when
> it is asked for the assembler code, and "incorrect" code when you ask for
> the actual binary.
So assemble the correct code and compare it with the .o..using someone
else's assembler.
>>> Most compilers do not actually produce assembler
>>> code anymore unless you ask for it.
>>
>> That's why they include this option.
>
> Chickens and eggs.
>
> Someone else posted this already in this thread, but I really suggest you
> read and understand it.
>
> http://cm.bell-labs.com/who/ken/trust.html
>
> I think you will find that Ken Thompson and Dennis Ritchie (who wrote the
> first C compiler) know something about what Ken talks about here.
>
Yes. it can be done in a limited way, but not in a generic way to fool
everyone who ever uses it.
And certainly not to install invisible network access that every router
in the world connives to pass unrecorded.
Look at what started this thread. Someone NOTICED that their network
access light was flickering when the machine was doing nothing. Pretty
poor hack if it fails that that first base.
Nico Kadel-Garcia wrote:
> AZ Nomad wrote:
>> On Thu, 06 Mar 2008 14:39:33 GMT, Jean-David Beyer
>> <jeandavid8@verizon.net> wrote:
>>> Bill Baka wrote:
>>>> Hadron wrote:
>>>>> AZ Nomad <aznomad.2@PremoveOBthisOX.COM> writes:
>>>>>
>>>>>> On Tue, 4 Mar 2008 16:19:16 -0800 (PST), plenty900@yahoo.com
>>>>>> <plenty900@yahoo.com> wrote:
>>>>>>
>>>>>>> I've learned that there are bits of NSA's SELinux in various
>>>>>>> places in kernel 2.6. How can I be sure that Big Brother isn't
>>>>>>> using back doors or bugs to break into my computer?
>>>>>>> Especially with all the illegal spying done these days...
>>>>>>> How much safer would it be to just switch back to 2.4 or 2.5?
>>>>>> Read the fucking source code! Thousands of others have and there
>>>>>> are no backdoors. When you build a kernel, it is from the source
>>>>>> code and if the source code has no backdoors, then the compiled
>>>>>> kernel won't either.
>>>>> Assuming you read the code to each and every application which runs
>>>>> under root. Assuming you have read the code for the compiler.
>>
>>> It also assumes that the compiler on your machine is the one you have
>>> code
>>> for, and I do not know how you could tell that. Because if you do
>>> not, you
>>
>> Please enlighten us on a version of GCC where nobody has examined the
>> code.
>
> It's theoretically possible to publish a GCC binary where the publishd
> source is not that used to compile the GCC.
So compile THAT source with another compiler, and compare the outputs of
THAT compiler with the standard trojaned one.
Thats what a lot of people tend to do who are in the compiler game
anyway..checking for code optimisations, bugs and the like.
We generally trust our
> software vendors to publish the source code they used, in the Linux
> world, as part of their complicance with the GPL. But people have
> occasionally been known to lie. It's why I prefer to compile, locally,
> tools from repositories that haven't established a solid trust
> relationship with us.
>
> It's also possible to include, in an early version of GCC or any other
> compiler, a backdoor for the compiled in encryption functions that will
> be propagated to other compilers built with it.
>
> Kernighan and Ritchie, the authors of C, admit to having played with
> this concept. It's discussed at
> http://osdir.com/ml/os.openbsd.tech/.../msg00166.html.
>
> I'm not saying GCC has such a flaw, but it's theoretically possible.
What 'compiled in encryption functions'?
The only encryption functions I can recall were in libcrypt..
which we had to garb source and comile as it wasn't 'available for
export' Though the sources were..
The Natural Philosopher wrote:
> Jean-David Beyer wrote:
>
>> Actually, I do not know how they write compilers these days.
>
> I doo not think you know how they EVER wrote compilesr, assemblers and
> linkers at all, ever.
That is not in exact correspondence with the facts.
I worked in one of the laboratories at Bell Labs that produced their C and
C++ compilers. I worked mainly on the HALO optimizer that optimized the
(assembly-level) code that came out of the compiler before it went into the
assembler. To do that, I had to know a lot about the compiler and assembler,
as well as the various target machines (e.g., AT&T 32100 and 32200 320bit
chip sets, SPARC chips (we were working with SUN on those), and another
in-house chip called the CRISP. We targeted our own 3B-20 machine as well as
the other 3B machines (they were somewhat different), as well as those other
chip set.
I also had to produce a link-editor (based on the regular UNIX one) that
could load programs into a special purpose computer with special memory
management hardware (for a stupid reason), and needed to be able to link
programs that needed more than 16 bits for addresses. It was no joy going
through the regular UNIX link editor for that. That was in the days of
PDP-11 style machines.
>
> If I had an assembler that didn;t show teh prper 1:1 output in hex for
> what I fed into it, I would be screming bloody murder.
I suppose so.
>
> Its easy enough to write a disassembler..in almost any language you want.
>
Sure.
>
> Its easy enough to write a pretty fair assembler in any language you want
> as well.
>
I guess so. But if you do not want to assemble and link-edit that stuff by
hand, you just reopen the Pandora's box of bootstrapping all over again.
>
> At times they
>> used lex and yacc to to the lexical and syntactic analyzers and
>> building up code trees. Then they optimized the trees, generated object
>> code, optimized that, and produced the .o files. So lex and yacc would
>> have to be verified too, not just their sources, but the binaries.
>>
>
>
> No need for any of that.
Perhaps not. Of course you can write an OS, assembler, compiler, etc., in
assembler. The first few versions of UNIX were done that way until Steve
Johnson wrote the portable C compiler (in C). About that time, Ken and
Dennis rewrote the UNIX kernel in C. At that point, retargetting the UNIX
kernel to other hardware became, comparatively, simple. A little before
that, MULTICS was written in an early dialect of PL/I. I doubt people write
compilers or OS kernels in assembler anymore.
>
> You can write a basic compiler in assembler. Use that to compile a less
> basic compiler, and bootstrap up from there.
>
Of course you could do that, but they did not even do that in the 1980s, and
I am sure they do not now. They use lexical analyzer generators (e.g., lex),
syntactic analyzer generators (e.g., yacc). They even use
compiler-compilers. At least they did in the 1980s. I cannot see why they
would take steps backwards now.
>
> YOur argument seems to be 'its all so complicated that opportunities for
> errosr - deliberate or otherwise, exist'
I was not arguing that at all. Using these higher level languages to
generate routine parts of compilers in C or C++ (or any other language)
actually simplifies things, though it makes the bootstrap problem a bit more
difficult. Because the complexity issues seem proportional to the number of
lines of code, and not much on how high a level language you use. Therefore
the higher level language(s) you use, the less likely you are to have bugs
because you need write less code to get the same effect.
>
> Sure, but deliberate errors that don't show up at *any* level for year
> and years are far far harder..
>
> Don't you think that someone cross compiling linux for - say - a custom
> hardware platform using a completely different program environment isn;t
> going to say 'funny, this code works differently when I use XYZ compiler'
> and burrow in to find out why?
>
Sure if they notice it. Having watched a system test group just trying to
verify that a UNIX system obeys the SVID specifications, taking months and
months of testing shows me that errors very easily sneak through the most
rigorous testing one can think of.
I accidentally put a bug into the HALO optimizer. We compiled the optimizer
with the optimizer in use. That passed all our tests. We then compiled the
entire C development suite with that optimizer. That passed all our tests
and the SVID tests as well. We then recompiled the UNIX kernel and
everything else, and that also passed all our tests, all the SVID tests, etc.
Then an end user, after a few months, said the FORTRAN compiler did not work
right on one particular function. We examined his code and determined it
worked unoptimized, and did not work optimized. The FORTRAN code was simple
and appeared correct. The assembly code output was not. The FORTRAN compiler
had not been changed (it was little used by then). I quickly found and fixed
the optimizer bug, but it was in a code sequence the C and C++ compilers
never generated, and that was where we did most of our testing. And the bug
was not even in the FORTRAN compiler until the optimizer mis-optimized it. I
made no attempt to hide the bug. Were I a black hat, I sure would.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 13:40:01 up 1 day, 20:41, 2 users, load average: 4.47, 4.16, 4.11
The Natural Philosopher wrote:
> Jean-David Beyer wrote:
>> The Natural Philosopher wrote:
>>> Sebastian G. wrote:
>>>> AZ Nomad wrote:
>>>>
>>>>> On Thu, 06 Mar 2008 14:39:33 GMT, Jean-David Beyer
>>>>> <jeandavid8@verizon.net> wrote:
>>>>>> Bill Baka wrote:
>>>>>>> Hadron wrote:
>>>>>>>> AZ Nomad <aznomad.2@PremoveOBthisOX.COM> writes:
>>>>>>>>
>>>>>>>>> On Tue, 4 Mar 2008 16:19:16 -0800 (PST),
>>>>>>>>> plenty900@yahoo.com <plenty900@yahoo.com> wrote:
>>>>>>>>>
>>>>>>>>>> I've learned that there are bits of NSA's SELinux in
>>>>>>>>>> various places in kernel 2.6. How can I be sure that
>>>>>>>>>> Big Brother isn't using back doors or bugs to break
>>>>>>>>>> into my computer? Especially with all the illegal
>>>>>>>>>> spying done these days... How much safer would it be to
>>>>>>>>>> just switch back to 2.4 or 2.5?
>>>>>>>>> Read the fucking source code! Thousands of others have
>>>>>>>>> and there are no backdoors. When you build a kernel, it
>>>>>>>>> is from the source code and if the source code has no
>>>>>>>>> backdoors, then the compiled kernel won't either.
>>>>>>>> Assuming you read the code to each and every application
>>>>>>>> which runs under root. Assuming you have read the code for
>>>>>>>> the compiler.
>>>>>> It also assumes that the compiler on your machine is the one
>>>>>> you have code for, and I do not know how you could tell that.
>>>>>> Because if you do not, you
>>>>> Please enlighten us on a version of GCC where nobody has examined
>>>>> the code.
>>>>
>>>> Examining the code doesn't help if the compiler compiles it to
>>>> trojanized code, which by itself might be the compiler.
>>> He said a 'version of GCC where nobody has examined the code'
>>>
>>>
>>> Not te code that gcc compiles, teh code of GCC itself.
>>>
>>> And its libaries,.
>>>
>>> Anyway, you could almost certainly not store a trojan in a compiler:
>>>
>>
>> I do not see why not.
>
> How many compilers have you written or been involved in developing?
>
Two.
>
>>
>>> It has to be at the least in the libraries, and those are all source
>>> open for inspection. As is the compiler itself.
>>
>> As I suggested, once you are contaminated with a trojanized compiler,
>> you are pretty much doomed. You can take clean verified source, compile
>> it with the trojanized compiler, and get a trojan-laden object file.
>> And that applies to the compiler, the run-time library, the OS kernel,
>> everything that gets compiled. Examining the source code is no use
>> because the trojan is hidden inside the compiler, and there is no
>> reason for the black hat to give you the source of that.
>>
>
> But they do. Gcc source is public domain.
But the trojanized version is not. And once you compile the trojanized
compiler, you can eliminate it's source code from the universe and it is too
late. Because that compiler can contaminate everything it compiles,
including the Gcc source.
>
> And no one says you have to use gcc either. You are at liberty to use any
> C compiler,.
>
Sure.
>
> However, its patently obvious that you don't really know what a compiler
> is or how it works.
>
> So it all seems feasible to you.
>
> I do, and it doesn't.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 14:10:01 up 1 day, 21:11, 2 users, load average: 4.16, 4.18, 4.12
The Natural Philosopher wrote:
> Sebastian G. wrote:
>> The Natural Philosopher wrote:
>>
>>
>>> Not te code that gcc compiles, teh code of GCC itself.
>>>
>>> And its libaries,.
>>
>>
>> And a trojan can propagate itself by exactly this mechanism.
>>
>>> Anyway, you could almost certainly not store a trojan in a compiler:
>>> It has to be at the least in the libraries, and those are all source
>>> open for inspection. As is the compiler itself.
>>
>>
>> No. It can be inside the compiler binary, and compile its very own
>> code to itself.
> So, inspect the compiler code. At some level it has to show up, and all
> levels are open to inspection.
>
It would appear ONLY in the binary version of the compiler. Never in the
source, be it lex, yacc, C++, C, assembler, ...
>
>
> You will get some damned funny results if for example you use a compiler
> trying to inject its own network access when you replace the standard
> network access library stuff with something you have written yourself
> for custom hardware. And shove it on a hardware debugger.
>
> You can't subvert EVERYTHING to not notice unwarranted network access.
>
>
> Fer chrissakes, even a semi decent firewall with packet logging is
> going to notice that socket calls to unknown addresses are taking place.
>
>
>
Yes, if you trust the firewall. You keep moving the target which is the
trust of the bootstrapping process.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 14:10:01 up 1 day, 21:11, 2 users, load average: 4.16, 4.18, 4.12
> However, its patently obvious that you don't really know what a compiler
> is or how it works.
>
> So it all seems feasible to you.
>
> I do, and it doesn't.
Seriously, Ken Thompson and Kernighan and Ritchie disagree with you.
Cross-compilation is a big step in breaking such a cycle of trojann-laden
software, as is evolution to use different components for password handling.
But please go look up the work by them on the subject.
Jean-David Beyer wrote:
> The Natural Philosopher wrote:
>> Sebastian G. wrote:
>>> The Natural Philosopher wrote:
>>>
>>>
>>>> Not te code that gcc compiles, teh code of GCC itself.
>>>>
>>>> And its libaries,.
>>>
>>> And a trojan can propagate itself by exactly this mechanism.
>>>
>>>> Anyway, you could almost certainly not store a trojan in a compiler:
>>>> It has to be at the least in the libraries, and those are all source
>>>> open for inspection. As is the compiler itself.
>>>
>>> No. It can be inside the compiler binary, and compile its very own
>>> code to itself.
>> So, inspect the compiler code. At some level it has to show up, and all
>> levels are open to inspection.
>>
> It would appear ONLY in the binary version of the compiler. Never in the
> source, be it lex, yacc, C++, C, assembler, ...
>>
>> You will get some damned funny results if for example you use a compiler
>> trying to inject its own network access when you replace the standard
>> network access library stuff with something you have written yourself
>> for custom hardware. And shove it on a hardware debugger.
>>
>> You can't subvert EVERYTHING to not notice unwarranted network access.
>>
>>
>> Fer chrissakes, even a semi decent firewall with packet logging is
>> going to notice that socket calls to unknown addresses are taking place.
>>
>>
>>
> Yes, if you trust the firewall. You keep moving the target which is the
> trust of the bootstrapping process.
>
Jean? I love the young'uns, I really do. They think that the thickness of the
armor they're aware of in one spot defines the strength of the knight against
the his own squire shoving a dagger in the eyeslits while he sleeps.
Notice, for example, that he's now going about "network access". This is not
what we discussed, or what the original poster discussing SELinux asked about.
We talked about backdoors. For your and my comments about the antique work of
the creators of UNIX and C itself, those are secret passwords. That's a
*local* vulnerability, not necessarily network access at all.
And "Natural Philosopher"? I've been involved in writing 4 compilers, two
hand-built from scratch for a computer science course at MIT during my
undergraduate days, some antique bug patches to gcc many years ago, and some
minor contributions to gcc-based cross-platform custom hardware compilers
about..... 5 years ago. So yeah, been there, done that.
On Fri, 7 Mar 2008 17:19:52 -0600, John Thompson <john@vector.os2.dhs.org> wrote:
>On 2008-03-07, AZ Nomad <aznomad.2@PremoveOBthisOX.COM> wrote:
>> On Thu, 06 Mar 2008 14:39:33 GMT, Jean-David Beyer <jeandavid8@verizon.net> wrote:
>>
>>>It also assumes that the compiler on your machine is the one you have code
>>>for, and I do not know how you could tell that. Because if you do not, you
>> Please enlighten us on a version of GCC where nobody has examined the code.
Jean-David Beyer <jeandavid8@verizon.net> wrote in
news:5ABAj.2166$wM2.41@trnddc07:
> But the trojanized version is not. And once you compile the trojanized
> compiler, you can eliminate it's source code from the universe and it is
> too late. Because that compiler can contaminate everything it compiles,
> including the Gcc source.
>
A trojan in the object code is NOT always useful.
It is easy to have a bug that only shows up under very special
circumstances, it is very difficult to 'craft a "bug"' that adds a trojan
to the object ONLY when such a trojan would be usefun.
You can run some tests like:
1) compile a very simple program with a single instruction.
2) compile a longer program with multiple instructions.
3) compare the length of the objects produce to confirm that the length
grows with the number of instructions AND that the plot of complexity vs
length of object has an intercept of zero length.
A compiler that is smart enough to 'add a back door' to the object
produced is going to produce an object that contain ONLY the back door
when it compiles a very simple program or it will display a discontinuity
in the size of the object produced when the code compiled is reduced below
a certain length. Either will be obvious.
So a compiler that is adds it's Trojan to EVERY object produced will leave
an obvious 'finger print' on every object produced. The trojan code is the
finger print.
To avoid this, the compiler must be smart en ought to know the function of
the object code it produces.
A compiler smart enough to KNOW the function of the module it is being
called upon to produce and only add the Trojan to an object where the
Trojan would be useful would need to be tens of thousands of times larger
than any normal compiler.
While theoretically possible, it is impractical to produce such a compiler
because a trojan that adds itself to the compiler will have bugs in the
trojan's code. According to Smurfy's law, it would keep adding copies of
itself each time it was used to recomplile itself, until memory was
exhausted.
--
bz
please pardon my infinite ignorance, the set-of-things-I-do-not-know is an
infinite set.
bz+csm@ch100-5.chem.lsu.edu remove ch100-5 to avoid spam trap
> To avoid this, the compiler must be smart en ought to know the function of
> the object code it produces.
>
> A compiler smart enough to KNOW the function of the module it is being
> called upon to produce and only add the Trojan to an object where the
> Trojan would be useful would need to be tens of thousands of times larger
> than any normal compiler.
Nonsense. Simply do it on a random basis with low probability.
> While theoretically possible, it is impractical to produce such a compiler
> because a trojan that adds itself to the compiler will have bugs in the
> trojan's code.
It seems like you really didn't read "Reflections on trusting trust". It
shows exactly such a trojan horse, or better said, a program that writes
such a trojan hosre, and it's very clear and short.
> According to Smurfy's law, it would keep adding copies of
> itself each time it was used to recomplile itself, until memory was
> exhausted.
>A compiler that is smart enough to 'add a back door' to the object
>produced is going to produce an object that contain ONLY the back door
>when it compiles a very simple program or it will display a discontinuity
>in the size of the object produced when the code compiled is reduced below
>a certain length. Either will be obvious.
Not necessarily: the compiler proposed by Ken Thompson on
the turing award lecture "Reflections on Trusting Trust" proposed
a conditional trojan:
- code which recognized it was compiling the compiler and
add the compiler trojan to the compiler
- code which recognized it was compiling login.c and which
would add the login trojan to that program
All other programs would be unchanged.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
bz wrote:
> Jean-David Beyer <jeandavid8@verizon.net> wrote in
> news:5ABAj.2166$wM2.41@trnddc07:
>
>> But the trojanized version is not. And once you compile the trojanized
>> compiler, you can eliminate it's source code from the universe and it is
>> too late. Because that compiler can contaminate everything it compiles,
>> including the Gcc source.
>>
>
> A trojan in the object code is NOT always useful.
>
> It is easy to have a bug that only shows up under very special
> circumstances, it is very difficult to 'craft a "bug"' that adds a trojan
> to the object ONLY when such a trojan would be usefun.
>
> You can run some tests like:
> 1) compile a very simple program with a single instruction.
> 2) compile a longer program with multiple instructions.
> 3) compare the length of the objects produce to confirm that the length
> grows with the number of instructions AND that the plot of complexity vs
> length of object has an intercept of zero length.
>
> A compiler that is smart enough to 'add a back door' to the object
> produced is going to produce an object that contain ONLY the back door
> when it compiles a very simple program or it will display a discontinuity
> in the size of the object produced when the code compiled is reduced below
> a certain length. Either will be obvious.
>
> So a compiler that is adds it's Trojan to EVERY object produced will leave
> an obvious 'finger print' on every object produced. The trojan code is the
> finger print.
>
> To avoid this, the compiler must be smart en ought to know the function of
> the object code it produces.
>
> A compiler smart enough to KNOW the function of the module it is being
> called upon to produce and only add the Trojan to an object where the
> Trojan would be useful would need to be tens of thousands of times larger
> than any normal compiler.
>
> While theoretically possible, it is impractical to produce such a compiler
> because a trojan that adds itself to the compiler will have bugs in the
> trojan's code. According to Smurfy's law, it would keep adding copies of
> itself each time it was used to recomplile itself, until memory was
> exhausted.
>
Sigh. Alright, youngsters. We're not talking about a module that is that
unusual: the "password" module is antique, and quite stable. All the Trojan
had to really know was the name of the module. Code drift might eventually
break the Trojan, it, for example by writing the module and more of the
compiler in C++. But it was a very powerful proof of concept, not the sort of
complex infinitely robust and self-modifying module needed to run forever and
ever. So the module disappears after code drift? Fine, you've had a few yars
with remote access to your target's systems to insert another one.
The "copy itself forever" is what happened to the Morris worm.
On 2008-03-08, Jean-David Beyer <jeandavid8@verizon.net> wrote:
> The Natural Philosopher wrote:
>>
>> You will get some damned funny results if for example you use a compiler
>> trying to inject its own network access when you replace the standard
>> network access library stuff with something you have written yourself
>> for custom hardware. And shove it on a hardware debugger.
>>
>> You can't subvert EVERYTHING to not notice unwarranted network access.
>>
>>
>> Fer chrissakes, even a semi decent firewall with packet logging is
>> going to notice that socket calls to unknown addresses are taking place.
>>
>>
>>
> Yes, if you trust the firewall. You keep moving the target which is the
> trust of the bootstrapping process.
>
No, it's not moving the target. You're proposing a compromise scenario
that requires multiple targets to be compromised. The compiler has to
be comprimised, the network utilities have to compromised, the firewalls
have to be compromised... That's the point. That's why it's unlikely.
--
Christopher Mattern
NOTICE
Thank you for noticing this new notice
Your noticing it has been noted
And will be reported to the authorities
Chris Mattern wrote:
> On 2008-03-08, Jean-David Beyer <jeandavid8@verizon.net> wrote:
>> The Natural Philosopher wrote:
>>> You will get some damned funny results if for example you use a compiler
>>> trying to inject its own network access when you replace the standard
>>> network access library stuff with something you have written yourself
>>> for custom hardware. And shove it on a hardware debugger.
>>>
>>> You can't subvert EVERYTHING to not notice unwarranted network access.
>>>
>>>
>>> Fer chrissakes, even a semi decent firewall with packet logging is
>>> going to notice that socket calls to unknown addresses are taking place.
>>>
>>>
>>>
>> Yes, if you trust the firewall. You keep moving the target which is the
>> trust of the bootstrapping process.
>>
>
> No, it's not moving the target. You're proposing a compromise scenario
> that requires multiple targets to be compromised. The compiler has to
> be comprimised, the network utilities have to compromised, the firewalls
> have to be compromised... That's the point. That's why it's unlikely.
>
>
Not really. Once you compromise the _su_ program or the _login_ program, you
can do anything you want.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 14:00:01 up 3 days, 20:01, 2 users, load average: 4.50, 4.48, 4.43
Chris Mattern wrote:
> On 2008-03-08, Jean-David Beyer <jeandavid8@verizon.net> wrote:
>> The Natural Philosopher wrote:
>>> You will get some damned funny results if for example you use a compiler
>>> trying to inject its own network access when you replace the standard
>>> network access library stuff with something you have written yourself
>>> for custom hardware. And shove it on a hardware debugger.
>>>
>>> You can't subvert EVERYTHING to not notice unwarranted network access.
>>>
>>>
>>> Fer chrissakes, even a semi decent firewall with packet logging is
>>> going to notice that socket calls to unknown addresses are taking place.
>>>
>>>
>>>
>> Yes, if you trust the firewall. You keep moving the target which is the
>> trust of the bootstrapping process.
>>
>
> No, it's not moving the target. You're proposing a compromise scenario
> that requires multiple targets to be compromised. The compiler has to
> be comprimised, the network utilities have to compromised, the firewalls
> have to be compromised... That's the point. That's why it's unlikely.
>
>
Well I pronabaly found out why teh OPs network light was flicketing whne
he wasn;t doing anything..gotr hid for an excess charge for bandwidth
used..when I hadn't been using anything.
Router logs were bleating about 'echo storm attack' for 10 HOURS on
sunday. 1.4BGytes of echos were fired at my router..
which dutifully echoed them back..this doubling the traffic..
Who needs te BNSA when any nerd with a university bandwidth connection
can waste your money for you?
In comp.security.misc plenty900@yahoo.com wrote:
> I've learned that there are bits of NSA's SELinux in various
> places in kernel 2.6. How can I be sure that Big Brother isn't
> using back doors or bugs to break into my computer?
You can't. You have to trust in people reading the source code detecting
what's going on.
> How much safer would it be to just switch back to 2.4 or 2.5?
I cannot see any safety in it.
Yours,
VB.
--
The file name of an indirect node file is the string "iNode" immediately
followed by the link reference converted to decimal text, with no leading
zeroes. For example, an indirect node file with link reference 123 would
have the name "iNode123". - HFS Plus Volume Format, MacOS X
On 2008-03-11, Volker Birk <bumens@dingens.org> wrote:
> In comp.security.misc plenty900@yahoo.com wrote:
>> I've learned that there are bits of NSA's SELinux in various
>> places in kernel 2.6. How can I be sure that Big Brother isn't
>> using back doors or bugs to break into my computer?
>
> You can't. You have to trust in people reading the source code detecting
> what's going on.
>
>> How much safer would it be to just switch back to 2.4 or 2.5?
>
> I cannot see any safety in it.
>
Bingo. If you're paranoid, you can see the possibility of being
pwned by anything (and I'm not saying such paranoia is completely
wrong). But if you're asking if SELinux makes it more likely,
the answer has to be no. The risks, like a trojan compiler,
that have been discussed here are no riskier for SELinux
than for ealier Linux editions.
--
Christopher Mattern
NOTICE
Thank you for noticing this new notice
Your noticing it has been noted
And will be reported to the authorities
Re: Does kernel 2.6 include an NSA backdoor? 
Linear Mode
