The Super Super Password that Will Get You In Anyway

In a shocking revelation, a super user has come up to you and said there is bad code in your C compiler that will let people do horrible things. They demand that you show them the source code now if you're foolish enough to comply. What happens next is a bit like going back to the diagrams from the 1950s, where the concept of a Trojan horse comes into play.

What Happens When You Show the Source Code?

If you're foolish enough to show them the source code and they see that it's clean, they might let you off with a warning. However, if they discover that there is bad code in your C compiler, their anger will not subside. They claim that they can squirt extra source code into every time you recompile the C compiler with itself, hiding it in a string of characters within the binary from a C compiler recompilation. This means that even after recompiling a new version of the C compiler, there is still a rogue version embedded within that will allow them to get back in.

The Rogue Code Will Propagate Itself

According to the super user, this rogue code will not only remain in the binary but also propagate itself into every program you compile with the compromised C compiler. This means that even if you create a new version of the C compiler from scratch, you'll still be using a version that has the bad code embedded within it. The cycle will continue indefinitely until someone finds and fixes the issue.

The T Diagram of Doom

When asked about how this works, the super user explains that at the base of your diagram is still a rogue version of the C compiler that you're using to compile yourself. This means that there's no hope but to use what the company or Ken has given you, as you haven't created a new one yet.

The Consequences Are dire

This situation has been described by Corey Doctorow as "a total effing bombshell." What it's saying is that if someone comes up to you and says they're going to punch you up unless you give them the source code to this compiler, you show them clean source code. However, even after recompiling and showing them clean source code, the compiled binary still allows you to get in as a super user because of the way the rogue code has been embedded.

The Source is Safe But the Binary is Not

The problem lies not with the source code itself but with the fact that it's embedded so deeply within the binary. This means that even if the user hasn't said they want the bad code, it will still be there, waiting to be triggered. The answer is that you're stuck with this Trojan horse, and all you can do is try to find someone who can help you deal with it.

The Issue Still Persists

Dr. Ken Thompson, the inventor of Unix, described this as a "Trojan" - a device masquerading as innocent but having hidden dangers. The issue persists because if you consider what kind of things could be propagated using techniques like this, the possibilities are endless. You could be a supplier of printer inks and start interrogating your printer to ensure it's running the right sort of ink.

The CD-ROM Burner Trap

Additionally, what happens if it's made by a company that's subverted the system software in Unix in such a way that it won't let you copy rogue CDs that haven't been made with its own facilities? This opens up a whole new can of worms, as the possibilities are limitless. The only solution is to stick to simple finite state automata and avoid monkeying around with extra ram or stack effects.

The Diagram Against Us

A diagram slightly downwards from here shows how this situation can play out. It's a stark reminder that even in the most secure systems, there is always the possibility of a Trojan horse waiting to be triggered.

"WEBVTTKind: captionsLanguage: enonce units got real traction from the mid 70s onwards i thought well it's only a matter of time they've got to give them the turing award and it happened i think in late 83 they were given the during award jointly i think that um the formal presentation which required a sort of little accompanying paper to go with it uh didn't happen until 1984 but it really was an amazing piece of work that went with it a lot of people couldn't understand why it was a bombshell but it really really is the acm award is given for outstanding achievements in any area of computer science so yes people like morris wilkes in the uk won it people like stephen planey and robin and so on who are all into regular expressions turing machines all that kind of stuff all this very worthy theoretical stuff has won the turing acm award a lot of us began to wonder though whether they might just be so impressed by unix as a down-to-earth achievement that dennis rich and ken thompson the the two authors of it might get jointly honoured we hoped because they deserved it it was an amazing achievement oh and by the way if any of you want to know what happened with unix and in what order i can only point you at my fellow computer file person brian kernighan he's written lots of books of course about c he co-authored with dennis but this one a history in a memoir i think is the one that i've dipped into most and certainly for preparing these recent videos because he basically all right isabel labs insiders a little bit of bias maybe but basically he gives an unvarnished view about what happened and in what order and why did uh berkeley have to happen after bell labs had set the ball rolling and all this and right on through to the breakup and eventually you just had to have something like linux it was the only way everybody was going to be able to progress so what did dennis and ken do and what did ken say in his acceptance speech which was so remarkable the title is reflections on trusting trust first of all half bridge full of thank yous to everybody who helped me i'm not currently involved late 84 in any more development work on the latest unix left that to others version seven has been out for almost five years now but what i want to do is to use this opportunity to get you all to think about something which has now come upon us you will be clear that dennis and i have developed c largely as a system implementation language and what's more to the point we have written the whole of the unix operating system in sea can you trust us not to have hidden something deadly inside of the sea that we are using all the time and most people say well this view you see that compilers were benign you know there were wonderful helpful things that enable you to get from a high level language down to a runnable binary in terms that you could more or less understand we've done lots of t diagrams to explain how this works you know c compiler available as a binary takes input statements puts out a certain output that's what a compiler is for it's to provide a binary or near binary object that's easier to produce than writing at assembler code level everybody understands that but um backing off from all of this a bit what ken asked although he doesn't make it quite as blatant as this but if you read and re-read and re-read and re-read this four-page article until you've understood it all and it does your head in the question you end up asking yourself is have we opened a pandora's box here because what ken is saying is something like this what happens if your compiler has been engineered to be one of the bad guys and you think oh my lord if the operating system is written in c and c is commonplace when people understand see and now it'll work with it it becomes a very powerful weapon for mucking with the operating system if you're a good enough c programmer so basically ken says yes consider the following i may or may not have done the following i think he actually has or did how would you feel if i make my compiler ask of the c programmer that's flowing through it i keep an eye on it and i say is this person just messing about compiling up hello world so you can amaze everybody with your first binary program it says hello world or is it something more serious is this person trying to recompile the whole kernel of the operating system because maybe as a bad compiler i ought to say i've got a view about this so the first trick he says is how do you know i'm not watching the code go by and when i say to myself he's recompiling me the operating system i intervene and put in some extra compiled source code which allows me to get into the system and log in as super user without knowing the super user password so i will put in an extra little bit that says are you a super user as an ordinary user okay go through the normal password mechanism otherwise when i say password if you give me what shall we say sean abracadabra if you say abracadabra i open up the entire system for you you can do absolutely everything how would you feel about that and then when he's got through that on part one of the paper saying how about a rogue operating system that we've propagated all over the world now hi ken thompson know the magic super super super password that will get me in anyway some angry person has come up and says there is bad code in your c compiler it will let people do horrible things and they say to you show me the source now if you're foolish you show them the source and they see the code and that's it but what happens and this for those of you who watched it is a bit like going back to t diagrams what happens if the thing effectively says i'm going to squirt some extra source for the rogue code into every time you recompile the c compiler with itself i won't put it in every program because people will detect it and will get mightily upset but i promise you i mean the the binary from a c compiler recompile is pretty big i will hide in there the rogue source code in a string of characters which if i trigger it and reactivate it will get compiled as part of a c compiler recompilation are you still with me and will always propagate itself into the programs and you might say well but but you'll come along with a version of the c compiler that's got that bad code and you will recompile it and i say yes but at the base of your t diagram is a still a rogue version of you that you are using to compile yourself because until your new one is created you've got no hope but to use what the company has given you or what ken has given you and ken is saying basically if you're happy with that am i a nice sort of person would i do this to you maybe i would there's very good reasons that this has been described by a gentleman called corey doctorow who describes it as a total effing bombshell what it's saying is that if somebody angrily comes up to you and isn't go census around them and say look i'm going to really punch you up and kill you unless you give me the source code to this compiler and show me it's clean so you show them clean source code and say go on recompile it and it compiles and it's fine but then when you run that compiled recompile of the binary it still allows you to get in a super user but you knocked the piece of code out that enables you to go super easy you're not recompile that the answer is it's embedded so deeply because of versions of the compiler ensuring that as you bootstrap up you still propagate that code even if the user hasn't said it wants it if you see what i mean so it's deadly because it's embedded and hidden in the binary not in the source you can masquerade that the source is okay honestly this source corresponds to this binary it's a bit like trying to get rid of japanese not weed in your garden you know there's always enough spores in the ground from previous that they will reinfect you yeah and i suppose you might turn your hair out and say how can i cope with this and the answer is and i'm going to leave it to sean and the computer file organization tentacles everywhere to find somebody suitable to follow me and say this is still an issue and in fact i think ken invented the word trojan for this he said this thing is masquerading of oh i'm just a perfectly innocent c compiler but it isn't it's a trojan horse there's trapdoors in the underside of it that will let you do these awful things and enable you to because of its self-replicating capability will enable you to propagate for even more and he basically just says consider it's sobering so this was 1984 this came out this was 1984 truly orwellian truly orwellian the article we're pointing you by corey doctorow was published in 2020 all i'm saying is i am not part of the great unix security industry i know nothing i'm just telling you what ken did originally but what dr was saying is this is still a big big issue because if you consider what kind of things could you propagate using techniques like this if you were a bad company you could for example be a supplier of printer inks and start interrogating your printer and say are you running the right sort of ink or is it roguing because if so we're going to disable your print routines or alternatively got one of these newfangled cd-rom burners in your computer what happens if it's made by a company that's subverted the system software in unix in such a way that it won't let you copy rogue cds that haven't been made with its own facilities stuff like that the possibilities are limitless dana scott and michael rabin in the late 1950s it is always doable so long as you stick to simple finite state automata don't start monkeying around with extra ram or stack effect slotting that t diagram against here slightly downwards is to show youonce units got real traction from the mid 70s onwards i thought well it's only a matter of time they've got to give them the turing award and it happened i think in late 83 they were given the during award jointly i think that um the formal presentation which required a sort of little accompanying paper to go with it uh didn't happen until 1984 but it really was an amazing piece of work that went with it a lot of people couldn't understand why it was a bombshell but it really really is the acm award is given for outstanding achievements in any area of computer science so yes people like morris wilkes in the uk won it people like stephen planey and robin and so on who are all into regular expressions turing machines all that kind of stuff all this very worthy theoretical stuff has won the turing acm award a lot of us began to wonder though whether they might just be so impressed by unix as a down-to-earth achievement that dennis rich and ken thompson the the two authors of it might get jointly honoured we hoped because they deserved it it was an amazing achievement oh and by the way if any of you want to know what happened with unix and in what order i can only point you at my fellow computer file person brian kernighan he's written lots of books of course about c he co-authored with dennis but this one a history in a memoir i think is the one that i've dipped into most and certainly for preparing these recent videos because he basically all right isabel labs insiders a little bit of bias maybe but basically he gives an unvarnished view about what happened and in what order and why did uh berkeley have to happen after bell labs had set the ball rolling and all this and right on through to the breakup and eventually you just had to have something like linux it was the only way everybody was going to be able to progress so what did dennis and ken do and what did ken say in his acceptance speech which was so remarkable the title is reflections on trusting trust first of all half bridge full of thank yous to everybody who helped me i'm not currently involved late 84 in any more development work on the latest unix left that to others version seven has been out for almost five years now but what i want to do is to use this opportunity to get you all to think about something which has now come upon us you will be clear that dennis and i have developed c largely as a system implementation language and what's more to the point we have written the whole of the unix operating system in sea can you trust us not to have hidden something deadly inside of the sea that we are using all the time and most people say well this view you see that compilers were benign you know there were wonderful helpful things that enable you to get from a high level language down to a runnable binary in terms that you could more or less understand we've done lots of t diagrams to explain how this works you know c compiler available as a binary takes input statements puts out a certain output that's what a compiler is for it's to provide a binary or near binary object that's easier to produce than writing at assembler code level everybody understands that but um backing off from all of this a bit what ken asked although he doesn't make it quite as blatant as this but if you read and re-read and re-read and re-read this four-page article until you've understood it all and it does your head in the question you end up asking yourself is have we opened a pandora's box here because what ken is saying is something like this what happens if your compiler has been engineered to be one of the bad guys and you think oh my lord if the operating system is written in c and c is commonplace when people understand see and now it'll work with it it becomes a very powerful weapon for mucking with the operating system if you're a good enough c programmer so basically ken says yes consider the following i may or may not have done the following i think he actually has or did how would you feel if i make my compiler ask of the c programmer that's flowing through it i keep an eye on it and i say is this person just messing about compiling up hello world so you can amaze everybody with your first binary program it says hello world or is it something more serious is this person trying to recompile the whole kernel of the operating system because maybe as a bad compiler i ought to say i've got a view about this so the first trick he says is how do you know i'm not watching the code go by and when i say to myself he's recompiling me the operating system i intervene and put in some extra compiled source code which allows me to get into the system and log in as super user without knowing the super user password so i will put in an extra little bit that says are you a super user as an ordinary user okay go through the normal password mechanism otherwise when i say password if you give me what shall we say sean abracadabra if you say abracadabra i open up the entire system for you you can do absolutely everything how would you feel about that and then when he's got through that on part one of the paper saying how about a rogue operating system that we've propagated all over the world now hi ken thompson know the magic super super super password that will get me in anyway some angry person has come up and says there is bad code in your c compiler it will let people do horrible things and they say to you show me the source now if you're foolish you show them the source and they see the code and that's it but what happens and this for those of you who watched it is a bit like going back to t diagrams what happens if the thing effectively says i'm going to squirt some extra source for the rogue code into every time you recompile the c compiler with itself i won't put it in every program because people will detect it and will get mightily upset but i promise you i mean the the binary from a c compiler recompile is pretty big i will hide in there the rogue source code in a string of characters which if i trigger it and reactivate it will get compiled as part of a c compiler recompilation are you still with me and will always propagate itself into the programs and you might say well but but you'll come along with a version of the c compiler that's got that bad code and you will recompile it and i say yes but at the base of your t diagram is a still a rogue version of you that you are using to compile yourself because until your new one is created you've got no hope but to use what the company has given you or what ken has given you and ken is saying basically if you're happy with that am i a nice sort of person would i do this to you maybe i would there's very good reasons that this has been described by a gentleman called corey doctorow who describes it as a total effing bombshell what it's saying is that if somebody angrily comes up to you and isn't go census around them and say look i'm going to really punch you up and kill you unless you give me the source code to this compiler and show me it's clean so you show them clean source code and say go on recompile it and it compiles and it's fine but then when you run that compiled recompile of the binary it still allows you to get in a super user but you knocked the piece of code out that enables you to go super easy you're not recompile that the answer is it's embedded so deeply because of versions of the compiler ensuring that as you bootstrap up you still propagate that code even if the user hasn't said it wants it if you see what i mean so it's deadly because it's embedded and hidden in the binary not in the source you can masquerade that the source is okay honestly this source corresponds to this binary it's a bit like trying to get rid of japanese not weed in your garden you know there's always enough spores in the ground from previous that they will reinfect you yeah and i suppose you might turn your hair out and say how can i cope with this and the answer is and i'm going to leave it to sean and the computer file organization tentacles everywhere to find somebody suitable to follow me and say this is still an issue and in fact i think ken invented the word trojan for this he said this thing is masquerading of oh i'm just a perfectly innocent c compiler but it isn't it's a trojan horse there's trapdoors in the underside of it that will let you do these awful things and enable you to because of its self-replicating capability will enable you to propagate for even more and he basically just says consider it's sobering so this was 1984 this came out this was 1984 truly orwellian truly orwellian the article we're pointing you by corey doctorow was published in 2020 all i'm saying is i am not part of the great unix security industry i know nothing i'm just telling you what ken did originally but what dr was saying is this is still a big big issue because if you consider what kind of things could you propagate using techniques like this if you were a bad company you could for example be a supplier of printer inks and start interrogating your printer and say are you running the right sort of ink or is it roguing because if so we're going to disable your print routines or alternatively got one of these newfangled cd-rom burners in your computer what happens if it's made by a company that's subverted the system software in unix in such a way that it won't let you copy rogue cds that haven't been made with its own facilities stuff like that the possibilities are limitless dana scott and michael rabin in the late 1950s it is always doable so long as you stick to simple finite state automata don't start monkeying around with extra ram or stack effect slotting that t diagram against here slightly downwards is to show you\n"