This post tries to prove that vulnerabilities can in fact be very subtle and that even people who master their toolkit and libraries can easily fall for them. It is based upon a vulnerability in ownCloud server fixed in June 2015.
cURL is probably known to most readers of this blog. If not: It is a library and command-line tool that can be used to send HTTP requests to other servers. It has an official PHP wrapper maintained by the PHP team.
Everybody who has used cURL before will probably agree: cURL is a mighty and complex utility, the PHP wrapper is no exception. Stating it is used to send HTTP requests is a bit of an understatement, it supports as well DICT, FILE, FTP, GOPHER, IMAP, LDAP, POP3, RTMP, RTSP, SCP, SFTP, SMB, SMTP, TELNET and TFTP.
As with any mighty tool, there are a lot of possibilities to shoot yourself in your own foot.
Read on for examples...
(Score: 5, Insightful) by DarkMorph on Thursday January 28 2016, @02:19PM
This is not a vulnerability. This is a damn feature built into the library that's properly documented. Prefixing the '@' character doesn't magically trigger file uploading mechanics out of thin air; cURL was clearly built to do this. The only vulnerability here is the damn programmer who didn't read the documentation for the library before using it.
(Score: 4, Interesting) by PizzaRollPlinkett on Thursday January 28 2016, @02:34PM
I was looking at the ownCloud (should that be "pwnCloud"?) security advisory, and it doesn't seem to be a problem with curl. I think curl is working as designed. I don't know about the PHP wrapper (other than a PHP wrapper to curl, or anything, sounds like a bad idea), but using a testing tool like curl in a production server sounds like you're just asking for trouble. The blog post is using GET data without sanitizing it, which is TRWTF here. If you're going to use a testing tool with a feature that lets you get any filename, you might want to purge @ from the input string as part of the sanitizing process. The larger issue is not to use curl in production web sites. I'm not sure if I learned anything or not from this. GET and POST parameters ought to be sanitized, especially before passing them to a third-party library, especially when it's a general-purpose testing tool not designed to be used on production web sites. I guess using curl is easier than writing, well, whatever pwnCloud does from scratch, but it's not the right tool for the job.
What's frightening is:
"Do you happen to see anything dangerous with this? Most developers I showed this snippet to certainly did not."
I saw the use of unsanitized GET data right away. I don't know who "most developers" are (what percentage of what sample population?), but the fact that this didn't bother them reinforces PHP's bad reputation.
(E-mail me if you want a pizza roll!)
(Score: 3, Informative) by TheRaven on Thursday January 28 2016, @03:02PM
sudo mod me up
(Score: 2) by kurenai.tsubasa on Friday January 29 2016, @01:06AM
This is so, but tools like curl and wget are also important for API development (think REST). I use a Chrome-based add-on these days, but it's important to throw all kinds of weird requests at an API to make sure one has programmed it correctly. Are you sure that query is returning 403 or 404 as it should instead of 500? (I prefer 404 to 403 for the same reason one should not reveal to the world whether the username or password was invalid. IOW, if you are not allowed to access that resource, it doesn't exist as far as you're concerned.)
(Score: 3, Informative) by meustrus on Thursday January 28 2016, @03:05PM
So did I, and I suspect most people surveyed did. They just couldn't nail down what "the problem" would be, since "the problem" is automagic file uploads. Unsanitized user input is just a smell until it hits the wrong spot after all.
Luckily, anybody who has worked with the cURL API in PHP long enough will default to stringifying everything and avoid the magic options like the plague because the magic doesn't work properly anyway. Most of the PHP APIs are really terrible because of exactly this sort of thing: every input field does some kind of magic, like handling file uploads with magic strings, automatically (kind of) escaping your user data for the database before it knows what database it's being SQL injected into, taking either an array or a varargs, automatically casting objects to arrays, both of the last two magic behaviors combined which is *awesome* when you want to pass in a single object, logging warnings for expected behaviors despite also returning an error code...need I go on?
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 2) by isostatic on Thursday January 28 2016, @08:11PM
I saw the use of unsanitized GET data right away. I don't know who "most developers" are (what percentage of what sample population?), but the fact that this didn't bother them reinforces PHP's bad reputation.
I see unsanitised inputs all over the place, especially with PHP (there seems to be a culture of sql commands by concatting them.
That said, I'm not sure how sanitisation would help here (ok, perhaps your username wouldn't have an @ sign in, but what if the field was "twitter handle", and had something like (pseudocode)
$unsafetwitter =~ /([A-Za-z0-9@]*)/;
$safetwitter = $1;
doCurl(twitter => $safetwitter);
(Score: 2) by jimshatt on Friday January 29 2016, @12:57AM
(Score: 5, Insightful) by cockroach on Thursday January 28 2016, @02:29PM
I thought we had established that passing unsanitized input data to another application was not typically a good idea. Blaming this on PHP/cURL is like blaming C when the programmer passes the contents of a remote file to system(3).
(Score: 3, Interesting) by Thexalon on Thursday January 28 2016, @03:26PM
I will blame it on PHP. The idea of an '@' prefix indicating that what follows will be not a string but a filename that you need to get the contents of is mindbogglingly stupid: It carries giant risks (like this one), and all it does is saves you explicitly loading the file contents.
Magic strings for no particular reason are an ongoing and fundamental design flaw with PHP. "fopen('/etc/hosts', 'r');" will do more-or-less what you expect, but "fopen('https://www.badsitehere.com/download-this-virus', 'r');" will go out to the specified URL and download that virus. And while that can be guarded against, the fact that somebody thought this was a good idea tells you that the language designers of PHP are foolishly creating all sorts of traps and pitfalls.
All languages make it possible for a programmer to shoot themselves in the foot, but PHP loads the gun and points it at your foot for you. And then its defenders say "Well, it was your fault for pulling the trigger!"
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 3, Insightful) by DannyB on Thursday January 28 2016, @03:53PM
It's okay if you blame PHP -- for the right reasons.
In this case, you're blaming it for something it is innocent of.
That @ operator you are complaining about is part of cURL's behavior, not PHP's behavior.
cURL is doing something very useful for what it was designed for. Specifically: a command line utility that its user is in full control of. Just like tons of other dangerous command line tools: rm, netcat, kill, and many others.
What I would blame PHP for, or perhaps one of its libraries, is implementing a simple function of contacting another server by taking the easy way out and relying on a very powerful command line tool, without fully understanding what that tool is capable of doing.
Would a Dyson sphere [soylentnews.org] actually work?
(Score: 3, Interesting) by draconx on Thursday January 28 2016, @05:54PM
Are you certain? From the curl documentation for CURLOPT_POSTFIELDS [curl.haxx.se] (emphasis added):
I think this is (or was, as the feature has apparently been removed in new versions of PHP) squarely a problem with the PHP bindings to the library.
(Score: 2) by tibman on Thursday January 28 2016, @04:22PM
I actually like php. But i explain the language differences to people like this: Microsoft tries to make C# into a pit of success (you tend to fall into success). PHP is just pits.
SN won't survive on lurkers alone. Write comments.
(Score: 2) by Thexalon on Friday January 29 2016, @02:37PM
So why do you like PHP, when there are alternatives that make it easier for you to succeed?
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by tibman on Friday January 29 2016, @03:52PM
Flexibility. A lot of what PHP has been doing for a long time has only recently become popular in strongly typed languages like C#. Inversion of control / dependency injection being a big one. Anonymous functions and closures are also things that strongly typed languages shy away from and force you to do flaming cheetah backflips to achieve similar functionality. Interfaces, for example, aren't even required in PHP because you can call whatever method you want with as many parameters as you want. Though if you wanted one, you could certainly make one (that's the flexibility part). You can do strange things like magic getter/setters which opens up new possibilities. I don't know of any other language that has something similar.
PHP is typically thought of as a web language but i think of it as a general purpose language. Instead of bash scripting i sometimes just write a php one. Then at a later date if i want it to be more interactive i can quickly put a real UI on it (or a web interface). If the script grows to more than a hundred lines i can promote it from procedural script to object oriented program (refactor into classes and multiple files). PHP is ugly and very inconsistent. But i prefer it over the well manicured languages because it is so flexible. But to each their own! : )
Example ui code with gtk: https://en.wikipedia.org/wiki/PHP-GTK#Example [wikipedia.org]
SN won't survive on lurkers alone. Write comments.
(Score: 0) by Anonymous Coward on Thursday January 28 2016, @04:24PM
http://use.perl.org/use.perl.org/_Aristotle/journal/33448.html [perl.org]
Don't you just love PHP?
(Score: 2) by TheRaven on Thursday January 28 2016, @03:28PM
sudo mod me up
(Score: 3, Interesting) by The Mighty Buzzard on Thursday January 28 2016, @03:56PM
Normally I lurve to hate on PHP but it so happens I lurve to hate on strongly typed languages even more. Anyone who can't keep track of their own data types needs to not be programming anything that anyone else will ever use. Programming languages are not there to hold your hand and coddle you, they should fully allow you to shoot yourself in the foot if you so feel the need. They just shouldn't do like PHP does and default to aiming at your foot.
My rights don't end where your fear begins.
(Score: 3, Insightful) by tangomargarine on Thursday January 28 2016, @05:36PM
I would think strong typing would be helpful as to making it obvious whether you shot yourself at all, and whether it was in the foot or somewhere else; not that you get halfway across the world and find out the output is weird because Python silently converted some type for you somewhere along the way into something you weren't expecting.
And besides, allowing you to shoot yourself in the foot while strongly-typed is called "casting."
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 0) by Anonymous Coward on Friday January 29 2016, @01:34PM
On the other hand, the rest of us love that our compilers do the basic type checking that can prevent huge classes of bugs ever getting past the compilation phase.
(Score: 2) by The Mighty Buzzard on Friday January 29 2016, @04:54PM
That's what warnings are for. Errors are tyranny.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Thursday January 28 2016, @04:06PM
...nothing like this could ever happen.
*sigh*
(Score: 0) by Anonymous Coward on Thursday January 28 2016, @04:27PM
...nothing like this could ever happen.
Specifically, stuff like the '@/etc/passwd' bit mentioned in TFA.
(Score: 3, Interesting) by jcross on Thursday January 28 2016, @05:31PM
Well, in a jail you couldn't dump /etc/password, but you could certainly dump any PHP source file that apache had access to, which might well contain secrets you don't want to share.
(Score: 3, Insightful) by isostatic on Thursday January 28 2016, @07:56PM
Well it depends what else is in that jail. The same would apply to a linux container or a solaris zone.
However blaming curl here seems to be just fishing for clicks. Everyone knows PHP is a pile of shit when it comes to security (and it's not just php code, although in this case that seems to be the cause, but where is the input sanitisation?) so yet another blog on yet another php exploit isn't exactly enthralling.
Curl however is widely used and a security issue there is worth investigating. Turns out there's nothing of interest, and the "examples" and "vulnerabilities" implies there would be far more on this blob than "If you pass @filename to curl in old versions of PHP it will read the file name"
(Score: 0) by Anonymous Coward on Thursday January 28 2016, @08:52PM
Good point.
Besides, who writes a program where it accepts input from an HTML form, and then turns around and just POSTS it to some random website?
That's what I thought.