Slashdot Mirror

You're talking about the trusting trust attack, which was made famous by Ken Thompson.

It is not showing figure 1, I was really interested why it looks like.

It was Ken Thompson, the man himself, that you're referring to. The talk in question can be found here: http://cm.bell-labs.com/who/ken/trust.html

Figure 1 is broken, I was really curious to see what is it?

They have a lot to do - they'll have to bootstrap this thing from the assembler on up if they are serious about security - http://cm.bell-labs.com/who/ken/trust.html

You're talking about the trusting trust attack, which was made famous by Ken Thompson.

Thankfully, you can counter the "trusting trust" attack using a technique called "Diverse Double-Compiling" (DDC). See the linked PhD dissertation for details.

Of course, there is still always the possibility you have a hacked C compiler. Man, I can't remember the name of it now, but sometime in, I think it was the 80's, someone made a pretty famous presentation/paper about putting a self-perpetuating trojan into a compiler. You could give the compiler source code, and the binary of the compiler to the 'mark', but you could completely remove the exploit from the source code, as long as the exploit was coded to compile itself into subsequent builds of the compiler; that is, the binary was infected, but the source was not, but it didn't matter since the infected binary could build a copy of itself into the next build of the compiler. The exploit could then additionally do something like whenever it built other binaries or libraries, add some exploit code to them as well.

That would be Ken Thompson.

It was Ken Thompson, the man himself, that you're referring to. The talk in question can be found here: http://cm.bell-labs.com/who/ken/trust.html

Ed was never pioneering in any sense—if you're going to be romantic about the past, at least be right. It's essentially a minimalist clone of qed made by and for, as usual, Unix guys who couldn't run the real deal on their low-end PDPs. qed/qedx, for the record, had all sorts of bells and whistles, including at one point regexes.

Ever read "Reflections on Trusting Trust"?

http://cm.bell-labs.com/who/ken/trust.html

Once you have, think about whether it is ever a good idea to have a customer's device decide whether the customer should get access to the Internet (assuming you're saying customers own the router).

Who exactly do you need to trust?

Ken Thompson? Reflections on trusting trust.

Plan9 has what's called Venti,

"...Venti, intended for archival data. In this system, a unique hash of a block's contents acts as the block identifier for read and write operations. This approach enforces a write-once policy, preventing accidental or malicious destruction of data. In addition, duplicate copies of a block can be coalesced, reducing the consumption of storage and simplifying the implementation of clients. Venti is a building block for constructing a variety of storage applications such as logical backup, physical backup, and snapshot file systems."

http://plan9.bell-labs.com/sys/doc/venti/venti.html

See Ken Thompson Reflections on Trusting Trust.

Now that there are multiple independent implementations of a C compiler, such as Clang for LLVM, TCC, and GCC, the trusting trust attack can be defeated with a compile farm.

But did you build your OS via tapping bits onto the SATA bus with a paperclip? Otherwise you have no idea what your OS is putting in there. See Ken Thompson Reflections on Trusting Trust.

I'd say it's the best programming book ever written (or at least the best I've read).

Some books that went a very long way for me: Code Complete http://en.wikipedia.org/wiki/Code_Complete Programming pearls: http://www.cs.bell-labs.com/cm/cs/pearls/ I won't add Knuth here as that was (kind of) a textbook but...

Reflections on Trusting Trust http://cm.bell-labs.com/who/ken/trust.html

http://cm.bell-labs.com/cm/cs/tpop/ - Kernighan is the Kernighan from K & R. I doubt Kernighan would co-author a book with an amateur ...

Here is his bio - http://herpolhode.com/rob/ . I doubt you'd be hiring a bad programmer.

nope, rob pike doesn't know much about real world programming. his code it a twisted mess

http://plan9.bell-labs.com/sources/plan9/sys/src/libthread/

You seem confused. He said C++ is complex, not C, and he is entirely right.

Yes. Actually, Pike loves C. He has written a C compiler for Plan 9. The language he co-designed was C-like. And I don't remember the source, but I once read that he writes object-oriented in C, using structures and pointers!

You seem confused. He said C++ is complex, not C, and he is entirely right.

Yes. Actually, Pike loves C. He has written a C compiler for Plan 9. The language he co-designed was C-like. And I don't remember the source, but I once read that he writes object-oriented in C, using structures and pointers!

Ken Thompson would show you how you'd fail in this anyway.

The Trusting Trust attack as Ken Thompson described it can be worked around using "diverse double compilation". To defeat this, a compiler virus would have to know how to infect GCC, TCC, Clang, and every other popular Free compiler for a given language, including non-self-hosting compilers (those written in another language entirely). Bruce Schneier explains, as does David A. Wheeler. Likewise, in the case of writing firmware to a flash memory, the would have to know how to infect a Willem programmer, a Wellon programmer, and every other popular flash programmer.

Even if you read all the code, you still can't be sure.

Unless you go through all the code yourself, there's no way to be sure of anything.

you mean unless you go through the code, compile it yourself using a compiler whose code you've also audited and itself was not compiled by an unaudited compiler

ipX, for the win:

"In the ten years that we have worked together, I can recall only one case of miscoordination of work. On that occasion, I discovered that we both had written the same 20-line assembly language program. I compared the sources and was astounded to find that they matched character-for-character."

http://cm.bell-labs.com/who/ken/trust.html

Reflections on Trusting Trust

Close. It wasn't code that was injected, it was proprietary binaries. In other words, closed source kills. Yes, the same general category that gives us billions of lost hours from crappy drivers for good hardware. The same general category that is responsible for providing an incubator for the world's botnets.

That makes what Novell, Black Duck and other branches of Microsoft are doing so profoundly bad when they try to re-label their proprietary binaries 'open source' without releasing the full source. Just releasing some of the source doesn't count, it's as bad as all-binary proprietary. By release, that means read, edit and re-compile. Anything less is just plain dangerous.

You'd think that countries would learn. Or at least the US would learn. As things are, TSA is shaking people down for baby milk instead of doing something useful like nuking each and every NTFS partition on every harddrive that passes through customs. During a transitory period of a year or two, they could take it easy on the scum by just erasing every file ending in .com, .exe, or .dll and handing them a Fedora live CD. Tracking down and locking up the present and former executives of Microsoft and its partners would be another step forward. Off to Gitmo with the lot.

They have the MAC, IP.

...of the access point, not the offending machine.

Trace the MAC as the unit was paid for by credit card ("cop" makes a few calls)

They would only find out which cafe you uploaded from. Why do both google and the credit card company give out their combined information easier than an ISP would?

and get the local surveillance tapes.

Well, there's your problem; If you have enough cameras that your local government can know everyone who passed through a particular cafe, you have a problem quite independent of wifi-geolocation. Even if such surveillance is the case, I don't see how you make the jump from "anyone in the cafe" to a particular person in the cafe.

No warrant, much less paper work needed

You are assuming various groups turn over information as convenient to your scenario, while the ones that existed prior to wifi-geolocation would not. You do not back any of these up, so it is a pretty flimsy stack on which to base your assertion here.

and they have Googles GeoAds v3.1 wifi coupon and banner software to light up all MACS in their city.

Here you are assuming software which does not exist, passing out information that current systems to not (client machine MAC data, passed back to advertisers/clients/governments). If you're going to walk this far into the tinfoil forest, you could also assume that the government has convinced your OS vendor to install keyloggers on every machine as part of a security update. Or maybe that has already been built into the compiler.

A known face is noted, no more leaks ever again.

Your scenario reads like a cheap spy novel.

Your ISP is very protective of your IP and home address, why just gift a cities open MACs and locations over to a US corp to sell to anyone?

You assume that ISPs will remain "good", while google will become "bad". Both have a history of turning over information only when ordered to by courts (warrantless wiretapping aside), though both are also at the mercy of the government and recent crappy laws (patriot act etc). I don't see why you would trust your ISP more than google, as both have access to similar amounts of information. I can understand trusting neither company, but in that case you shouldn't be using the internet if you really that worried about privacy.

Also, I see many posts claiming google will "sell to anyone", yet nobody ever seems to come up with any evidence of google actually selling non-aggregated information. They use it themselves for ad products, but that's not the same thing as selling data profiles of individual people. You must be confusing them with Acxiom or similar companies.

I much prefer the Linux app distribution model.

Even auditing the code doesn't help. The only thing crazier than running a browser and OS whose code you've not audited is auditing the browser's and OS's code but then compiling them! The only way out is to write the compiler in pure machine code yourself.

...and then you just have to run it in your head -- you can't trust hardware!


More seriously, proprietary software requires you place all your trust in one entity. With open-source software, that trust is more distributed, and it's less likely that someone was able to bury something malicious, especially if there's an active and large developer community. This isn't at all to say there can't be anything malicious (or flawed) in OSS, but it's easier to trust a large group of people that have nothing to gain from duping you and who know they would probably get caught than it is to trust a single company that might have something to gain and can probably get away with it.

With proprietary software, you're betting that a specific company won't fuck you over.
With OSS, you're betting that at least one person out of a community of developers (and users who actually do audit code) won't fuck you over.

Python is FOSS so there is no black box.

Ken Thompson smiles upon your trust.

And how do you know that? On what grounds you're putting this trust in most of the closed software you use? (heck, also open one...did you make sure all your binaries are fine? Do you trust all eyes looking at the code? The compiler?)

Exactly. I considered linking to this in my post above, but it seemed a little too philosophical for the topic. Still a great read, and excellent point.

Xenix on an Altos 586 would have been licenced from Microsoft, not SCO, and was Microsoft's version of Unix (they had a license from AT&T / Bell Labs). Later Microsoft sold their Xenix stuff to SCO.

I have install disks for Xenix 2 which was 7th edition Unix (manuals are on the web http://cm.bell-labs.com/7thEdMan/) and Xenix 3 which was AT&T System III (pre System V).

My system had a 40 MB ST506 Hard disk (you could only access 32 Meg), a 720 KByte floppy drive (Double sided, Double Density 96TPI, 5 1/4") and 5 (or was it 6) serial ports, 512K of memory and an 8086 processor. I think that the 586 name indicated that you could have 5 users and a printer connected on a 8086 processor. The Altos 986 had 10 ports for 9 users!

By far the easiest way to get data on and off at the time was using the floppy. With a 10 meg drive it would only take a dozen or so floppies to back the system up. Tar was the standard backup command, but I think there was an odd extension to tar for multi-volumes.

I think all the machines should have had 720KB floppy drives. Xenix came on floppies and so did diagnostics. These are much easier to swap with other systems than ST506 hard disks. Other systems such as some NEC PCs (IBM clones) also used these 720 KB drives And they were pin compatible with 720k 3 1/2 drives (different connector, but same pins).

Second best method was kermit (I remember having a lot of trouble trying to compile kermit on this) and with a 10 meg system, it is quite possible that you don't have a C compiler.

UUCP is an option, but it may not be installed. You could also use cu from another unix system, but it does not have error checking.

However if it was a BBS server, there is a better chance that it does have Kermit, UUCP, or X-modem software installed. I think the serial ports default to 9600 baud, 1 sotp bit, no parity.

Many of the comments suggest using SCO software. Most SCO software requires either a 286, 386, or higher processor and won't run on an Altos 586. SCO did sell Xenix for 8086, but it was not very widely used.

Of course I bought this machine around 1987 and threw it out around 2004, and my memory is a bit rusty, so my comments should probably be considered as hints at the truth.

Grant

Most languages still handle concurrency very badly. C and C++ are clueless about concurrency.

c itself isn't aware of concurrency, but so what? that doesn't mean that a program written in c can't be aware of concurrency. for example, the bell labs thread library manages threads and procs and provides channels for locking and communication between them. the syntax can get clumsy if you aren't careful, but that's the only problem i can think of

Go [... is] intended for server-side processing.

what makes you think that? it's a general purpose language

here's a ton of stuff that might interest you: http://swtch.com/~rsc/thread/

Talk to these folks, they'll get you on the right track.

Plan 9:

http://plan9.bell-labs.com/plan9/

http://plan9.bell-labs.com/wiki/plan9/mailing_lists/

If there's a way - they'll set you on the right track.

Talk to these folks, they'll get you on the right track.

Plan 9:

http://plan9.bell-labs.com/plan9/

http://plan9.bell-labs.com/wiki/plan9/mailing_lists/

If there's a way - they'll set you on the right track.

The referenced to article doesn't actually state he included a back door. It was a proof of concept demo apparently: Suppose we wish to alter the C compiler

"one the creators of Unix, admitted that he had included a backdoor in early Unix versions. Thompson's backdoor gave him access to every Unix system then in existence"

Except that the Windows command line, and MS focus on it, has improved massively (out of all recognition really) in the last 2 or 3 years.

You're definitely true. I'll be the first to say that, for instance, the PowerShell object-piping thing is a really neat and useful idea.

But, IMO, it's still far from what you see on a Unix-like platform in terms of actual usability. I mean, even the terminal emulator that hosts both CMD and PowerShell is still a huge turd. I mean, even in Win7, you can't even resize the damn window (in ways that matter) without going into a dialog box and changing the width field. Then there's a bug through XP (seems to be fixed in Windows 7) that causes it to ignore (most of the time) my keyboard layout changes.)

Then you get to things with the shell itself. For instance, the fact that the tab completion behaves differently from Unix isn't a problem on it's face, but having used both variants extensively (I don't usually use Cygwin shells when in Windows; I take a pretty strong "when in Rome" approach to that), I much prefer the Unix-shell version. (The CMD/PowerShell tab completion method, while sometimes handy, has two significant problems: unless you know your directory contents really well, it's not very predictable. Second, the worst-case behavior is terrible. There are some other minor issues like not being able to tab complete something in the middle of a command without it wiping out everything that follows, and not tab completing through a forward slash despite most commands and programs accepting them. PowerShell doesn't have that very last problem.) Another thing I miss a ton is ctrl-R, for reverse incremental search. F8 does something similar in CMD, but... it doesn't seem to work very well for some reason. It doesn't seem to work at all in PowerShell.

Disclaimer: I've played with PowerShell a little bit, but only a little bit. It looks like you can do things like customize the tab completion behavior, so it's possible that some of my concerns could be alleviated.

(Finally, believe me, I'm no "rah rah Unix/Linux" person; I've been called a MS shill on a couple of occasions. You say "age old Unix story of stagnation through fragmentation", which I don't quite agree with, but I do feel that there are a lot of people out there who believe that almost everything Unix does it does right, that the autotools really aren't that bad, that it's actually a reasonable decision to use 'make' for a C project, etc. is a big problem, and that they can be as prominent as they are is holding back Linux. I'm very sympathetic to parts this presentation (now a decade old) by Rob Pike, where he says that systems research is hurting because people get set in an orthodoxy. (See pp. 14, 16, 17.) (And if you look at his credentials, he's not exactly a MS shill either.) In my opinion, Windows actually serves a very very valuable purpose -- it's the only OS in even moderately wide use that isn't backed by Unix. The fact that they do things differently is, in and of itself, valuable -- even if they don't always get it right. (Because, IMO, they do get right in ways that Linux/Unix doesn't as much as they get it wrong.) I take the position of disliking every OS out there pretty strongly, just in different ways.)

It could also be the other way round - on Unix you have the command line heritage, but also it's much more of a pain to create a GUI, so even if you start out thinking "this tool should have/be a GUI", you may end up with command line.

It's possible, though I would still say that, in most cases, it probably more has something to do with the mindset.

You've got to build your own toolchain, too.... from the bare metal.

Reflections on Trusting Trust.

And I guess you have to trust the CPU not to have backdoors, too...

To answer your first question, you're partially correct that a debugger can do wonders to highlight malicious code. Of course, as you point out, knowing when and where to use a debugger can be a little challenging. And then the realization that unless exceptional care is taken, the code you're stepping though might not even contain or reveal the exploit. (Since the mere act of viewing the byte code in a debugger can change affect it's operation.) There's one story that really opened my eyes to the possibilities. I don't remember where the long beards keep the real link, but this seems to be the story I remember:

http://cm.bell-labs.com/who/ken/trust.html

This was the first story of real high level obfuscation I learned about in college. As a result of Ken Thompson's little speech here, he caused the DOD to change the way they do code reviews to catch back doors like this. And the obfuscated C challenges have been going on since at least the early 80s. Some of the winners are real treasure troves of high level trickery.

http://www.ioccc.org/years.html

If you manage to get this into the GNU/Linux Kernel, you get a job at the NSA.

No, you should write a self-reproducing 'bug' for a well-known compiler suite: Reflections on Trusting Trust

Rather than playing with just another un*x clone, try something like Haiku or FreeVMS or my personal favourite Plan 9

Dennis Ritchie has a whole page of comments in the Unix source code, and what information they convey.

the go authors have a decades-old practice of deliberately choosing annoying names "in the Bell Labs tradition of selecting names that make marketeers wince."

http://plan9.bell-labs.com/wiki/plan9/FAQ/index.html

You might read up on Trusting trust.

And I have heard of the NSA (or CIA, or some TLA agency) examining chips in routers, in search of discrepancies. IE trojans, at the chip level.

You only THINK your tin foil hat is too tight...

How many programs on your system do you *fully* understand? How certain are you about that?

Maybe we should have some sort of trust system where programs can be 'signed'. And to make sure the verification software hasn't been compromised, we could have a hardware module that verifies the boot loader, etc... Some sort of Trusted Platform hardware module...

How many programs on your system do you *fully* understand? How certain are you about that?

For learning how to use Unix, I liked The Unix Programming Environment. Although it shows its age, the book helped me move from the opaque feeling I get from working with black-box GUIs to an understanding of the Unix philosophy: tools that are as simple as possible. It taught me to be comfortable with the shell and low-level utilities. And I love Kernighan's dense writing style.

kids - read Shannon thouroughly as well, starting with "A Mathematical Theory of Communication"

Interesting, for sure, but what does it have to do with programming?

Link, by the way: A Mathematical Theory of Communication

Read this.

I'm pretty sure the original poster for OS9 was not talking about MacOS 9. There's an old OS called OS9 that had nothing to do with Macs.

I think you are probably referring to Plan 9 from Bells Lab.
http://plan9.bell-labs.com/plan9/

yup

apparently it's still available and according to wiki it's still being maintained and used