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.
This article is either intentionally sensationalist or written by someone who just has no clue.
The research presented found flaws in popular interpreters for a few interpreted languages. This is little different than finding flaws in libraries and in fact, many of these flaws were in the libraries.
It is a very important distinction. Fixing a problem in a language usually takes negotiation and can be years. Fixing a problem in an interpreter often takes days.
People whose idiot managers read this and are panicking at this moment will now be having to explain to them this week why this doesn't mean that they need to rewrite all of their code into another language to fix their problems.
But the exploits require shell-level access to launch the interpreters. When you have shell access, it's not surprising that you can execute an arbitrary shell command.
Some heretics have been tempted away from the One True Faith in C/C++ binarchy. They will find the heretical languages they have aligned themselves are false Gods or tempters like the fallen angel, Satan. Their abode will be fiery and their torment long!
Here Endeth The Sermon.
The congregation will now rise and repeat Google's Style Guide For C++, omitting the parts that are now known to be heresy and falsehood sent by malicious trickster demons.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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. . . .
That is fair, that the JVM hasn't been exploited. That is partly because you have to get through the verifier first.
If you're using JNI, you are already on the other side of the airlock. Unless you can get malicious JNI loaded from the outside, a JNI attack is not a JVM flaw.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
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
I haven't looked at the other languages, but in the case of perl, it's not a flaw in the interpreter, its a flaw in a specialised library module (ExtUtils::Typemaps::Cmd) that is used to build other modules - i.e. that is run only when building and installing a third-party module. The installer for such a module will typically hard-code the module name they pass to ExtUtils::Typemaps::Cmd::embeddable_typemap(). If someone wanted to modify the installer to run a command rather than load a file, they could just directly write 'system "rm -rf /"' rather than the elaborate ExtUtils::Typemaps::Cmd::embeddable_typemap( 'system "rm -rf /"'). And if they could modify the install script, you've lost anyway.
Also, I can't find any in-the-wild use of that function.
Unskilled "engineers" pumped through bad schools to cobble together some barely functional shit to make money for venture capitalists and industrialists in a huge economic bubble made insecure apps.
Another factor is engineered vulnerabilities to assist mass surveillance.
Basically our entire society has become a bubble that is going to pop within 50 years.
My karma was manually wiped by site staff https://slashdot.org/~slshdtisctrldbysjws 18 mod up, 10 mod down = bad karma
Note for the dim bulbs: this comment is meant to be a joke. The original article was foolish, and suggesting Haskell shows how ridiculous it is in the first place.
Why is Snark Required?
> Humans have an uncanny ability to evade culpability in clever ways.
Well you seem to be saying that language designers / implementers have no culpability at all.
For your metaphor, what if the person building the house is using a rubber mallet, rusted nails and broken wood?
People can write bad programs in any programming languages, but some programming languages have flawed designs that make bad behaviour much more likely.
It's turtles all the way down.
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.
Also the case for the perl example, which I kid you not, posits that if you have access to the command line such that you can type in a perl one-liner, there's a perl library function for which one of the parameters can be tricked into shelling out to (you guessed it) ... the command line.
... which shells out the output of the 'id' command in the middle of the error message it returns.
... well, OK ... but that's another matter entirely.
The example cited is this:
perl -e "use ExtUtils::Typemaps::Cmd;print embeddable_typemap(\"system 'id'\")"
And yet the perl system function, by design, straightforwardly does the exact same thing, minus the above error messages and convoluted approach:
perl -e 'system "id";'
Finally, if you have access to the command line anyhow, you can, you know, simply input the 'id' command.
If the point here is that user input shouldn't be blindly passed to functions that might execute them, and, oh by the way, here's a fairly obscure example of a module function that does that, as a heads up
I'm pretty much only seeing facepalm material here.
These tests aren't about bugs in in-built functionalities used as expected, but about somehow unexpected behaviours when misusing them. Or, in other words, what is the likeliness of a poorly developed piece of software (an extreme scenario where you aren't even properly using well-documented resources aimed to ease your work) to have a valid appearance? As per my personal experience and despite not caring too much about the specific programming language, I have observed curious behaviours when mistyping some bits in some of the mentioned languages. Not getting a clear error when you do something wrong is certainly a bit bothering, but blaming that for a faulty output is going too far.
Any experienced enough programmer shouldn't find any problem to deal with virtually any language. Even in case of not having too much experience, you could avoid all this by paying more attention and/or reading the available documentation. Additionally and regardless of your experience, thoroughly debugging/testing all the code should be a relevant part of any development.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
It is possible to write memory safe code in C. There are three problems. The first is that it's quite hard. The second is that a single memory safety bug violates invariants that the entire program depends on and so can cause non-local problems. The third is that C is the lingua franca for library interfaces and so it's likely that your program is using C libraries with bugs that can completely destroy the program's security.
Now here's the kicker: Most of the languages listed are implemented in C. Not only in C, but often using some of the pointer manipulation tricks that make C both powerful and dangerous. On top of that, they're providing standard libraries that are mostly both written in C and using third-party libraries written in C. Even if your Ruby (for example) code is entirely bug free, you have so much C code in your address space that it's astonishing anything works at all.
I am TheRaven on Soylent News