
Libcurl remote code execution - marshray
http://blog.volema.com/curl-rce.html
======
agwa
This is nasty but fortunately it only affects fairly recent versions of curl,
specifically curl 7.26.0 up to and including 7.28.1. That means Debian Stable
and Ubuntu 12.04 aren't affected.

As a general rule, if you use libcurl in an application and follow redirects
you should probably restrict CURLOPT_REDIR_PROTOCOLS to just HTTP and HTTPS
(and maybe FTP). Otherwise a nefarious site could redirect curl to, for
example, a IMAP, POP, or SMTP URL, which is potentially undesirable even
without this vulnerability. If you're just using curl to talk HTTP(S) you
really don't need any of these other protocols.

~~~
ars
Why does curl even allow that?

------
rachelbythebay
Regarding version numbers, I'll mention something here that I used to have to
tell customers in the web hosting biz all the time: stuff sometimes gets
backported and version numbers don't tell the whole story. For instance, RHEL
5 has "curl-7.15.5-15.el5" right now, and that would suggest it doesn't
support either of the CURLOPTS required to disable this.

However, the actual build loops in a patch called
curl-7.15.5-CVE-2009-0037.patch, and that adds in all of the CURLPROTO_* magic
required to lock down an application. I discovered this tonight when updating
my client-side code to restrict redirects and found that it would build fine
on RHEL 5 even though I expected it to die. A little digging around in the
source RPM explained it.

So, if you're on an OS like RHEL and you think you might not be able to use
this feature, try looking in your curl.h file. You might actually have support
courtesy of some backported patch from your distributor.

------
wereHamster
Somebody wrote new code which uses strcat() in 2012 (the commit which
introduced that bug was written in June 2012)? That's.. wow.. unbelievable.

~~~
xxpor
Is this kind of stuff not code reviewed?

~~~
nolok
It's an open source project, you are free to do so if you have the time or the
need, and contribute back any corrections.

~~~
xxpor
I guess I'm just idealistic, but I would think for something this security
sensitive or important (see "Fixing" TWO in glibc), they would have code
reviews before anything could be committed.

In this case, a automated system rejecting anything that uses the non
"n"(strcat vs strncat, etc.) version of the string functions in C would have
worked.

~~~
peterwwillis
If you expect code reviews and automated tests for an open-source product
that's developed in spare time for no money, you can go to this page
(<http://curl.haxx.se/donation.html>), click the PayPal button, and be very
very generous.

------
rmccue
If there's anyone using my Requests for PHP library [0], just an FYI that it
is not vulnerable to this as it handles redirection outside of cURL and
double-checks all URLs. That said, I'll be pushing some commits momentarily to
ensure that this is also forced via CURLOPT_PROTOCOLS inside the cURL
transport.

[0]: <http://requests.ryanmccue.info/>

------
jackowayed
I've been reading more about security lately, and one thing I don't understand
is how buffer overflows allow for true RCE these days. I believe all modern
processors support having non-executable pages; why is any program-writeable
page executable? Especially in C, where there's no JIT. It also seems like
address space randomization would make RCE pretty hard.

Obviously they can still arbitrarily write the instruction pointer, which is
very bad and possibly bootstrappable into fully RCE, but I still see more
conventional RCE described in recent books and wonder if and why it's still
doable.

~~~
grn
Here you can read about defeating the protections you mentioned:
[http://www.blackhat.com/presentations/bh-
europe-09/Fritsch/B...](http://www.blackhat.com/presentations/bh-
europe-09/Fritsch/Blackhat-Europe-2009-Fritsch-Buffer-Overflows-Linux-
whitepaper.pdf)

------
mmastrac
So apparently cURL speaks POP3. I had no idea until seeing this. This might be
useful to know for future projects.

~~~
mattlong
FYI, `curl --version` shows all the protocols it supports

~~~
grn
On my Debian Squeeze I get the following:

    
    
        $ curl --version
        curl 7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6
        Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp 
        Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
    

Looks pretty impressive.

------
jimrandomh
Thus illustrating, once again, that the C programming language is unfit for
network-facing software and that using it in that role is irresponsible.

~~~
mattlong
What is a suitable alternative?

~~~
daeken
C++. I hate it, it has its own host of problems, and memory corruption is
certainly still an issue there, but the most common issues that plague C apps
won't plague properly written C++ apps/libraries. C's string handling (or lack
thereof) has cost the world an immeasurable amount of time and money.

The biggest advantage that C++ has over just about everything else, is that
you can use it to write libraries usable from everything else, and you can do
it very easily. You can expose a C-style API trivially, and bind it to
everything you want; that advantage can't be overstated.

While I'd love for everything to be written in pure safe, managed code, that's
not viable right now. C++ is the best alternative we have, when safe languages
aren't usable for the task.

~~~
pjungwir
> the most common issues that plague C apps won't plague _properly written_
> C++

or properly written C, either. :-)

------
lenkite
I hate the fact that most of the C standard library needs to be ignored due to
buffer overflow/security issues. I nearly always use the cross platform "Safe
C Library" anytime I do something in C:
<http://sourceforge.net/projects/safeclib/> <http://www.drdobbs.com/cpp/the-
safe-c-library/214502214>

------
roel_v
I guess I'm just a dumbass, but does the linked PoC do more than just
overwrite EIP with 'A'? Is the payload left as an exercise for the reader or
is this a working example and am I missing something clever?

~~~
anyfoo
The stack was overwritten with 'A's, and thus upon returning from a function
the return address consisted entirely of 'A's, which is why EIP is now filled
with it.

A clever hacker would use this to jump into some malicious code instead;
that's how stack overflow exploits usually work.

So, yes, the actual payload is left as an exercise for the reader, but this
shows that there's already everything there to make it possible.

~~~
roel_v
Oh OK, then I did see correctly after all. But still, on many modern systems
(e.g. with non-executable stack) it would require fairly sophisticated
trickery in the payload to make this do anything. I mean, getting control over
EIP is a very good first step, but this isn't 1995.

~~~
gsg
Control over the program counter allows return-into-libc or other ROP attacks.

------
stcredzero
Seems OS X 10.8.2 is unaffected.

    
    
        curl --version
    

Gives me 7.24 or so.

------
javajosh
Mitigation: wget.

~~~
X-Istence
Not having wget installed stops about 60% of the PHP shell scripts I've seen
dropped on servers.

~~~
dchest
Not having PHP installed stops 100% of them.

~~~
contingencies
Less snarky and more portable option: avoid webserver-writeable directories.

