Did Programming Language Flaws Create Insecure Apps? (bleepingcomputer.com) 100
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.
Re: (Score:2)
I'll up for some fishing:
The Pascal way can be hard to interpret so C is clearly better.
But LISP need no semi-colons as it produces no semi-shit!
Re: (Score:3, Funny)
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.
Re: (Score:3)
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. N
Re: (Score:2)
I'd say there's another distinct problem with safe memory management in C: it's nonlocal, and can't be verified in general, since telling if a memory block is freed or used after free can easily be changed into the Halting Problem. If you use C++ and smart pointers appropriately, you can generally set things up so that memory management is local, so that it's a lot easier to verify correctness.
Yes. (Score:2)
Interpreter flaws, not language flaws! (Score:5, 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.
Re: (Score:2)
Re: (Score:1)
You have been living under a rock for the last decades or so, right?
Some interpreted languages I know of compile the source into byte code internally and run it on a virtual machine. But does it really matter? The numbers you give, 10-50 times slower, where did you pull them from? I would really like to see benchmarking to validate those claims.
Also, speed can be more than execution speed. Sometimes development speed is important too. Go read: https://www.tcl.tk/doc/scripting.html
Re: (Score:2)
Sadly, if you put development speed as top priority, that implies quality is not top priority, or even bug fixing. It may be true that management values speed, but a professional craftsperson should always value quality over speed.
Re: Interpreter flaws, not language flaws! (Score:2)
He was talking about speed of development. Not speed of the program. And while speed of development is highly desirable. It is not a quality of the end product
Re: (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.
Re: (Score:2)
Re: (Score:3)
It's possible that JavaScript is the ideal solution to some problems, but it sure isn't the ideal solution to all problems. Or even most. Perhaps not many.
FWIW, I looked into using it and I would have needed to write a custom library in another language to even make it possible...a much better choice was to just use a different language. Not, admittedly, the one I would have used if I were writing a JavaScript custom library.
The language that's best depends substantially on the problem you're trying to a
Re: (Score:2)
So ideally, you want a Javascript to C++ compiler and you'll have the best of both worlds.
Re: Interpreter flaws, not language flaws! (Score:1)
Re: Interpreter flaws, not language flaws! (Score:1)
As others mention JIT mutes that argument. In most cases JIT code with garbage collection is substantially faster as itâ(TM)s far better suited to the processor it is running on. Itâ(TM)s just like compiling with the exception that the code is optimized for the local CPUâ(TM)s pipeline.
In async programming patterns where there can be inter-thread communication across cores, JITed code is almost guaranteed to be faster especially if âoelocksâ on objects are native to the language as
Re: (Score:2)
Re: (Score:2)
There are people who seem to don't mind slowdowns. Even higher level workers. I've run across one who was proud that the tool he used to auto-generate code "only" had a 100% overhead.
Re: (Score:2)
If you're using an interpreted language, you've already made the decision that you don't really give the slightest shit about speed. Interpreted languages as a rule run 10-50x slower than compiled and also require a runtime be installed. Nobody who is doing any serious programming cares about this.
Most code written today doesn't need to be 10-50x faster, so interpreted code is perfectly acceptable. For those few routines that need to be blazingly fast, feel free to optimize them in whatever fashion is appropriate -- whether that's writing them as libraries in real languages or even implementing them in hardware.
It's all a matter of economics. I can hire as many developers as I want at $30 to $50/hr that can code in the interpreted languages and then hire only one or two experts at $100 to $150/hr t
What about the benefits? (Score:1)
Letâ(TM)s assume for example that the languages themselves arenâ(TM)t perfect. Developers working in these languages (I am not) will write code using the standard libraries for these languages. So unlike C and C++ where developers tend to constantly rewrite the standard libraries (see Qt, glib, etc...) as well as compile non-library related problems into their code making it have to be recompiled in order to correct flaws, when security flaws are found in code written in these languages, updating
Re: (Score:1)
Wake up and realize that â(TM)I.T. doesnt just work.â(TM)
Re: (Score:2)
To pick an obvious example, there has never to my knowledge been an exploitable bug in the JVM. Plenty in the standard library though.
Re: (Score:3)
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.
Re: (Score:2)
https://www.cvedetails.com/pro... [cvedetails.com]
Re: (Score:2)
How many of those were JVM exploits?
Please read what I said again, bearing in mind that this story is about interpreters. There have been PLENTY of standard library exploits, but I can't think of any JVM bugs that have been exploited. There might be a couple of obscure ones.
Re: (Score:2)
Sure, these are flaws (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.
Re: (Score:2)
I don't get this article. They're not even fuzzing the interpreters, but rather the STANDARD LIBRARIES. How is this remotely interesting? Passing unsanitized input to arbitrary standard library functions, what could go wrong?? *facepalm*
True (Score:2)
Pounding the hell out of functions with random (and thus lying) input is one of my best tricks.
How am I gonna save the Enterprise if everyone knows the secret?
Re: (Score:2)
Trump uses PHP.
Or Golf Script [golfscript.com] to keep his Code Golf [wikipedia.org] score to a minimum. Arf.
Turing complete (Score:3, Insightful)
You could say the same for C (Score:2)
Fuzz testing: Good thing he didn't test TECO (Score:5, Insightful)
Most of us are probably too young to remember the TECO [wikipedia.org] 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.
Re: (Score:1)
s/TECO/vim/ and it's essentially saying the same thing: try to guess what happens when you type your name as a command in vim
Re: (Score:2)
Delete to end of line, and replace with "vid". Easily fixable by undoing.
Re: (Score:2)
Just about any possible typing error while talking with TECO will probably destroy your program
I'm pretty sure that's mostly the case with contemporary programing environments as well. Point to a random spot, replace the character in that spot with a random one, and observe the glorious result. We don't have any self-repair yet.
Re: (Score:2)
Re: (Score:2)
I'm old enough to remember TECO, the world's most terrifying text editor. It never actually did anything terrible to me, but living one keystroke away from disaster eight or ten hours a day was stressful.
No (Score:1)
Programming languages don't write insecure applications, people do.
Next thing I suppose we'll arrive at is if someone builds a structurally insecure apparatus with a hammer, nails and wood, I suppose it will be the hammer's fault for being a bad tool and we'll need to consider not using hammers anymore?
Humans have an uncanny ability to evade culpability in clever ways.
Yes (Score:3)
> 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.
Re: (Score:1)
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?
No, you missed the point. If someone builds something that is unstable with a hammer and nails, is the manufacturer of the hammer and nails liable for it. NO. A thousand times NO. Take your nanny state and shove it up your liberal ass.
Re: (Score:2)
WTF?! Seriously, we're making metaphors of programming languages as tools and houses as programs.
You make the point that it's the builder's responsibility to make a good house. (I got your point, it's not a hard one to understand).
I make the point that it's worth using good tools, because some programming languages make it hard to write secure code. I could keep stretching the metaphor and say it's up to the builder to know what good tools are if that would make you happier.
Jumping to "Take your nanny state
So 'hello world' can be exploited? (Score:2)
So if I were to write a straight 'hello world' app in these languages, it could be exploited. Any proof?
Not actually language flaws... (Score:5, Insightful)
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.
Re:Not actually language flaws... (Score:4, Insightful)
I'd be kind of surprised if something called "pipeto" DIDN'T allow one to run arbitrary commands. But so do subprocess, os.system, os.popen, and probably 20 other Python library functions.
Re: (Score:2)
This "study"'s PHP "vulnerability" was that if you pass USER INPUT to a function called "shell_exec", that there's a security flaw there.
Well DUH!
not a flaw in perl (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.
Should have used Ada (Score:2)
No (Score:2)
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.
Obvious Answer (Score:4, Interesting)
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.
What a load ... (Score:2)
The examples given mostly have nothing to do with the languages having vulnerabilities at all (I only read the Python section as I'm most familiar).
For goodness sake, none of those were privilege escalation or remote access attack vectors. Yes, if you allow the user to specify their environment variables (like PAGER and EDITOR) they'll get executed *as that user* which is known behaviour.
Re: (Score:2)
The example cited is this:
perl -e "use ExtUtils::Typemaps::Cmd;print embeddable_typemap(\"system 'id'\")"
And yet
Yes they can & it's a "holy terror" to me... a (Score:1)
See subject: C shows you it in buffer overflows due to null-terminated string use & functions like sscanf (iirc this had big problems) having to be redone.
Neither is a problem in Pascal/Object Pascal (length is built-into strings).
Had a troll "bug me" today https://it.slashdot.org/comments.pl?sid=11461611&cid=55711831/ [slashdot.org] & it "hits on" this part & what did I do to AVOID program language issues (especially in stringwork which my program noted there HUGELY operates in)?
Something from a book I re
Not the language, but the OS (Score:4, Insightful)
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.
Comment removed (Score:3)
fearmongering (Score:1)
this looks a lot like someone just wants a paper they can refer to when they sell you their "NextGen Cyber Security Protection Package (tm)" for a couple grand a month. I mean, those "flaws" are certainly not language flaws, they aren't even interpreter flaws, and to me it looks like they aren't even flaws at all.
Python: libraries provide relatively unknown functions that allow to execute arbitrary code, don't feed them user input and you're fine
Perl: see python
php: if you feed user input to shell_exec wit
what flaw? (Score:2)
you're already running an arbitary php script on the machine. What does executing arbitrary machine code through the php interpreter gives you that you don't already have?
The ability to escape php's poor sandboxing features? Don't make me laugh.
Honestly looking in the wrong place... (Score:1)
The biggest flaws are in OSes and product strategies. Microsoft is the obvious poster-boy for this. Their product strategy of binary backwards compatibility is easily responsible for 99% of the exploits on Windows. And the pathetic part is that people did and have been predicting nearly every type of exploit that has hit Windows since 1995 simply base on architectural design issues caused by this product strategy. Windows has only recently become half-secure as it's abandoned that fundamental design f