Slashdot Mirror
Did Programming Language Flaws Create Insecure Apps? (bleepingcomputer.com)
Several popular interpreted programming languages are affected by severe vulnerabilities that expose apps built on these languages to attacks, according to research presented at the Black Hat Europe 2017 security conference. An anonymous reader writes:
The author of this research is IOActive Senior Security Consultant Fernando Arnaboldi, who says he used an automated software testing technique named fuzzing to identify vulnerabilities in the interpreters of five of today's most popular programming languages: JavaScript, Perl, PHP, Python, and Ruby.
Fuzzing involves providing invalid, unexpected, or random data as input to a software application. The researcher created his own fuzzing framework named XDiFF that broke down programming languages per each of its core functions and fuzzed each one for abnormalities. His work exposed severe flaws in all five languages, such as a hidden flaw in PHP constant names that can be abused to perform remote code execution, and undocumented Python methods that can be used for OS code execution. Arnaboldi argues that attackers can exploit these flaws even in the most secure applications built on top of these programming languages.
Fuzzing involves providing invalid, unexpected, or random data as input to a software application. The researcher created his own fuzzing framework named XDiFF that broke down programming languages per each of its core functions and fuzzed each one for abnormalities. His work exposed severe flaws in all five languages, such as a hidden flaw in PHP constant names that can be abused to perform remote code execution, and undocumented Python methods that can be used for OS code execution. Arnaboldi argues that attackers can exploit these flaws even in the most secure applications built on top of these programming languages.
It's almost like being Turing complete opens you up to being insecure.
Most of us are probably too young to remember the TECO editor, from the early 1960s, but ...
It has been observed that a TECO command sequence more closely resembles transmission line noise than readable text. One of the more entertaining games to play with TECO is to type your name in as a command line and try to guess what it does. Just about any possible typing error while talking with TECO will probably destroy your program, or even worse - introduce subtle and mysterious bugs in a once working subroutine.
Also, I assert that there are no language flaws in Perl, just obscure and/or advanced usages, some of which may be dangerous to you, others or the planet.
It must have been something you assimilated. . . .
Fuzzing is great, but he doesn't seem to understand what a language flaw is.
In the case of Python, he's found 2 methods in libraries that can call shell commands. Leaving aside that this would be a library issue rather than a language issue, there's no evidence that it's even that.
Python explicitly doesn't have sandboxing. Like most languages (including C, C++, etc), the documented behavior is that if you control the program and environment then you're fully allowed to import subprocess or os and run whatever you want. You don't need to find "hidden" ways to run a subprocess, you can directly "import subprocess" and run stuff.
This is doubly true because of the nature of the modules investigated. The first "flaw" is that mimetools has a deprecated "pipeto" method that lets you pipe to arbitrary commands. But mimetools is already well-known to expose os access in millions of ways (most obviously, it imports and exposes os, so if for some bizarre reason you want to avoid importing os yourself, you can simply run "mimetools.os.popen" directly); no competent programmer would expect otherwise.
The second "flaw" is that pydoc runs a pager program which lets you run an arbitrary command if you control the program environment. Of course, the documentation states explicitly that the specified pager program will be used. It's unclear what part of the behavior here he thinks even surprising. And, again, the pydoc module imports and exposes "os" in exactly the same way that mimetools does.
rage, rage against the dying of the light
If your OS doesn't require you to specify what I/O is allowed for a program when you run it, you're never going to have a secure system. We need capability based security, and will be spinning our wheels until we get it.