I'd hoped this wasn't about the software.
Hacking with LaTeX
11–20 of 41 posts
Re: Hacking with LaTeX
#12> That's because Latex is turing complete and that means... The article is of course interesting, but it's really annoying to read claims that Turing completeness has anything to do with security. The danger comes from interaction with the external environment, not whether or not the language is Turing complete. If HTML had a "\write" equivalent, it would be just as dangerous. Conversely, the script, \newwrite\outfil…
> \newwrite\outfile > \openout\outfile=cmd.tex > \write\outfile{\imm\diate\wwrite\args} > \write\outfile{\inp\iput\cmd} > \closeout\outfile Though a longtime TeXer, I've never used the output facilities very much, so it's probably my fault; but I can't understand what this does (hence what it illustrates), and some things seem like typos. For example, shouldn't `\imm\diate`, `\wwrite`, and `\iput` be `\immediate`, `\…
It's from the article.
Re: Hacking with LaTeX
#13Earlier quoted context omitted.
Can you give an example of how the halting problem allows one to make it impossible/difficult to detect malicious code? I sort of get what you are saying, that Turing completeness makes analysis more difficult, but I still don't see what it has to do with security.
Well, if you can somehow inject arbitrary code, then you can inject an infinite loop. So a program will only halt on all inputs if you can not inject an infinite loop.
Sure.. so how is an infinite loop a security vulnerability?
Re: Hacking with LaTeX
#14Earlier quoted context omitted.
Well, take things that way: if your language is not Turing-complete, you could lock things down so that no crazy stuff happens, and prove that there is no way to bypass the security --assuming this problem is decidable, which can be the case if the language is not Turin-complete, but is hopeless otherwise. So it's a bit like saying "well, both are dogs so both can bite", when one is well-trained and leashed, and the…
Can you give an example of how the halting problem allows one to make it impossible/difficult to detect malicious code? I sort of get what you are saying, that Turing completeness makes analysis more difficult, but I still don't see what it has to do with security.
This is more from the perspective of the language designer, not from a "you get a binary, is it malware" one, in which case Turing-completeness basically has no importance. So for an example...
Many exploits use stackoverflows to get the execution of arbitrary code. You can prove that in some bounded languages such things cannot happen, regardless of the inputs the program gets.
Obviously you still rely on assumptions such as "the OS is not going to do random things with the memory", but that's outside of your power anyway.
Re: Hacking with LaTeX
#15Earlier quoted context omitted.
Well, if you can somehow inject arbitrary code, then you can inject an infinite loop. So a program will only halt on all inputs if you can not inject an infinite loop.
Sure.. so how is an infinite loop a security vulnerability?
If you are performing data processing on user-supplied inputs (as online compilers do), then an infinite loop can amount to a DoS attack.
Re: Hacking with LaTeX
#16Earlier quoted context omitted.
> \newwrite\outfile > \openout\outfile=cmd.tex > \write\outfile{\imm\diate\wwrite\args} > \write\outfile{\inp\iput\cmd} > \closeout\outfile Though a longtime TeXer, I've never used the output facilities very much, so it's probably my fault; but I can't understand what this does (hence what it illustrates), and some things seem like typos. For example, shouldn't `\imm\diate`, `\wwrite`, and `\iput` be `\immediate`, `\…
It's from the article.
Oops! I usually read comments first, to see if the article is worth it. Sorry about that.
Re: Hacking with LaTeX
#17> That's because Latex is turing complete and that means... The article is of course interesting, but it's really annoying to read claims that Turing completeness has anything to do with security. The danger comes from interaction with the external environment, not whether or not the language is Turing complete. If HTML had a "\write" equivalent, it would be just as dangerous. Conversely, the script, \newwrite\outfil…
> \newwrite\outfile > \openout\outfile=cmd.tex > \write\outfile{\imm\diate\wwrite\args} > \write\outfile{\inp\iput\cmd} > \closeout\outfile Though a longtime TeXer, I've never used the output facilities very much, so it's probably my fault; but I can't understand what this does (hence what it illustrates), and some things seem like typos. For example, shouldn't `\imm\diate`, `\wwrite`, and `\iput` be `\immediate`, `\…
The abbreviations are defined with the `\def` in the same code snippet. So that aren't typos, but a way to build latex commands like `\immediate` by breaking it up in multiple parts.
Re: Hacking with LaTeX
#18Earlier quoted context omitted.
Can you give an example of how the halting problem allows one to make it impossible/difficult to detect malicious code? I sort of get what you are saying, that Turing completeness makes analysis more difficult, but I still don't see what it has to do with security.
The halting problem makes it impossible to consistently answer the question "Will this instruction be executed ?" This is why you can't know if the code is malicious : you can't (always) infer meaningful properties about the code (Will it write something on the disk ?...).
> The halting problem makes it impossible to consistently answer the question "Will this instruction be executed ?"
In fact, Rice's theorem says that it's impossible more generally to answer any question about arbitrary code—so no work-arounds like "OK, I can't tell if a particular instruction is executed, but I can just test whether this program is 'safe'" (say, performs no I/O).
Re: Hacking with LaTeX
#19
Re: Hacking with LaTeX
#20Earlier quoted context omitted.
Well, if you can somehow inject arbitrary code, then you can inject an infinite loop. So a program will only halt on all inputs if you can not inject an infinite loop.
Sure.. so how is an infinite loop a security vulnerability?
The argument is the other way around, if a program halts on all inputs, then there is no possibility to inject arbitrary code. ( There may still be important security vulnerabilities, but there are some limits. Consider a debugger that executes the first 10 000 operations of a program, it would halt, but 10 000 operations is a lot of space to do something malicious.)