Compsci boffin publishes proof-of-concept code for 54-year-old zero-day in Universal Turing Machine
- Reference: 1620724506
- News link: https://www.theregister.co.uk/2021/05/11/turing_machine_0day_no_patch_available/
- Source link:
In a paper published on academic repository ArXiv, Johnson cheerfully explained that his findings wouldn't be exploitable in a real-world scenario because it pertained specifically to the 1967 implementation
[1]PDF
of the simulated Universal Turing Machine (UTM) designed by [2]the late Marvin Minsky , who co-founded the academic discipline of artificial intelligence.Yet what the amusing little caper really brings to the world is a philosophical point: if one of the simplest concepts of a computer is vulnerable to user meddling, where in the design process should we start trying to implement security features?
[3]
[4]
[5]
"The universal Turing machine is generally considered to be the simplest, most abstract model of a computer," wrote Johnson [6]in his paper . Through exploiting the Minsky-spec UTM's lack of input validation, he was able to trick it into running a program he had put together.
The Minsky specification describes a tape-based machine that reads and executes very simple programs from a simulated tape. Instructions on the tape move the simulated tape reader head left or right across the "tape" itself, which is represented as a one-line alphanumeric string. While users can make inputs at the start of the tape, in the UTM model they're not supposed to alter the program that follows.
"Regardless of the historical aspect of it, the fact [is] that the most simple [computer] we can describe seems to have had this propensity for vulnerability," Johnson told The Register .
[7]
Security (if you could call it that) for UTM consists of a single digit that tells the machine "user input ends here, everything after this point is executable with the parameters you've just read."
Johnson's exploit was as simple as writing that "input ends here" character in the user input field and then writing his own program after it. The UTM executes that and skips past the intended program.
Parallels with modern vulnerabilities are obvious: scale it up a bit in complexity and this has all the hallmarks of a SQL injection vuln, for example – or any other unsanitised or unescaped user input field.
[8]
Johnson told The Register today: "In this case, as in many cases, the vulnerability is based on confusing the machine… in academia, we scientists like to start with the basic principle: demonstrate something for a small system, then maybe it's true for a larger system. It seems to me that for the very smallest system, there is this intrinsic vulnerability, this propensity to be vulnerable."
The compsci prof continued: "Obviously Marvin Minsky didn't have the intention to [create] either a secure or a vulnerable system. Nevertheless, what happened was [it] was vulnerable."
Philosophically, Johnson's vuln (which has been assigned as [9]CVE-2021-32471 ) raises deeper questions for hardware and firmware designers alike to think upon, he told us: "Some people say that security needs to be built in from the start; you can't add it later. But in this case, all the mitigations of this that I could think of, they need to be add-ons, you can't build it into this machine.
"And if this is the mother of all computers, then it seems to me that you cannot build security in from the start."
Professor Alan Woodward of the University of Surrey opined to El Reg : "It's an interesting and provocative thought as to whether or not there is some fundamental cause for the number of specific attacks we see. I don't think we need to panic that there is some fundamental flaw in modern computer architecture, more it's a reminder that complexity brings its own threats."
Looking specifically at Johnson's vuln, he commented: "Interestingly, it seems to point more to issues with interpretations/implementations of the Turing machine. It seems to support the adage that nothing is totally secure once it's actually implemented." ®
Get our [10]Tech Resources
[1] https://regmedia.co.uk/2021/05/10/mit_minsky_paper.pdf
[2] https://www.theregister.com/2016/01/26/marvin_minsky_obit/
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YJpVvDedkw1XzV-jiKYYowAAAEI&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YJpVvDedkw1XzV-jiKYYowAAAEI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YJpVvDedkw1XzV-jiKYYowAAAEI&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://arxiv.org/abs/2105.02124
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YJpVvDedkw1XzV-jiKYYowAAAEI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YJpVvDedkw1XzV-jiKYYowAAAEI&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[9] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32471
[10] https://whitepapers.theregister.com/
I don't think that is correct. You could just put the 'user input ends here' at the beginning of the user input and happily jump to your code. Perhaps if only the user input portion of the 'tape' was mutable, but no, that wouldn't work either as however the immutability was implemented could always be corrupted by your code. Buggered really.
"where in the design process should we start trying to implement security features?"
AT THE BEGINNING.
Re: "where in the design process should we start trying to implement security features?"
Hum, would that be before of after performance engineering which also needs to be designed in from the start. Oh, and extensibility and a whole host of other properties. Not to forget the documentation, leaving that to the end is a disaster. I guess we just have to do everything at the start of the design process except the implementation. As for testing, if we design it all ok, who needs that.
Down to the pub (where we will soon be able to not freeze our collective butts off) as all good design starts there.
The illusion of absolute security
There is no computer that can be completely secure. Perfect security is an illusion.
Software can be written defensive but it will not secure you against all possibilities. You are also using hardware, which can make mistakes. That cosmic ray just hit the wrong gate at the wrong time throwing the software into a different state, etc...
As shown, you cannot build security into the system from the start and expect it to be perfect. And when you add it in the process of creating other facets, like software, you still will be lacking or leaking somewhere at some stage. There will always be a compromise possible, maybe unlikely, but the chance is there.
Now then, we people tend to be very bad at evaluating risk and are subject to influences from all sides. The question whether a risk is acceptable is a question already answered. We all want perfection but none can perform perfection. So it seems, the machines are just as bad as we are. So, when are the machines replacing us all?
> But in this case, all the mitigations of this that I could think of, they need to be add-ons, you can't build it into this machine.
If the user input was fixed width ( either by spec, or determined by the first byte of the user input ), this would prevent this attack. It wouldn't be an add-on.