Slashdot Mirror

← Back to Stories (view on slashdot.org)

Did Programming Language Flaws Create Insecure Apps? (bleepingcomputer.com)

Posted by EditorDavid on from the uh-oh dept.

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.

4 of 100 comments (clear)

  1. Interpreter flaws, not language flaws! by RhettLivingston · · Score: 4, Informative

    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.

    1. Re:Interpreter flaws, not language flaws! by Anonymous Coward · · Score: 1, Informative

      JavaScript is not secure, as language or as interpreter.

      There are tons of flaws in JavaScript as buffer overflows, arithmetic underflows-overflows, loss of accuracy, race conditions, NaN, undefined, exceptions raises, etc.

  2. Sure, these are flaws by Anonymous Coward · · Score: 4, Informative

    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.

  3. not a flaw in perl by Anonymous Coward · · Score: 3, Informative

    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.