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â(TM)s not like you ever saw a program coded in C not get hacked.
So did bad programming.
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.
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 the languages and their libraries often secure the programs as well.
Basically, the real issue isnâ(TM)t whether the languages are flawed. Weâ(TM)ve seen problems in code provided by libg++ in the past. The problem is whether the languages are patched through automatic updates in a timely fashion and whether the patches actually correct problems not just in the language but also in the code written against them.
That said, Iâ(TM)m working on C# code now which through reflection (advanced RTTI) will require every function to explicitly define permissions to platform wide resources making every function in the code âoedeny anyâ until the developers and operators explicitly permit what it has access to based on RBAC. I expect the first few versions of this code to cause more harm to security than it helps. Once it is hardened though, it should probably be the most secure coding system ever written which doesnâ(TM)t impede usability.
Yes, flaws in virtual machines or compilers can create security vulnerabilities.
No, you can't prevent *all* security vulnerabilities by fixing those flaws. The desire for this is very strong for obvious reasons, but it is impossible. If the language is powerful enough to be useful, it is powerful enough to be used wrong.
So long as we need software developers at all, we need them to have the means, motive, and opportunity to ensure that their code is secure. That will never be free.
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;
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?
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
Security analysis in computer science is a very hard task that is costly hard to implement a safe software & hardware.
Adding security's features does impose a hard penalization that consumes many available resources & time.
Zero risk does not exist.
Bugs & flaws are the enemy of the existence.
i realy like your BASIC-esque line formatting, and here I thought we would be tempted with another series of Fortran trolls fighting with Pascal trolls about how C got the semi-colon wright the first time and evetyone else better pay the Syntax like a knaive!
It's almost like being Turing complete opens you up to being insecure.
With "traditional" attacks such as buffer overflows. Newer languages abstract away having to do things like manually allocate string sizes to make buffer overflows less possible. That's why we continue to improve these languages and develop new ones and I expect this process to continue as newer attacks are developed against existing languages.
Trump uses PHP.
Or Golf Script to keep his Code Golf score to a minimum. Arf.
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. . . .
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.
We'll make great pets
Java can solve this by layering.
The java machine can run in a java machine, running on a java machine written in java.
Any exploit would have to be multiple layers deep. And with each machine taking longer and longer to boot, it would be like inception, where 1 hr of the users time is like 1 or 2 cycles of the machine.
...I do all of my web scripting in assembly language.
So if I were to write a straight 'hello world' app in these languages, it could be exploited. Any proof?
any non-trivial program (sorry meant app) will branch out in ways that are not fully testable. Try all you like you cannot make it 100% safe.
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.
Everything in the world has flaws, so it wouldn't be different with Operating Systems, Virtual Machines, communication protocols, languages and ourselves.
However the biggest problem seems to be the need to rush products just to try to get ahead in the market, to deliver something because some person that wasn't technical enough provided some absurd deadline date or because many developers today are lazy and don't code as they should (yeah GC's are to blame) to avoid problems. With it in mind and projects getting each time more complex, that means we rely each time more in rushed finished frameworks(projects), see the irony!
Imagine code that actually helped with security rather than opened a back door and trap door.
Domestic spying is now "Benign Information Gathering"
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
WTF is that post EVEN saying? And why can't he MANAGE his caps lock KEY?
I read and understood it perfectly. Is english your primary language?
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?
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.
- Michael T. Babcock (Yes, I blog)
> 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.
Programs don't kill, programmers do.
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/ & 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 read years ago was a BIG INFLUENCE in a way ("The Toyota Way" - that company experienced huge success using PROVEN tech, nothing fancy, for decades - so I decided to do the same w/ the program noted in that link & above + after it).
I chose as PROVEN of tech language-wise as I knew of for stringwork (even though I like C++ as much, even C to a lesser extent) since Delphi knocked the chocolate outta MSVC++ in VBPJ (competing trade rag) DOUBLING it in math & stringwork winning 4/6 tests given (Sept/Oct 1997 issue "Inside the VB5 Compiler").
I used that 23++ yr. proven language (actually much longer than that but as Delphi Object Pascal it is that, OWL predates that by far longer & so does its base language Pascal) & controls used in my program too (solid ones, no 'new hotness' 3rd party stuff that are proven decades long now since 1995 Delphi 1.0) & an IP stack that's been patched & proven since 1968++ w/ the hosts file that's been solid since it was introduced (1973 iirc).
Any methods I used are proven from my own coding for 25 or so years now, much of the as a pro, too. I didn't want to take chances & give anyone any "ammo" they can take "potshots" @ me with!
The "infamous they" say "don't take codework personally" well, NOT when it's MY NAME on the work!
APK
P.S.=> So far, so good foor 5++ yrs. publicly now (I had it long before that here privately) - but there's always a chance something will turn up in the language itself (but after that long of a solid track record, it's more doubtful than possible imo)... apk
We don't have any self-repair yet.
humans have doctors, but apparently you are some sort of bot
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.
Oh almighty C, hallowed be thy name..I shall have no other compiler than thou... Thou are my one true compiler! Amen!
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.
Software quality is directly related to a failure to do the needful and revert back with highest priority.
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
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 without proper sanitation you deserve to get hacked. same if your security depends on a constant being defined and you haven't ensured it's actually defined.
nodejs: who passess user input to require()? if you do that you deserve to get hacked.
jruby: so you're passing unsanitized user input to a function that loads the given file and executes it? well shit.
basically all those "flaws" are "function_that_executes_stuff(unsanitized_user_input);"
So yeah this dude "found" some ways you could write insecure code. he could have titles his paper "5 things you shouldn't do when developing a secure application". but claiming that even the most secure applications built with those languages can be compromised because of those things is just complete BS.
and besides, how is his technique fuzzing? not one of those "flaws" is triggered by weird input, which I thought fuzzing was for? this really looks like "oh let's take some bad practices, call them flaws and claim we discovered them with our Shiny New Framework, and don't forget the buzzwords"
sorry for the rant, but things like these just make me really pissed:/
That's where all flaws lay. No matter whether you are user, nerd or developer, or all of them.
What did you expect?
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.
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 flaw and technology debt has been swept away. Not perfect but much better. The problem: Microsoft should have bitten this bullet in 1995, not 2015!
What's the new "Epic Fail"? IoT obviously. Talk about unimaginative architectures and baked-in architectural security risks and flaws!! Gee, let's put an x86 or nearly as powerful ARM into a device to implement complex yet insecure protocols that have not even been proven and those same deivces requires low costs, has low margins and can't be monitored for break-ins without dozens of points of "man-in-the-middle" hacking plus somehow with all of this the network stacks and security won't have problems? It's so painfully obvious what will be happening soon with IoT: basically every malware and security failure that has ever hit Microsoft but worse because critical infrastructure will depend on it. At least infrastructure managed by people stupid enough to adopt these technologies.
None of these has much to do with programming language flaws (except to the extent that using the wrong language could contribute to security risks as a top-level strategy issue).
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.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes