SoylentNews is people
SoylentNews
Submitted via IRC for SoyCow8317
Research presented this week at the Black Hat Europe 2017 security conference has revealed that several popular interpreted programming languages are affected by severe vulnerabilities that expose apps built on these languages to attacks.
The author of this research is IOActive Senior Security Consultant Fernando Arnaboldi. The expert 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.
[...] The researcher released XDiFF as an open source project on GitHub. A more detailed presentation of the testing procedure and all the vulnerabilities is available in Arnaboldi's research paper named "Exposing Hidden Exploitable Behaviors in Programming Languages Using Differential Fuzzing."
(Score: 2) by Arik on Tuesday December 12 2017, @03:57AM (21 children)
If laughter is the best medicine, who are the best doctors?
(Score: 2, Interesting) by Anonymous Coward on Tuesday December 12 2017, @04:51AM (20 children)
You can make secure applications in these languages if you scope the problem correctly. Control your inputs to something reasonable (ex: less than 500MB string or something), and sanitize the data before passing it around to creepy duck typing functions, avoid massive allocations etc. These languages are not secure sandboxes, and the same is true of C. These exploits aren't much different than C exploits.
Differential fuzzing is a neat approach here though, and the results are somewhat interesting.
(Score: 1, Funny) by Anonymous Coward on Tuesday December 12 2017, @04:57AM
What is this? Reason in my Soylent? Be gone, heathen!
(Score: 4, Informative) by Arik on Tuesday December 12 2017, @05:17AM (17 children)
No matter how perfect your script, the actual program here is still the interpreter, and if it's broken (and it is!) then nothing you do in your script can change that.
If laughter is the best medicine, who are the best doctors?
(Score: 3, Interesting) by The Mighty Buzzard on Tuesday December 12 2017, @11:46AM (11 children)
How it's specifically broken is very important. Quite a lot of these bugs would require you have write access to the source of the script to be run to cause any problems. Which impacts "secure apps" not at all if you trust your developers.
My rights don't end where your fear begins.
(Score: 3, Insightful) by Arik on Tuesday December 12 2017, @03:36PM (8 children)
I cannot agree.
"Trust your developers" and "secure apps" are mutually exclusive. Security is not created by a mind which trusts.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by The Mighty Buzzard on Tuesday December 12 2017, @04:24PM (7 children)
I didn't say blindly trust. I'd expect any code additions to anything but a single-coder project to be reviewed before being merged.
My rights don't end where your fear begins.
(Score: 2) by Arik on Tuesday December 12 2017, @04:53PM (6 children)
Didn't say you did. You said:
"a lot of these bugs would require you have write access to the source of the script to be run to cause any problems. "
And that's true enough in a literal sense, of course, but the 'tone' seems a bit dismissive. Oh, it would require write access, that means it's not really a problem, well no, if you want any chance of producing secure programs you need to jettison that thought, it won't do you any good.
"I'd expect any code additions to anything but a single-coder project to be reviewed before being merged."
1) Reviews are not magical. The more that needs to be reviewed the less intensive the attention. Not all reviewers are equal and even the best can miss things. And deceivers have plenty of tools in their bag as well.
2) Even if reviews *were* magical, there are still many possible ways to bypass them.
Many many highly intelligent humans have been working for many many years on making computers *do stuff.* A far smaller number focus on making them *not do stuff.* Security is about the latter, not the former. Security is swimming against the stream, a half-hearted effort is effectively a total failure.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by The Mighty Buzzard on Tuesday December 12 2017, @06:05PM (5 children)
And yet, that's the best you can do if you ever want to ship anything. A full on effort would require a minimum of a formal proof for every last line of code in your code base, the operating system if there is one, the compiler/interpreter you're using, and any third party libraries you use. Even then you're trusting the ability and integrity of the authority certifying the proof.
At the end of the day, people in the real world try to learn as much as they can, keep up to date on new developments, do the best they know how, and make sure someone with a similar approach is double checking them. "Perfect" isn't just the enemy of "good", it's also the enemy of "ever ready".
My rights don't end where your fear begins.
(Score: 2) by Arik on Tuesday December 12 2017, @07:16PM (4 children)
Yes, exactly, that is the commercial reality which has lead inexorably to our current swampland of widely distributed and fundamentally insecurable systems.
The question is, how to get from here to anywhere else?
"A full on effort would require a minimum of a formal proof for every last line of code in your code base, the operating system if there is one, the compiler/interpreter you're using, and any third party libraries you use."
That should be the goal of any system that aspires to be secure.
"Even then you're trusting the ability and integrity of the authority certifying the proof."
Yes, nothing is perfect, but open review is the best review, multiple reviewers help, and these are minimum conditions.
""Perfect" isn't just the enemy of "good", it's also the enemy of "ever ready"."
See, this is one thing we disagree on. Perfection alone does not condemn a project to never ready.
Perfection *plus* a constantly expanding feature-list? Well yes, that will never, ever be ready. Modular design is key. Bootloader, kernel, dæmones, shell, userspace; subdivided again and again. Not divided to make things more complicated! Divided to make things more simple. Once this is done and out of the way then you can concentrate on the specific problems your program needs to solve and ignore the rest. Until this is done you cannot - we cannot - take any of it for granted.
We create logical walls to make sure that unexpected things do not happen, and thereby ensure the expected, and desired, operation of each individual system as well as the system as a whole. And also so that it doesn't all have to be done at once, of course, or even ever. IF you had an actual mathematically proven system up to the point of the VM THEN you would actually be living in a reality where it might be sane to trust the VM enough to run arbitrary code in it a la ecma, java, flash, etc. When you go to build a three story house you don't start with a bunch of mud and driftwood for the first level and figure you'll make up for it by using steel and concrete up top.
But anyway this is not impossible in any physical or mathematical sense it just takes more time and care. As a species we've been programming electronic computers for nearly a hundred years now we've had plenty of time to build a secure base system from the ground up and have it reviewed and tested thoroughly, if *anyone* had seen an interest in putting a moderate amount of funding into it. Instead the closest thing we have is OBSD, built mostly by volunteers in their free time, and with virtually no traction because of being systematically excluded from hardware. And speaking of hardware, ALL of this presumes old-school hardware. "Management Engine" and insecure microcode implementations are fundamental problems.
Clearly there are other forces at work against perfection than merely it's own intrinsic difficulty. Again, take note, it's not that many people are aiming for it and fail. It is that an entire generation has been conditioned to believe it's impossible! Hence virtually no one even tries or notices. ¿Qui buono?
If laughter is the best medicine, who are the best doctors?
(Score: 2) by The Mighty Buzzard on Tuesday December 12 2017, @11:41PM (3 children)
FTFY. Looking for perfection will have you producing nothing. Getting "hello world" out the door in assembly without an OS wouldn't even be viable because you can't trust the silicon it runs on unless you created the chip using the same perfect security standard.
Looking for "better without becoming a massive time sink" is what you want to be doing as a base. If your particular situation calls for more than that, do more than that.
My rights don't end where your fear begins.
(Score: 2) by Arik on Wednesday December 13 2017, @12:24AM (2 children)
But if you zoom back out to the macro scope, it's a disaster in progress.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by The Mighty Buzzard on Wednesday December 13 2017, @02:54AM (1 child)
I'm not by any stretch saying not to keep on top of things as best you're able and write secure code to the best of your ability. That's one of the programming givens for me. Spending months or years making double-super-certain that under no circumstances can your program ever fail in an unfortunate way is not helpful to anyone though unless you work in a national security capacity.
My rights don't end where your fear begins.
(Score: 2) by Arik on Wednesday December 13 2017, @03:55AM
That's great and I think you are misunderstanding me a little.
I'm not criticizing your personal practices, which I am sure are better than industry standard and nothing to be ashamed about.
I'm talking about the broader eco-system. You're working inside a system where you have no choice but to rely on the foundations that others built. And it's not your fault that those foundations were not built to be reliable.
But it still might concern you.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by DannyB on Tuesday December 12 2017, @05:00PM (1 child)
I seem to remember a serious PHP vulnerability some months back. A web app processing a URL could be compromised. Because it uses CURL to do the URL processing. And CURL, which was never designed to be used in a web application, has buckets and ooodles of fantastical flexible goodness in complex ways it can process requests. Thus PHP inherits those same fantastical features. Which lead to remote code execution. A vulnerability created by a complex fairly obscure interaction of PHP with CURL in order that PHP implementers could lazily use CURL.
So a web application that could seeming harmlessly allow a user to, say, fetch an image from a remote location and upload it as their, say, avatar or logo, could trigger remote code execution through a carefully crafted URL with whipped cream added.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 0) by Anonymous Coward on Thursday December 14 2017, @12:44AM
yes, and IIRC those functions were supposed to be disabled in php.ini by anyone who pays attention to security.
(Score: 0) by Anonymous Coward on Tuesday December 12 2017, @03:15PM (3 children)
FTFY
Something about an oblig link to a demonstration of a hacked that produces executables with malicious code and also compiles vanilla compiler source code into a compiler with the same hack.
Naah, that can't be possible. C is the Language of the GODS themselves, from which the Universe hath been created! Before om, the sound of creation, there was C!
(Score: 2) by Arik on Tuesday December 12 2017, @03:30PM (2 children)
If laughter is the best medicine, who are the best doctors?
(Score: 2) by DannyB on Tuesday December 12 2017, @05:13PM (1 child)
C, and probably other languages, like Java, aren't so much the problem. It is their libraries that are the problem.
Why did anyone ever think that null terminated strings were a good idea?
Why did someone think that library string operations given a string pointer shouldn't also require a max buffer limit?
And then there are formatting vulnerabilities. Just as one example, printf which accepts a complex formatting string. Lazy application programmers simply pass the string they want to print as the formatting string with no additional arguments.
Now I would point out that Java solves these problems. But does not eliminate other problems. See my PHP with CURL post a few posts above.
Who ever thought that running an Applet in a Browser that could have all sorts of complex interactions with the browser's JavaScript was a good idea? (And substitute "Applet" with any of: Flash, ActiveX and Silverblight)
Even ignoring browser Applets, a server side Java application can have problems with complex interactions of libraries similar to the PHP / CURL interaction problem. And I suppose so could C or C++ have similar complex library interaction problems.
I think the compiler is the very least of anyone's worries. Compilers tend to be extremely solid. They generate fixed machine code from fixed source code. Even in Java, the bytecode is generated from source, and then at execution time is compiled into the specific type of machine code to fit your actual hardware processor. These processes are not generally where the vulnerabilities lie. (Although C was used as the example of the classic Trusting Trust problem, what if your compiler binary was modified so that when it compiled the compiler, it realized it was doing so and generated a compromised binary of the compiler from clean source code.)
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by Arik on Tuesday December 12 2017, @05:52PM
Oh libraries are a big part of it. But in practice, they might as well be the language, they're how the language is actually used and in most cases they're why it's used.
But the languages themselves, in the more idealistic meaning, are still part of this. We didn't make higher and higher levels of language just for shits and giggles, we did it because by moving the level of abstraction higher you offload more of the work onto the compiler/interpreter. That means less work you have to do to get the computer to do something, which seems like an obvious win in many cases.
But the trade-off is that the more abstractions lay between you and the actual code, the more difficult it is when you look at it from the security standpoint. From the standpoint not of 'how do we make it do x?' but instead 'how do we make sure it doesn't do anything besides x?'
"Why did anyone ever think that null terminated strings were a good idea?"
Why did anyone ever think it was a good idea to name the special termination character null, which means 0, which is another character entirely? That's my question.
But to answer your question, it seems like a very good idea to store strings in as compact a form as possible when you're working with systems that have ~1kb RAM.
This is actually an issue that relates back to the level of abstraction, in an interesting way. If you're programming directly with a first or second order language, you have to think about these things directly, and in a form that pretty much mirrors the actual reality of what's happening in the program. So you are able to think about how many bytes you have available to terminate a string, about how many physical read requests you're generating, and so forth. And that means you have to know what machine you're writing for, it means portability between different sorts of computer systems is just not part of the design. When you put more abstractions between yourself and that reality, you lose a lot of your ability to control the hardware, and the idea is explicitly to trust that the compiler or interpreter is going to do that thinking for you so you can focus on other things. And so you get portability designed in, C as 'portable assembly' so when you use it you should be able to forget all about the physical hardware and just say 'store these strings' and then 'return the strings stored earlier' and not need to worry at all about what they're stored on in the meantime or how they're terminated or any of that.
But as your example points out, that's not really what you get. You're still writing to a machine, it's just that it's no longer the physical machine that the program will run on, it's a sort of abstract machine, and you're still worrying about how many bytes are being used to terminate your strings. So java is another incarnation of the same idea, and now that's made explicit, and you're programming to a VM. Which at least has better specifications available now that it's explicit.
"Who ever thought that running an Applet in a Browser that could have all sorts of complex interactions with the browser's JavaScript was a good idea?"
People who have money and buy ads, unfortunately.
If laughter is the best medicine, who are the best doctors?
(Score: 1, Insightful) by Anonymous Coward on Tuesday December 12 2017, @07:46PM
> No matter how perfect your script, the actual program here is still the interpreter
No matter how perfect your interpreter, the actual program here is still the microcode running in the CPU, firmware in the bus controllers, etc.
Also,
>nothing you do in your script can change that.
Wrong. From TFA, these issues are usage-dependent. Ie. if you don't use the poor idioms, the interpreter can't choke on them, no matter what parameters are passed nor what specific interpreter runs the code.
(Score: 0) by Anonymous Coward on Tuesday December 12 2017, @09:19AM
BTW, Perl can provide a secure sandbox if one wants to interpret external strings as code:
http://perldoc.perl.org/Safe.html [perl.org]