Skip to main content

Surprisingly Turing-Complete

A catalogue of software constructs, languages, or APIs which are unexpectedly Turing-complete; implications for security and reliability.

‘Computers’, in the sense of being Turing-complete, are extremely common. Almost any system of sufficient complexity—unless carefully engineered otherwise—may be found to ‘accidentally’ support Turing-complete somewhere inside it through ⁠‘weird machines’ which can be rebuilt out of the original system’s parts, even systems which would appear to have not the slightest thing to do with computation. Software systems are especially susceptible to this, which often leads to serious security problems as the Turing-complete components can be used to run attacks on the rest of the system.

I provide a running catalogue of systems which have been, surprisingly, demonstrated to be Turing-complete. These examples may help unsee surface systems to see the weird machines and Turing-completeness lurking within.

Turing-completeness (TC) is (avoiding pedantically rigorous formal definitions) the property of a system being able to, under some simple representation of input & output, compute any program of interest, including another computer in some form.

TC, besides being foundational to computer science and understanding many key issues like “why a perfect antivirus program is impossible”, is also weirdly common: one might think that such universality as a system being smart enough to be able to run any program might be difficult or hard to achieve, but it turns out to be the opposite—it is difficult to write a useful system which does not immediately tip over into TC. “Surprising” examples of this behavior remind us that TC lurks everywhere, and security is extremely difficult.

I like demonstrations of TC lurking in surprising places because they are often a display of considerable ingenuity, and feel like they are making a profound philosophical point about the nature of computation: computation is not something esoteric which can exist only in programming languages or computers carefully set up, but is something so universal to any reasonably complex system that TC will almost inevitably pop up unless actively prevented.

Accidentally Turing-Complete

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Greenspun’s Tenth Law

Comic caption: ‘This site requires Sun Java 6.0.0.1 (32-bit) or higher. You have Macromedia Java 7.3.8.1¾ (48-bit). Click here [link to java.com main page] to download an installer which will run fine but not really change anything.‘; description: this is a humorous parody of OSI-style technical diagrams describing a contemporary software ‘stack’, which consists of many layers of buggy obsolete software programs/libraries dependent on the one below going from obsolete to fanciful to possible-yet-horrifying like ‘a giant CPU someone built in Minecraft’. It depicts the inefficiency, opacity, redundancy, and historical accretion of legacy software that describes real-world systems all too well.

⁠XKCD #1636, “XKCD Stack”

They are probably best considered as a subset of “discovered” or “found” esoteric programming languages (esolangs), excluding the designed ones.

So FRACTRAN, as minimalist as it is, does not count, because John Conway designed it that way to prove a point about the Collatz conjecture; nor would a nightmarishly-obfuscated language like Malbolge⁠1⁠ count; but neither would John Conway’s Game of Life count, because it was chosen out of a large set of possible rules because it looked like its behavior was complex enough to yield many interesting aspects like being TC.⁠⁠2⁠

I also rule out tools or games: I personally rarely find them surprising. (Once you have seen one encoding of logic gates into a platformer video game which has door switches, or one encoding of string rewrites into a text editor’s regexps, then you have seen them all—although have you seen ⁠minimax-search chess AI in regexps…?)

Tools, such as configuration formats or domain-specific languages or text editors, almost always turn out to violate the Rule of least power & become ⁠“accidentally Turing-complete”. A tool as complicated as ⁠Sendmail⁠3⁠, ⁠MediaWiki templates, tmux configs, ⁠sed or repeated regexp/find-replace commands in a text editor will usually turn out to be TC.⁠⁠4⁠ Standard formats often support obscure features which are computationally powerful: we are not surprised that a sound library emulating a NES video game console in order to support an obscure music format will turn out to be Turing-complete—but by the NES part. Some formats, like PDF, are simply appalling.⁠⁠5⁠. Similarly, given the complexity of packet-switching Ethernet networks & routers, which implement multiple rules & rewrites, it’s not necessarily too surprising if one can build a cellular automaton ⁠into them or encode ⁠logical circuits; likewise, airplane ticket planning/validation is not just ⁠NP-hard or EXPSPACE-hard, but undecidable.

This is because any feature involving string substitution or templating or compile-time computation may support a lambda calculus or a term-rewriting language or tag system⁠⁠6⁠

Games are unsurprising because many games support scripting (ie. TC-ness) to make their development easier and enable fan modifications. An actual scripting language or VM is so blatant as to be boring when (not if) someone finds a vulnerability or escape from the sandbox. Games being TC may be as simple as including syntax for calling out to a better-known language like ⁠Perl. It can be impressive to go through the work of constructing a Turing machine inside those games, but as soon as you know what a cellular automaton is or that clockwork can implement a logic gate⁠⁠7⁠, then you won’t be surprised if Dwarf Fortress has at least four different ways to encode Turing machines.⁠⁠8⁠

Finally, I will also rule out various kinds of analogue & mechanical computers. If you know your technology history, you won’t be surprised by a Lego or dominos⁠9⁠ Turing machine—since we already know that mechanical computers work.⁠⁠10⁠

Stalking The Wily VM

Many cases of discovering TC seem to consist of simply noticing that a primitive in a system is a little too powerful/flexible. For example, if Boolean logic can be implemented, that’s a sign that more may be possible and turn Boolean circuits into full-blown circuit logic for a TM. Substitutions, definitions/abbreviations, regular expressions (especially with any extensions or custom features), or any other kind of ‘search and replace’ functionality is another red flag (eg. Notepad++ Turing machines), as they suggest that a cellular automaton or tag system is lurking. This applies to anything which can change state based on ‘neighbors’, like a spreadsheet cell or a pixel. Any sort of scripting interface or API, even if locked down, may not be locked down quite enough. (⁠“Weird machines” are a fertile ground of “that’s TC?” reactions.) Operations which take variable lengths of times or whose completion can’t easily be predicted from the start are another source of primitives, as that non-constant operation implies they may ‘depend’ on the data they are operating over in some way, implementing different operations on different data and having some sort of internal control flow, which may mean that they can be made equivalent to Boolean conditionals based on a careful encoding of data.

Surprisingly Turing-Complete

What is “surprising” may differ from person to person. Here is a list of accidentally-Turing-complete systems that I found surprising:

Possibly accidentally or surprisingly Turing-complete systems:

  • ⁠find + mkdir are Turing-complete (within a large but prespecified width limit), by Rule 110 when using find’s ability to run mkdir conditionally (-execdir) on directories matching a regexp (-regex)

  • CSS without mouse clicks? Perhaps some sort of Wang tile using reflections and conditionals?

  • Unicode? ⁠Nicolas Seriot suggests that ⁠Unicode’s bidirectional algorithms (intended for displaying scripts like Arabic or Hebrew which go right-to-left rather than left-to-right like English) may be complex enough to support a tag system via ⁠case folding rules (eg. Turkish).

    • Fonts themselves? Aside from looking pretty and being required by many writing systems, Heavy use of ligatures enable ‘handwriting’ fonts, with realistic features like alternating between many possible versions of a letter to avoid a mechanical regularity or ⁠‘running out of ink’. However, this generality & context-sensitivity means that font rendering systems must support glyph substitution rules which are ⁠suspiciously close to tag systems and allow for tricks like ⁠solving Fizz Buzz or ⁠rendering sparklines, although some implementations may not allow recursion and others have hardcoded depth limits.

      One semi-practical use is ZawDecode, a Burmese font which tries to partially solve the problem of Burmese having two text encodings in use, with no way to distinguish which encoding a string uses. For historical reasons, much Burmese is written in a fake Unicode called Zawgyi font which defines the meaning of each Unicode point totally differently from the official Unicode Burmese: so a string of text which is written in ‘Zawgyi’ will be a ‘valid’ UTF-8 Burmese string but nonsense when read as Burmese, and vice-versa. So ZawDecode abuses font ligatures to encode heuristics that guess, based on the gibberish, what a string is written in, so it can either render it according to Zawgyi or as regular Burmese. (The author claims “85%” accuracy in guessing Zawgyi but no details are available in English.)

      By far the most impressive use of ‘font programming’ is ⁠“Fontemon: World’s first video game in a font!” (a Choose-Your-Own-Adventure text game). But as technology advances, more becomes possible—ever wanted to watch ⁠“Bad Apple!!” in your ⁠font engine?

  • Human optical illusions? Changizi2008 presents ambiguous images in a circuit-like format, whose depth perception ‘flips’ based on the ‘input’ or top of the circuit, which are analogous to OR/AND/NOT/XOR computations; the existence of these ‘visual circuits’ hints at the possibility of ‘TC-complete’ images (although many pieces, like a working memory, are missing)

  • Adaptive immune system: almost certainly Turing-complete given its ability to learn, store memories, and modulate responses (all aspects which surprise people who think of just the innate immune system & destroying invaders), but not yet formally proven anywhere I’ve found. (Perhaps via stochastic Petri nets?)

  • Newtonian orbital mechanics: there are many mechanical computers which use gravity & collisions (eg. billiard-ball computers); are there computers which use only gravity without collision—could a solar system be a computer?

    The difficulty of the n-body problem and the many fascinating possibilities like n-body choreographies, suggest that Newtonian mechanics is Turing-complete… but ⁠the problem is still open.

    Whichever way it resolves, I expect people to be surprised.

Security Implications

…And so we go on dealing with the fortress, Abbé Faria sounding out the weak points of the wall and coming up against new obstacles, I reflecting on his unsuccessful attempts in order to conjecture new outlines of walls to add to the plan of my fortress-conjecture.

If I succeed in mentally constructing a fortress from which it is impossible to escape, this conceived fortress either will be the same as the real one—and in this case it is certain we shall never escape from here, but at least we will achieve the serenity of one who knows he is here because he could be nowhere else—or it will be a fortress from which escape is even more impossible than from here—and this, then, is a sign that here an opportunity of escape exists: we have only to identify the point where the imagined fortress does not coincide with the real one and then find it.

⁠“The Count of Monte Cristo”, Italo Calvino

It turns out that given even a little control over input into something which transforms input to output, one can typically leverage that control into full-blown TC. This matters because, if one is clever, it provides an escape hatch from a system which is small, predictable, controllable, and secure, to one which could do anything. (And will once an attacker has something to say about it.) It’s hard enough to make a program do what it’s supposed to do without giving anyone in the world the ability to insert another program into your program. Many security flaws would be unexploitable, or difficult to exploit, if one could only attack them blindly or at random; but inserting a program can let an attacker run computations to figure out what to do, and succeed each time. Even if there is no way to outright ‘escape’ the sandbox, such hidden programs can be dangerous, by extracting information about the surrounding program (eg. JS embedded in a web page which can extract your passwords by using Row hammer to attack your hardware directly, even if it can’t actually escape your web browser), or can take the host into strange & uncharted (and thus, untested) territories, enabling other attacks.

That we find these demonstrations surprising is itself a demonstration of our lack of imagination and understanding of computers, computer security, and AI. We pretend that we are running programs on these simple abstract machines which do what we intuitively expect, but they run on computers which are bizarre, and our programs themselves turn out to be computers which are even more bizarre. Secure systems have to be built by construction; once the genie has been let out of the lamp, it’s difficult to patch the lamp.

An active area of research is into languages & systems carefully designed and proven to not be TC (eg. total functional programming). Why this effort to make a language in which many programs can’t be written? Because TC is intimately tied to Gödel’s incompleteness theorems & Rice’s theorem, allowing TC means that one is forfeiting all sorts of provability properties: in a non-TC language, one may be able to easily prove all sorts of useful things to know; for example, that programs terminate, that they are type-safe or not, that they can be easily converted into a logical theorem, that they consume a bounded amount of resources, that one implementation of a protocol is correct or equivalent to another implementation, that there are a lack of side-effects and a program can be transformed into a logically-equivalent but faster version (particularly important for declarative languages like SQL where the query optimizer being able to transform queries is key to acceptable performance, but of course one can do a surprising amount in SQL like 3D raytracing, ⁠Tetris, gradient descent for fitting machine learning models and ⁠some SQL extensions make it TC anyway by allowing either a cyclic tag system to be encoded, the model DSL, or to call out to PL/SQL) etc.

Languages or systems which unintentionally cross over the line into being TC can be amusing or useful (although usually not), but they also have some serious implications: such systems, because they were never expected to be programmable, can be harmful, or extremely insecure & a cracker’s delight, as exemplified by the ⁠“language-theoretic security” paradigm, based on exploiting “weird machines”; some of the literature:

Most recently, Spectre & generalizations (Mcilroyet al2019) can be interpreted as providing a whole ‘shadow computer’ in the CPU via speculative execution which can be programmed to do things like ⁠run malware without visibly executing any of the malware instructions while having side-effects in the real computer. Spectre is interesting in being a class of vulnerabilities which have existed for decades in CPU architectures that were closely scrutinized for security problems, but just sort of fell into a collective human blind spot. Nobody thought of controllable speculative execution as being a ‘computer’ which could be ‘programmed’. Once someone noticed, because it was a powerful computer and of course TC, it could be used in many ways to attack stuff.

“Too powerful” languages can also manifest as nasty DoS attacks; the fuzz tester afl found that it could create an infinite loop in OpenBSD’s roff document formatting tool (first version, 43 years prior) by abusing some of the string substitution rules.

See Also

Appendix

How Many Computers Are In Your Computer?

Moved to “How Many Computers Are In Your Computer?”.

On Seeing Through and Unseeing

Moved to “On Seeing Through and Unseeing: The Hacker Mindset”.


  1.  

    It took several years before anyone figured out how to write a trivial program in Malbolge. Malbolge was eventually ‘solved’ (in terms of writing programs in it) when, 22 years later, someone finally pulled off an interpreter for a more friendly language in 2020.

  2.  

    Questions about whether GoL was TC appeared almost immediately upon publication, and that was proven not too long afterwards. Now you can, say, program Tetris in it or, of course, Life itself.

  3.  

    The baroque complexity of Sendmail possibly contributed to its infamous reputation for insecurity—it was one of the exploit vectors of the Morris worm, and for years shipped with a remote root backdoor (password: WIZ).

  4.  

    Virtual machines are everywhere! Most people these days are probably unaware that TrueType & many fonts are PostScript programs based on stack machines, similar to ⁠DWARF debugging and ELF metadata, or that some music formats go beyond MIDI in providing scripting capabilities and must be interpreted to be displayed; once one knows this, then fonts being TC are no more surprising than TeX documents being TC.

    While a powerful software design pattern, that power leads to many severe & fascinating font or media security vulnerabilities such as ⁠the BLEND vulnerability or ⁠SNES & ⁠NES code exploiting Linux systems, or the ⁠Operation Triangulation exploit which chained an undocumented TrueType opcode with 3 kernel/browser exploits & an also-undocumented hardware feature.

  5.  

    The full PDF specification is notoriously bloated. For example, in a PDF viewer which supports enough of the PDF spec, like the Google Chrome browser, ⁠one can play Breakout or ⁠Doom (because PDF includes its own weird subset of JavaScript leading to ⁠XSS). The Adobe PDF viewer includes functionality as far afield as 3D CAD support.

  6.  

    eg. esolangs likes ⁠“/// ” or ⁠Thue, XSLT, Ant, C++ templates & Java generics, RNA/DNA computing etc.

  7.  

    Game examples: Dwarf Fortress, ⁠Infinite Minesweeper, ⁠StarCraft, Minecraft ⁠in Minecraft, ⁠Transport ⁠Tycoon & ⁠Cities: Skyline.

  8.  

    ⁠Dwarf ⁠Fortress: Dwarf Fortress provides clockwork mechanisms, so TC is unsurprising; but the water is implemented as a simple cellular automation, so there might be more ways of getting TC in DF!

    The DF wiki currently lists ⁠4 potential ways of creating logic gates: the fluids, the clockwork mechanisms, mine-carts, and (most unusually) ⁠creature/animal logic gates involving doors+pressure-sensors.

  9.  

    See Think Math’s ⁠domino logic gates & ⁠2014 demonstration of a 4-bit adder implemented using domino logic.

  10.  

    There are edge-cases. It may be surprising that the Z3 electromechanical computer is Turing-complete given that it could only “execute fixed sequences of of floating-point arithmetical operations (addition, subtraction, multiplication, division, and square roots)”—but with all those operations, the camel’s nose is in the tent.

  11.  

    Worth mentioning in the context of Wang tiles is the Abstract Tile Assembly Model (aTAM) (cf. Brun2008), ⁠DNA Wang tiles, and the ⁠‘infinite Tetris’ TC construction with programming language & animations (uses an infinite board + ‘hard drop’ feature).

  12.  

    Did you know GNOME Calculator has HTTPS support—to fetch currency exchange rate information from the ECB & IMF?

  13.  

    Earlier versions required players to take all possible actions, but the 2019 paper claims to remove this assumption and force all actions, rendering the construction fully mechanical.

Similar Links

⁠[Similar links by topic]