Slashdot Mirror

Sorry to tell you, but Ken Thompson talked about you how you pretty much have to trust someone back in 1984: http://cm.bell-labs.com/who/ken/trust.html

If no one else, you have to trust the compiler author isn't pulling a fast one on you....

Compiling it yourself does not necessarily help.

Anybody who wants to have a meaningful discussion on this subject needs to read Ken Thompson's 1984 ACM article "On Trusting Trust". In it he describes inserting rogue code into the compiler that recognizes when it's compiling a compiler and replicates into the executable of the compiled compiler - and so becoming persistent across a platform migration. This is just the transport mechanism. The payload is code that recognizes the Unix Login and subverts its security. Obviously, once the first compiler is compiled with this trojan the source code for it can be removed and all subsequent compilers compiled with this trojaned compiler will have the code no matter what platform it migrates to.

It doesn't just seem like we've been having this discussion for 30 years. We actually have. In order to have a compiler you can actually trust you need to implement its progenitor in machine language using a byte editor, and even then you need to manually compute a checksum for the mini-compiler that can be checked from a system running an OS not derived from it. Fortunately a minimum C compiler is pretty basic and it's not that hard to implement in binary. Starting with a basic assembler is even easier.

For those who don't know: Ken Thompson's CV includes the phrase: "I invented Unix" among many other valuable contributions. If anybody would be informative on this topic, he would.

Do you not use any computers in aerospace manufacturing at all? Any computer program *CAN* do something dangerous, unless you audit every line of every program and build the computer hardware in house from scratch(see 'Reflections on Trust by Ken Thompson'). I'm not sure what Google saying that it can do something dangerous has any bearing and more so I don't know the context of that quote. Google obviously isn't going to say all apps from the Play store are perfect, because NO software or hardware company says that. I'm also not saying that Google is necessarily the best company to trust with aerospace parts either, I'm just saying that line of reasoning is flawed and doesn't make a lot of sense.

It would be cool if you could get Plan 9 working. It's an OS that was designed around distributed computing from the ground up. So much so that the API is hardware agnostic. It doesn't matter what hardware you are running or where it exists. All resources in the cluster are shared automagically. You would need some distributed rackspace in strategic global locations.

Step one is making a small lab with junk computers.
Step two is testing your application in this environment.

If you can get the backend running on Plan 9 then you can start renting servers, installing Plan 9 and adding these servers to your existing cluster. At some point you will be able to turn off the computers at your house and the app will keep running on the remaining cloud servers. It's a pretty sweet idea.

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

It's kinda like UNIX.

Good luck.

Why is he labeled troll? I mean seriously who doesn't know that Windows 8 sucks? Its the first MSFT OS since WinME I won't allow in my shop and I'm making as much wiping it for Win 7 as I did wiping Vista for XP which was quite a lot.

And please do NOT give us that "Oh its just 7 with a start screen" bullshit because that is what it is, bullshit. I'd love nothing more than to talk to some of the internal devs of Win 8 because i truly believe that "refresh your PC" was NOT put in there to help users but because they knew there was serious flaws they couldn't fix before RTM. I haven't had to reinstall a single Windows 7 system that the user hadn't gotten infected, with Win 8 I've probably made a good $800 in the past couple of months from folks bringing their laptops in for me to do just that with Win 8 as it shits itself a LOT.

Frankly the confusion over Win 8 VS Win RT is just the stinky tip of a shit iceberg, the whole damned thing is just a mess. Oh and "keyboard commanders" don't bother replying, you are full of crap and here is a study proving it. The simple fact is when you HAVE to be a keyboard commander and memorize a shitload of keyboard commands on an OS that MSFT designed for keyboard-less touch tablets? Something has gone horribly horribly WRONG.

Lets cut through the bull, Win 8 and WinRT is gonna be on every "worst of" list come Dec and the fact that even the fricking retailers don't know the difference should just show how badly thought out the whole thing was. I only hope that after ballmer shits out "Windows Blue" and the board sees its just as fucking stupid and pointless as Win 8 (you are focusing on touch, when more than 98% of the PCs DO NOT HAVE TOUCH and the OEMs are saying "We can't sell the touchscreens as nobody wants 'em" and you don't see that as a problem? Really?) they will punt kick his fat sweaty ass like a 40 yard field return and bring somebody in there with a functioning brain...fuck put ME in charge and I'll double the numbers in 2 years or you won't owe me a dime!

Spin off mobile, make Metro OPTIONAL on systems that aren't ARM and focus on a "it must be simple and work no matter what" mantra, oh and toss the mess that is Win 8, build the optional metro on the much more solid Win 7, and add services that will allow you to monetize those that stick with previous builds. hell I can think of two just off the top of my head, make deals with the media companies to make any laptop with an HDMI out and Windows Media Center into a media powerhouse and use the MSFT servers to allow home users and SMBs with a thumbstick remotely access their PCs from anywhere.

But any other corp would look at the facts, Win 8 bombed, WinRT bombed, numbers falling, users not even able to shut the damned thing down without knowing shit they have no reason to know, and see the whole direction is a failure. Instead we get what we see in TFA, where even the retailers don't know WTF you are selling or the differences between the models. What a fucking mess.

Bimbo Newton Crosby, all these "keyboard commanders" jumping through keyboard commands are merely trying to cover up a bad design because honestly you can drive Windows 7 (and Vista and XP for that matter) with JUST a mouse and it works fine, its ONLY Windows 8 that keyboard commands become mandatory. Which is ironic since MSFT is pushing what is supposed to be a tablet OS onto the desktop. The fact that their tablet OS needs a keyboard to be usable? Just shows how made of fail it is.

And all those keyboard commanders might want to read a study comparing mouse to keyboard and the verdict? if the UI is well designed then the mouse is faster. Of course since Win 8 practically requires a keyboard I think we can take from that that Win 8 is a bad UI design.

Yep, another typer thinking he is the shiznit because he is keyboard addicted. No, you are not the second coming because you use a keyboard. People proficient with a mouse and a UI that isn't braindead are just as fast (if not faster) than a typer. TIFKAM is just deficient in the mouse department and that only leaves the keyboard as a means to control it halfway decent.

For your reading pleasure: http://plan9.bell-labs.com/wiki/plan9/mouse_vs._keyboard/

You need to compile this compiler with a compiler which begs the question....

Sigh. It raises the question. To "beg the question" means something completely different. Here is a simple rule of thumb of when that phrase should be used: never.

How was the first compiler compiled?

The first compilers (Fortran and Lisp) were written in assembler. Later compilers were written in Lisp or Fortran.

New languages can be bootstrapped by first implementing a sufficient subset, and then expanding it. Ken Thompson explains this process (and how to subvert the process) in his Turing Award lecture on Trusting Trust.

Or compile gcc with gcc?

Not if Ken Thompson contributed to gcc, unless you've taken sufficient care.

Even OSS can be vulnerable

Whatever happened to Plan9?

If you are serious about this project I would use Plan 9 because it is designed to use all of your hardware transparently. They can always use more members in this small community. You might find this underrated platform quite delightful:

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

Ignore all the naysayers. Just having experience with Plan 9 makes this experiment worth it.

Only if you can read machine code. The source only gets you so far if the compiler's compromised - see Reflections on Trusting Trust.

Also, even compiling from trusted source is no good if your compiler is compromised.

The paper is very interesting, but if you don't want to read the whole thing, just read the section under the heading "Moral".

and it doesn't guarantee that the compiler doesn't have a backdoor of it's own.

The point is... you can find a browser that doesn't fuck you over and use that.

And you can find a phone that doesn't take advantage of you and use that. The trouble is, this sort of "doesn't take advantage of you" isn't exactly a selling point among the mass market, which means a product like this won't be produced for a mass-market price.

for things like, say, open source browsers, you can read the code and see what it is doing.

But do most people verify that the binary they download matches the source code? And do they diverse-double-compile their compiler toolchain to make sure it isn't infected with a "Reflections on Trusting Trust"-style virus? I'm under the impression most end users take this on faith.

Verifiability: you can trace the source code and know precisely what is being done in your analysis.

That one is only mostly true: You can trace the source code, which is great most of the time, but if you have a "creative" compiler, it might do something different than what you'd expect, and if you run on "creative" hardware, it might do something different than what the source code and compiler expect. This is the old Reflections on Trusting Trust argument.

How does the Android SDK's license compare to the iOS or Windows Phone SDKs? Is there a cross compiling issue where the iOS or WP SDK's are saying they'll compile to Android, and the Android SDK being formerly Free software means it's not being treated as it should?

iOS and WP are compared to Android constantly. Above posters have mentioned Ubuntu Mobile more than the actual market competitors, but as we learned yesterday Ubuntu Mobile is Android.

As we know from Trusting trust, the Android SDK has become less trustworthy, but fortunately Android is still Linux.

What this gets down to, even starts heading down that path right in the question, was covered by Ken Thompson in the classic paper "Reflections on Trusting Trust": http://cm.bell-labs.com/who/ken/trust.html

There are some good questions in there but, the rathole its starting to go down is not helpful. You need to look at what secure means to you first. What are the use cases for the environment? What does the environment need to allow? What should it not allow? Why? Answer those, and the path forward will become more clear.

There is no way you can avoid putting trust on something outside your own control, be it the C compiler, firmware on the motherboard or the CPU itself. So what you really are asking is "where should I put my trust level". That depends extremely from person to person and is next to impossible to answer, almost like asking "what car should I buy". You cannot expect good answers to what you ask without providing good indicators about what threats you consider important. However, the slashdot crowd usually does not pay any attention to the original question in any case, so maybe it is not that important :)

The first rule of software is that all software beyond the barest of trivial examples will have bugs. Compilers are software, and have the same long and sordid history of bugs. Since compilers have been mentioned specifically, you might be interested in the classic work Reflections on Trusting Trust (it was apparently written by a guy who knows a thing or two about the topic, some Ken Thompson fellow).The same goes for test suites. In many cases, bugs translate to security vulnerabilities. In some cases, perfectly rational behavior demonstrated by entities known as programs results in unexpected behavior when they are made to exchange data. This phenomenon is referred to as "novel outcomes" in some circles, and "wow, that's some fucked up shit" in others. There is a reason the field of information security is as broad as it always has been, is, and always will be.

Your post proves you have never worked as a professional developer, or for an organization where your role was deeply connected to systems or development work. Heck, it proves you've never worked on any major open source project either, for that matter. I suppose we should all stop using anything resembling software immediately to prevent the planet from caving in under the weight of its own failure. Or perhaps you should take your obviously extremely advanced software engineering skills and produce the one true invulnerable platform for everyone, one layer and application at a time.

As Bruce Schneier famously said, "security is a process, not a product." That process never ends, and involves complexities I believe could be delicately framed as things that aren't exactly your area of expertise. That's okay, though; you can always start educating yourself immediately. We're all looking forward to your next batch of brilliant revelations on infosec strategy.

One of the threats I expect to see more of is in the vein of Ken Thompson's hack, where a compiler (or any other build tool) hosts a trojan and infects other programs it compiles (or links, assembles, etc.) practically undetectably. With open-source software taking an ever-more-vital role in the Internet's core systems, will this kind of attack be easier to detect (perhaps due to the widespread availability of still-clean compilers), or more difficult (perhaps due to the wide network of trusted developers)?

First, she needs to read claude shannon's "a mathematical theory of communication"

http://cm.bell-labs.com/cm/ms/what/shannonday/shannon1948.pdf

Also, this class may help:

https://itunes.apple.com/us/itunes-u/principles-digital-communications/id341597796?mt=10

A Mathematical Theory of Communication by Claude E. Shannon

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

They need extensive testing and an object level code audit, along with tool chain certification to insure what they are running is what the code represents.

http://cm.bell-labs.com/who/ken/trust.html "The moral is obvious. You can't trust code that you did not totally create yourself."

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

If you haven't read it, or even if you haven't read it recently, you really should.

Even if you get the source, can you trust your compiler?

It's not the BSD compiler rootkit. It's the original AT&T "cc" command.

Reflections on Trusting Trust by Ken Thompson, himself.

To ensure that the module itself hasn't been tampered with once it has been validated.

Verifying correctness of the algorithms and their implementation was the purpose of the lengthy NIST validation process.

After that, before each use, they're checking to make sure someone hasn't pulled a fast one and modified the code.

Ken Thompson's ACM classic Reflections on Trust back in 1984 really laid this issue to bare. He was discussing compilers, and considering OpenSSL's validation is for source code and you can compile it yourself, it is very pertinent.

No matter how few people actually read through the Linux kernel code, it's sufficiently open that blatant backdoors are not going to be inserted.

Open source suffers from quasi-religious stuff too, as you just demonstrated with your claim. Ken Thompson, of Bell Labs and Unix and C fame - the "K" in K&R, demonstrates the insufficiency of being able to read the source code.
http://cm.bell-labs.com/who/ken/trust.html

The problem is we havent seen TRUE computer voting in action.

Do you have any idea how expensive that would be, to really do that right?
1. All hardware would have to be thoroughly verified and checked, pin by pin, to ensure that nothing funny was going on.
2. Any operating system used on the machines would have to be verified, byte by byte, to ensure that nothing funny was going on.
3. And of course, you'd also have to verify the compiled software used, byte by byte (if you want to know why the compiled software rather than the source has to be verified, read Reflections on Trusting Trust by Ken Thompson).

And yes, we don't have any of that verification done today, but that's what would be necessary if we wanted a computer that was able to do a job as good as a human hand-counted system.

Really, paper ballots and human counters work just fine, on any scale (Too many votes? Add more counters.). Electronic voting is a solution in search of a problem.

Not necessary at all. You do know the classic text on this, right? Reflexions on Trusting Trust, by Ken Thompson.

Do RepRap machines, as open as they are, suffer from Ken Thompson's Trusting Trust problem? I suppose once the integration is sophisticated enough to incorporate the controller software in the replication process that it could, for example, recognize any tumbler-style lock device being printed and surreptitiously modify the design during printing to include support for a special master key. Is there a lower-level analog to the compiler problem that involves only subtle changes to the hardware elements?

Strange Loops: Ken Thompson and the Self-referencing C Compiler
Reflections on Trusting Trust - Ken Thompson

Wish I had points because I found these links really interesting. Thanks.

Strange Loops: Ken Thompson and the Self-referencing C Compiler Reflections on Trusting Trust - Ken Thompson

Those are old and outdated papers from before diverse double compilation techniques were described. Source code is the fundamental requiement for both auditing and efficient discovery of exploits. This is the reason why the Chinese government insists on and gets access to Microsoft Windows source.

Sorry for the broken link. Here is the correct link. It should be required reading for anyone involved in computer security.

Strange Loops: Ken Thompson and the Self-referencing C Compiler
Reflections on Trusting Trust - Ken Thompson

This is only true if you're compiler hasn't been compromised, or the that compiled it, or the one that compiled that one, and on and on.

The reality is that no matter how clever you are, how long you spend reading the source code for your favorite operating system, or how well you understand the results of that reading, you have to trust someone some time.

Even aside from that, the number of people who truly understand the source and design of any given OS completely could probably be counted without resorting to toes. A Debian maintainer neutered their SSL library for years getting rid of a compiler warning. The days of Mel's are long gone and when you get into the deep magic, most folks, myself included, are way out of our depth.

Open Source has a lot of advantages to it, but the idea that someone is going to stick something in a proprietary OS which is simple enough for even most programmers to actually catch without it getting detected is pretty close to nil. Many eyes only helps if the back door is simple enough for the many to recognize.

At its core, C is designed to be a sort of portable assembly language.

No, it was designed as a replacement for assembly language. There's a difference.

Most of its original features were intended to map directly to PDP-11 opcodes

This is a myth. Most of C's original features are inherited or evolved from its predecessor languages.

http://cm.bell-labs.com/who/dmr/chist.html

Unfortunately, it hasn't really kept up with the improvements in modern instruction sets.

C has never had any direct support for the instructions of any particular machine architecture. In this, of course, it is in good company with virtually every other non assembly language because, not being assembler, you wouldn't expect it to have direct support for any particular machine instruction.

There really ought to be SIMD data types and functions built in to the language

How would you do that in a portable way?

It astounds me that Linkedin and eHarmony used unsalted password hashes. That's much worse than using md5 (and, yes, you shouldn't use md5, but, still, first things first).

From the Linkedin Press Release :

The passwords are stored as unsalted SHA-1 hashes,

Come on, guys, get up to at least 1978 in your security policy.

This is why the episode of BSG where they didn't want to network the systems together because of the Cylons hacking in remotely is so laughable

It's a little less laughable when you consider that the Cylons owned most of the electronics manufacturing business on the twelve colonies.

(it would take a single firewall rule in that case... deny all incoming traffic)

That's a nice thought, but it doesn't help when your firewall switches to "allow all" once it sees the right magic packet. Which is exactly what happened in the pilot episode.

there's consumer grade encryption available that far exceeds the capability of the most advanced military computers to crack within a practical amount of time

There sure is. But all it takes is one little "mistake" to turn it from unbreakable into child's play.

Imagine a world where one company in, say, China makes more than half of the world's consumer electronics, including parts used for high security applications. In such a world it would be easy to see why people lie awake at night dreaming of Ken Thompson style hacks.

BCC was present in RFC680, from 1975. The Unix V6 mail program didn't explicitly have mail folders, but from what I can tell of the man page for the Unix V6 mail command ( http://man.cat-v.org/unix-6th/1/mail ), the notion that mail could stored somewhere other than the .mail file in the home directory did exist in 1975. The Unix V7 mail command (you can find its man page at http://plan9.bell-labs.com/7thEdMan/v7vol1.pdf on page 112) most certainly does support saving mail to multiple mailbox files (and what is an mbox file but a bloody folder, which is essentially what Thunderbird still uses with an additional index file). It's that basic multiple mbox structure that programs like Elm and Pine would ultimately build on top of. MH that appears to be from around 1979 also handles multiple mail folders.

So no, the guy didn't invent bcc or multiple mail folders either. He didn't invent the first GUI mail system, which was probably Xerox's Laurel.

The guy is a liar.

Merely looking at such code isn't sufficient to identify introduced faults. Doing a thorough audit, with something as simple as diff -u, on the other hand, catches the class of faults introduced in source.

Audits of source code will not catch Trojans in compilers, as described in Ken Thompson's Reflections on Trusting Trust, but if we diff the compiler binaries, the auditor will catch the change.

Therefor one can confirm a high degree of security if one invests a good chunk of work.

I won't speculate on the NSA, but back in the day when Sun still existed, we had this debate about Trusted Solaris, and the professional paranoids were horrified at the thought of leaving a backdoor that someone else could use. The amateur paranoids though it would be a fine idea (;-))

dave (a semi-professional paranoid, back in my Sun days) c-b

I get your point, but if you think that "open source" is any kind of guarantee of security, you are sadly mistaken. Do you trust that the binaries supplied are not tampered with? Have you, or someone you trust, personally audited the code?

And how about the toolchain? If you haven't read it yet, I highly recommend Reflections on Trusting Trust by Ken Thompson. Prepare to lie awake at night...

Can you really trust your pre-compiled compiler?

Reflections on Trusting Trust.

The thing I like about Open Source/Free Software, in the end, isn't so much that I have to, myself, inspect and compile every program. I trust the pre-compiled binaries because I know that if someone *does* try to sneak something in, someone else will find it, probably pretty quickly.

So, I guess what I'm saying is, I'm glad there's very technical and very paranoid people out there double checking everything so I don't have to.

System I, I think System II got the "versions", then they "jumped" to System III, although many people allready had sidejumped to Berkeley. But indeed it started with System, not versions, (but the "versions" made it popular :-))

Well, yeah, it started with "System", as in "The UNIX Time-sharing System". The document cited there is "Unix Programmer's Manual, First Edition", at least according to Dennis Ritchie's home page. I'm not sure Research UNIX had anything as formalized as "releases", as opposed to "what we have right now when we're making a UNIX tape", and I'm not sure that the "version numbers" applied to the operating system rather than to the manual.

There was no "System I" or "System II"; "System III" came from a line of UNIXes that combined Research stuff with the (based on something that looked like V6 with the "Phototypesetter, Version 6" enhancements and some other post-V6 stuff) first edition of PWB/UNIX and a bunch of other UNIXes inside AT&T.

System I, I think System II got the "versions", then they "jumped" to System III, although many people allready had sidejumped to Berkeley. But indeed it started with System, not versions, (but the "versions" made it popular :-))

Well, yeah, it started with "System", as in "The UNIX Time-sharing System". The document cited there is "Unix Programmer's Manual, First Edition", at least according to Dennis Ritchie's home page. I'm not sure Research UNIX had anything as formalized as "releases", as opposed to "what we have right now when we're making a UNIX tape", and I'm not sure that the "version numbers" applied to the operating system rather than to the manual.

There was no "System I" or "System II"; "System III" came from a line of UNIXes that combined Research stuff with the (based on something that looked like V6 with the "Phototypesetter, Version 6" enhancements and some other post-V6 stuff) first edition of PWB/UNIX and a bunch of other UNIXes inside AT&T.

Not to mention the compiler that was used to compile _your_ compiler - http://cm.bell-labs.com/who/ken/trust.html