Live data from Hacker News

CVE-2021-32471 – Input validation in Marvin Minsky 1967 Turing Machine

cve.mitre.org

11–20 of 43 posts

Re: CVE-2021-32471 – Input validation in Marvin Minsky 1967 Turing Machine

#11
post #10
post #9

Earlier quoted context omitted.

Haven't looked into this paper deeply, but this reads very strange to me: > This paper reports on the discovery of an accidental arbitrary code execution vulnerability in Marvin Minsky's 1967 implementation of the universal Turing machine. By submitting crafted data, the machine may be coerced into executing user-provided code. It's a universal Turing machine. Its whole purpose is running "user-provided code". That's…

Yes, that's the joke.

Wait until they try unicode, then the joke will be on them.

Re: CVE-2021-32471 – Input validation in Marvin Minsky 1967 Turing Machine

#12
post #10
post #9

Earlier quoted context omitted.

Haven't looked into this paper deeply, but this reads very strange to me: > This paper reports on the discovery of an accidental arbitrary code execution vulnerability in Marvin Minsky's 1967 implementation of the universal Turing machine. By submitting crafted data, the machine may be coerced into executing user-provided code. It's a universal Turing machine. Its whole purpose is running "user-provided code". That's…

Yes, that's the joke.

I get that the CVE is a joke, but are you saying the paper is as well?

Re: CVE-2021-32471 – Input validation in Marvin Minsky 1967 Turing Machine

#13
post #9

A better link is the research paper: https://arxiv.org/abs/2105.02124 > The universal Turing machine is generally considered to be the simplest, most abstract model of a computer. This paper reports on the discovery of an accidental arbitrary code execution vulnerability in Marvin Minsky's 1967 implementation of the universal Turing machine. By submitting crafted data, the machine may be coerced into executing user-p…

Haven't looked into this paper deeply, but this reads very strange to me: > This paper reports on the discovery of an accidental arbitrary code execution vulnerability in Marvin Minsky's 1967 implementation of the universal Turing machine. By submitting crafted data, the machine may be coerced into executing user-provided code. It's a universal Turing machine. Its whole purpose is running "user-provided code". That's…

> This is a little bit like saying "we found a weakness in the Python interpreter whereby you can feed it specially crafted input that allows you to run arbitrary Python programs".

If my understanding is correct, it's more like, "we found a weakness in the Python interpreter whereby you can feed it a specially crafted input to a Python script that allows you override that script and forces the Python interpreter to do something else", which can be a reasonable point to make.

BTW, if we keep using the Python analogy, this scenario sounds like a Python script that loads its configuration data from a Pickle file on the hard drive. In Python, Pickle doesn't validate the input and it's capable of modifying the internal state of the program. What the authors say is that malicious data in the Pickle file leads to code execution due to deserialization of untrusted data. Depending on your perspective, just like Python says a malicious Pickle file is not in its threat model, you can argue that the Universal Turing Machine is never meant to be protected from malicious data on the tape, and this is not a exploit, but an interesting thought experiment nevertheless.

The paper says,

> The universal machine, U, will be given just the necessary materials: a description, on its tape, of T and of [the initial configuration on T's own, simulated tape] s_x; some working space; and the built-in capacity to interpret correctly the rules of operation as given in the description of T. Its behavior will be very simple. U will simulate the behavior of T one step at a time [...]

> [...] There is one obvious trust boundary in a universal Turing machine, U: the initial string on the tape of the simulated Turing machine, T. That string corresponds to the user-provided data of an ordinary computer program. Because the potential users may be unknown to the developers and administrators of the computer and its programs, it is common to view this data as untrusted. In our explorations of the universal Turing machine, we will make the same assumption. Therefore, if it were possible to execute arbitrary code without manipulating the program of T, but only by providing crafted data on T’s simulated tape, that would constitute a vulnerability.

Basically the authors' reasoning is:

1. An Universal Turing machine is an interpreter/simulation that is capable of executing code written for any Turing machine, provided by the user.

2. The user code takes an external input - the initial content on the tape.

3. It's possible to maliciously craft an input (the content on the tape) to the user code to hijack the simulation, without modifying the user code.

Re: CVE-2021-32471 – Input validation in Marvin Minsky 1967 Turing Machine

#14

Sure this CVE sounds like a joke but if you create a programming language that is non Turing complete it is much easier to secure than a Turing complete language. Making a language that have the expressive power of finite state machines could be an example.

We are doing this already.

- Configuration languages (JSON, YAML, XML) are pure combinatorial logic.

- Regular expressions are... mostly not actually regular, but you get the idea.

- Some templating languages are deliberately less powerful than Turing machines, e.g. ST4 is context-free.

- Prepared SQL statements are a similar idea on a different axis.

The real question is whether a non-TC language could be useful for general purpose programming. Such a language might come with very strong guarantees (termination, time complexity, even correctness or a limited form of correctness), but they might be extra-cumbersome for 'normal' workloads.

Re: CVE-2021-32471 – Input validation in Marvin Minsky 1967 Turing Machine

#15
post #9

A better link is the research paper: https://arxiv.org/abs/2105.02124 > The universal Turing machine is generally considered to be the simplest, most abstract model of a computer. This paper reports on the discovery of an accidental arbitrary code execution vulnerability in Marvin Minsky's 1967 implementation of the universal Turing machine. By submitting crafted data, the machine may be coerced into executing user-p…

Haven't looked into this paper deeply, but this reads very strange to me: > This paper reports on the discovery of an accidental arbitrary code execution vulnerability in Marvin Minsky's 1967 implementation of the universal Turing machine. By submitting crafted data, the machine may be coerced into executing user-provided code. It's a universal Turing machine. Its whole purpose is running "user-provided code". That's…

If you do read the paper, you see that the universal machine U expects both a description of the simulated machine T, and a description of the input to T. The exploit is that they can cause arbitrary code execution not by changing the former but the latter. They also suggest a fix to U that makes it robust against exploits in the description of T's input.

Re: CVE-2021-32471 – Input validation in Marvin Minsky 1967 Turing Machine

#16
But why to make CVE out of that ?

this paper, this CVE has nothing to do with ! USEFUL ! research,

paper is essentially saying that by using simplest machine possible

we prove it does not provide layers of security abstractions which were invented and deployed in last 40+ years to machines

so thats like getting CVE for turning off ASLR, AppARMOR SElinux etc in linux kernel.

this proof is so obvious that highschooler should have to know this.

If research alone does not get credited or recognized why we need to award CVE's to make it more credible ? WHICH IS NOT EITHER WAY

second thing

do we as industry want VANITY CVE's ?

do we really need CVEs stemming from such a absurd exmples as some old vacuum tube computer does not provide ASLR ? no sane person wants that

and what if someone gets credited with 2 CVE's for heartbleed, does such a person want to work in industry which awards CVE to person exploiting bugs in 80' APPLE drives, IN 2021? which i know of atlest 50 bugs in them. do i go and request CVE's for that ?

Re: CVE-2021-32471 – Input validation in Marvin Minsky 1967 Turing Machine

#17
post #12
post #10

Earlier quoted context omitted.

Yes, that's the joke.

I get that the CVE is a joke, but are you saying the paper is as well?

i dont know if he says exactly that by i do say exactly that

paper is essentially saying that by using simplest machine possible

we prove it does not provide layers of security abstractions which were invented and deployed in last 40+ years to computers

so thats like getting CVE for turning off ASLR, AppARMOR SElinux etc in linux kernel.

Re: CVE-2021-32471 – Input validation in Marvin Minsky 1967 Turing Machine

#18
post #12
post #10

Earlier quoted context omitted.

Yes, that's the joke.

I get that the CVE is a joke, but are you saying the paper is as well?

As far as I can tell, yes, it is.

Showing a universal Turing machine is a proof of the fact that when you write stuff like the smn theorem or anything that uses universal functions you aren't writing nonsense.

There is no "contract" between the universal machine and the hypothetical user. One could certainly ensure that, say, the input TM is properly formatted, or that "the runtime" will only use a certain set of cells, and so on. The difficulties and problems one would find in trying to do so are the same one would face when writing an operating system and a compiler.

Re: CVE-2021-32471 – Input validation in Marvin Minsky 1967 Turing Machine

#19
post #11
post #10

Earlier quoted context omitted.

Yes, that's the joke.

Wait until they try unicode, then the joke will be on them.

reddit is saying that macos is build on turing complete emojis !

we should investigate XD

Re: CVE-2021-32471 – Input validation in Marvin Minsky 1967 Turing Machine

#20
I think this should be considered a satire of what the "security industry" has become: finding any little thing that they can claim is exploitable, regardless of actual significance, and all the while using paranoia to slowly destroy general-purpose computing and user freedom.
Post reply on HN