1libcurl-security(3)            libcurl security            libcurl-security(3)
2
3
4

NAME

6       libcurl-security - security considerations when using libcurl
7

Security

9       The  libcurl  project takes security seriously.  The library is written
10       with caution and precautions are taken to mitigate many kinds of  risks
11       encountered  while  operating with potentially malicious servers on the
12       Internet. It is a powerful library, however, which  allows  application
13       writers  to make trade-offs between ease of writing and exposure to po‐
14       tential risky operations. If used the right way, you can use libcurl to
15       transfer data pretty safely.
16
17       Many  applications  are used in closed networks where users and servers
18       can (possibly) be trusted,  but  many  others  are  used  on  arbitrary
19       servers  and are fed input from potentially untrusted users.  Following
20       is a discussion about some risks in the ways in which applications com‐
21       monly use libcurl and potential mitigations of those risks. It is by no
22       means comprehensive, but shows classes of attacks that robust  applica‐
23       tions  should  consider.  The  Common  Weakness  Enumeration project at
24       https://cwe.mitre.org/ is a good reference for many of these and  simi‐
25       lar types of weaknesses of which application writers should be aware.
26

Command Lines

28       If  you  use  a command line tool (such as curl) that uses libcurl, and
29       you give options to the tool on the command line those options can very
30       likely  get  read  by  other users of your system when they use 'ps' or
31       other tools to list currently running processes.
32
33       To avoid these problems, never feed sensitive things to programs  using
34       command line options. Write them to a protected file and use the -K op‐
35       tion to avoid this.
36

.netrc

38       .netrc is a pretty handy file/feature that allows you to login  quickly
39       and  automatically to frequently visited sites. The file contains pass‐
40       words in clear text and is a real security risk. In  some  cases,  your
41       .netrc  is  also stored in a home directory that is NFS mounted or used
42       on another network based file system, so the clear text  password  will
43       fly through your network every time anyone reads that file!
44
45       For  applications  that enable .netrc use, a user who manage to set the
46       right URL might then be possible to pass on passwords.
47
48       To avoid these problems, don't use .netrc files and never  store  pass‐
49       words in plain text anywhere.
50

Clear Text Passwords

52       Many  of  the  protocols  libcurl supports send name and password unen‐
53       crypted as clear text (HTTP Basic authentication, FTP, TELNET etc).  It
54       is  very  easy  for anyone on your network or a network nearby yours to
55       just fire up a network analyzer tool and eavesdrop on  your  passwords.
56       Don't  let  the fact that HTTP Basic uses base64 encoded passwords fool
57       you. They may not look readable at a first glance, but they very easily
58       "deciphered" by anyone within seconds.
59
60       To  avoid this problem, use an authentication mechanism or other proto‐
61       col that doesn't let snoopers see your password: Digest, CRAM-MD5, Ker‐
62       beros, SPNEGO or NTLM authentication. Or even better: use authenticated
63       protocols that protect the entire connection and everything  sent  over
64       it.
65

Un-authenticated Connections

67       Protocols that don't have any form of cryptographic authentication can‐
68       not with any certainty know that they communicate with the right remote
69       server.
70
71       If  your  application is using a fixed scheme or fixed host name, it is
72       not safe as long as the connection is un-authenticated. There can be  a
73       man-in-the-middle  or in fact the whole server might have been replaced
74       by an evil actor.
75
76       Un-authenticated protocols are unsafe. The data that comes back to curl
77       may  have  been injected by an attacker. The data that curl sends might
78       be modified before it reaches the intended server. If it  even  reaches
79       the intended server at all.
80
81       Remedies:
82
83       Restrict operations to authenticated transfers
84              Ie use authenticated protocols protected with HTTPS or SSH.
85
86       Make sure the server's certificate etc is verified
87              Never ever switch off certificate verification.
88

Redirects

90       The  CURLOPT_FOLLOWLOCATION(3)  option automatically follows HTTP redi‐
91       rects sent by a remote server.  These redirects can refer to  any  kind
92       of  URL,  not  just HTTP. libcurl restricts the protocols allowed to be
93       used in redirects for security reasons: only HTTP, HTTPS, FTP and  FTPS
94       are  enabled by default. Applications may opt to restrict that set fur‐
95       ther.
96
97       A redirect to a file: URL would cause the libcurl to  read  (or  write)
98       arbitrary  files from the local filesystem.  If the application returns
99       the data back to the user  (as  would  happen  in  some  kinds  of  CGI
100       scripts),  an  attacker could leverage this to read otherwise forbidden
101       data (e.g.  file://localhost/etc/passwd).
102
103       If authentication credentials are stored in the ~/.netrc file, or  Ker‐
104       beros  is in use, any other URL type (not just file:) that requires au‐
105       thentication is also at risk.  A redirect such as  ftp://some-internal-
106       server/private-file  would  then  return  data  even when the server is
107       password protected.
108
109       In the same way, if an unencrypted SSH private key has been  configured
110       for  the user running the libcurl application, SCP: or SFTP: URLs could
111       access   password   or   private-key    protected    resources,    e.g.
112       sftp://user@some-internal-server/etc/passwd
113
114       The CURLOPT_REDIR_PROTOCOLS(3) and CURLOPT_NETRC(3) options can be used
115       to mitigate against this kind of attack.
116
117       A redirect can also specify a location available only  on  the  machine
118       running  libcurl,  including  servers hidden behind a firewall from the
119       attacker.    e.g.    http://127.0.0.1/    or    http://intranet/delete-
120       stuff.cgi?delete=all or tftp://bootp-server/pc-config-data
121
122       Applications can mitigate against this by disabling CURLOPT_FOLLOWLOCA‐
123       TION(3) and handling redirects itself, sanitizing  URLs  as  necessary.
124       Alternately,  an  app could leave CURLOPT_FOLLOWLOCATION(3) enabled but
125       set CURLOPT_REDIR_PROTOCOLS(3) and  install  a  CURLOPT_OPENSOCKETFUNC‐
126       TION(3) callback function in which addresses are sanitized before use.
127

Local Resources

129       A  user  who  can  control  the  DNS server of a domain being passed in
130       within a URL can change the address of the host to a local, private ad‐
131       dress  which  a  server-side  libcurl-using application could then use.
132       e.g. the innocuous URL http://fuzzybunnies.example.com/ could  actually
133       resolve  to  the  IP  address  of  a  server behind a firewall, such as
134       127.0.0.1 or 10.1.2.3.  Applications can mitigate against this by  set‐
135       ting  a CURLOPT_OPENSOCKETFUNCTION(3) and checking the address before a
136       connection.
137
138       All the malicious scenarios regarding redirected  URLs  apply  just  as
139       well to non-redirected URLs, if the user is allowed to specify an arbi‐
140       trary URL that could point to a private resource. For  example,  a  web
141       app  providing a translation service might happily translate file://lo‐
142       calhost/etc/passwd and display the result.  Applications  can  mitigate
143       against this with the CURLOPT_PROTOCOLS(3) option as well as by similar
144       mitigation techniques for redirections.
145
146       A malicious FTP server could in response to the PASV command return  an
147       IP  address  and  port  number  for  a  server local to the app running
148       libcurl but behind a firewall.  Applications can mitigate against  this
149       by using the CURLOPT_FTP_SKIP_PASV_IP(3) option or CURLOPT_FTPPORT(3).
150
151       Local  servers  sometimes  assume  local  access comes from friends and
152       trusted   users.   An   application    that    expects    https://exam
153       ple.com/file_to_read         that        and        instead        gets
154       http://192.168.0.1/my_router_config might print a file that would  oth‐
155       erwise be protected by the firewall.
156
157       Allowing your application to connect to local hosts, be it the same ma‐
158       chine that runs the application or a machine on the same local network,
159       might be possible to exploit by an attacker who then perhaps can "port-
160       scan" the particular hosts -  depending  on  how  the  application  and
161       servers acts.
162

IPv4 Addresses

164       Some users might be tempted to filter access to local resources or sim‐
165       ilar based on numerical IPv4 addresses used in URLs. This is a bad  and
166       error-prone  idea  because  of the many different ways a numerical IPv4
167       address can be specified and libcurl accepts: one to four dot-separated
168       fields using one of or a mix of decimal, octal or hexadecimal encoding.
169

IPv6 Addresses

171       libcurl  will  normally handle IPv6 addresses transparently and just as
172       easily as IPv4 addresses. That means that a  sanitizing  function  that
173       filters  out  addresses like 127.0.0.1 isn't sufficient--the equivalent
174       IPv6 addresses ::1, ::, 0:00::0:1, ::127.0.0.1 and  ::ffff:7f00:1  sup‐
175       plied  somehow by an attacker would all bypass a naive filter and could
176       allow access to undesired local resources.  IPv6 also has  special  ad‐
177       dress blocks like link-local and site-local that generally shouldn't be
178       accessed by a server-side libcurl-using application.  A  poorly-config‐
179       ured  firewall  installed  in a data center, organization or server may
180       also be configured to limit IPv4 connections but leave IPv6 connections
181       wide  open.   In some cases, setting CURLOPT_IPRESOLVE(3) to CURL_IPRE‐
182       SOLVE_V4 can be used to limit resolved addresses to IPv4 only  and  by‐
183       pass these issues.
184

Uploads

186       When  uploading,  a  redirect  can cause a local (or remote) file to be
187       overwritten. Applications must not allow  any  unsanitized  URL  to  be
188       passed  in  for  uploads. Also, CURLOPT_FOLLOWLOCATION(3) should not be
189       used on uploads.  Instead, the applications  should  consider  handling
190       redirects itself, sanitizing each URL first.
191

Authentication

193       Use of CURLOPT_UNRESTRICTED_AUTH(3) could cause authentication informa‐
194       tion to be sent to an unknown second server.  Applications can mitigate
195       against  this by disabling CURLOPT_FOLLOWLOCATION(3) and handling redi‐
196       rects itself, sanitizing where necessary.
197
198       Use of the CURLAUTH_ANY option to CURLOPT_HTTPAUTH(3) could  result  in
199       user name and password being sent in clear text to an HTTP server.  In‐
200       stead, use CURLAUTH_ANYSAFE which ensures  that  the  password  is  en‐
201       crypted over the network, or else fail the request.
202
203       Use  of the CURLUSESSL_TRY option to CURLOPT_USE_SSL(3) could result in
204       user name and password being sent in clear text to an FTP server.   In‐
205       stead, use CURLUSESSL_CONTROL to ensure that an encrypted connection is
206       used or else fail the request.
207

Cookies

209       If cookies are enabled and cached, then a user could craft a URL  which
210       performs  some  malicious  action to a site whose authentication is al‐
211       ready  stored  in  a   cookie.   e.g.   http://mail.example.com/delete-
212       stuff.cgi?delete=all  Applications  can  mitigate  against this by dis‐
213       abling cookies or clearing them between requests.
214

Dangerous SCP URLs

216       SCP URLs can contain raw commands within the scp: URL, which is a  side
217       effect of how the SCP protocol is designed. e.g.
218
219         scp://user:pass@host/a;date >/tmp/test;
220
221       Applications  must  not allow unsanitized SCP: URLs to be passed in for
222       downloads.
223

file://

225       By default curl and libcurl support file:// URLs. Such a URL is  always
226       an  access,  or attempted access, to a local resource. If your applica‐
227       tion wants to avoid that, keep control of what URLs to use and/or  pre‐
228       vent curl/libcurl from using the protocol.
229
230       By default, libcurl prohibits redirects to file:// URLs.
231
232

Warning: file:// on Windows

234       The  Windows  operating  system will automatically, and without any way
235       for applications to disable it, try to establish a  connection  to  an‐
236       other  host  over  the  network and access it (over SMB or other proto‐
237       cols), if only the correct file path is accessed.
238
239       When first realizing this, the curl team tried to filter out  such  at‐
240       tempts  in  order to protect applications for inadvertent probes of for
241       example internal networks etc. This resulted in CVE-2019-15601 and  the
242       associated security fix.
243
244       However,  we've since been made aware of the fact that the previous fix
245       was far from adequate as there are several  other  ways  to  accomplish
246       more  or  less the same thing: accessing a remote host over the network
247       instead of the local file system.
248
249       The conclusion we have come to is that this is a weakness or feature in
250       the  Windows  operating system itself, that we as an application cannot
251       safely protect users against. It would just be a whack-a-mole  race  we
252       don't  want  to  participate  in.  There are too many ways to do it and
253       there's no knob we can use to turn off the practice.
254
255       If you use curl or libcurl on Windows (any version), disable the use of
256       the  FILE  protocol  in curl or be prepared that accesses to a range of
257       "magic paths" will potentially make your system  try  to  access  other
258       hosts on your network. curl cannot protect you against this.
259

What if the user can set the URL

261       Applications  may find it tempting to let users set the URL that it can
262       work on. That's probably fine, but opens up for mischief  and  trickery
263       that  you  as an application author may want to address or take precau‐
264       tions against.
265
266       If your curl-using script allow a custom URL do you also, perhaps unin‐
267       tentionally,  allow  the user to pass other options to the curl command
268       line if creative use of special characters are applied?
269
270       If the user can set the URL, the user can also specify the scheme  part
271       to  other protocols that you didn't intend for users to use and perhaps
272       didn't consider. curl supports over 20 different URL schemes. "http://"
273       might be what you thought, "ftp://" or "imap://" might be what the user
274       gives your application. Also, cross-protocol operations might  be  done
275       by  using  a particular scheme in the URL but point to a server doing a
276       different protocol on a non-standard port.
277
278       Remedies:
279
280       Use --proto
281              curl command lines can use --proto to limit what URL schemes  it
282              accepts
283
284       Use CURLOPT_PROTOCOLS
285              libcurl  programs can use CURLOPT_PROTOCOLS(3) to limit what URL
286              schemes it accepts
287
288       consider not allowing the user to set the full URL
289              Maybe just let the user provide data for parts of it?  Or  maybe
290              filter input to only allow specific choices?
291

RFC 3986 vs WHATWG URL

293       curl  supports  URLs  mostly  according  to how they are defined in RFC
294       3986, and has done so since the beginning.
295
296       Web browsers mostly adhere to the WHATWG URL Specification.
297
298       This deviance makes some URLs copied between browsers (or returned over
299       HTTP  for redirection) and curl not work the same way. This can mislead
300       users into getting the wrong thing, connecting to  the  wrong  host  or
301       otherwise not work identically.
302

FTP uses two connections

304       When  performing an FTP transfer, two TCP connections are used: one for
305       setting up the transfer and one for the actual data.
306
307       FTP is not only un-authenticated, but the  setting  up  of  the  second
308       transfer is also a weak spot. The second connection to use for data, is
309       either setup with the PORT/EPRT command that makes the  server  connect
310       back  to  the client on the given IP+PORT, or with PASV/EPSV that makes
311       the server setup a port to listen to and tells the client to connect to
312       a given IP+PORT.
313
314       Again, un-authenticated means that the connection might be meddled with
315       by a man-in-the-middle or that there's a malicious server pretending to
316       be the right one.
317
318       A malicious FTP server can respond to PASV commands with the IP+PORT of
319       a totally different machine. Perhaps even a third party host, and  when
320       there  are many clients trying to connect to that third party, it could
321       create a Distributed Denial-Of-Service attack out of it! If the  client
322       makes  an upload operation, it can make the client send the data to an‐
323       other site. If the attacker can affect what data the client uploads, it
324       can be made to work as a HTTP request and then the client could be made
325       to issue HTTP requests to third party hosts.
326
327       An attacker that manages to control curl's  command  line  options  can
328       tell curl to send an FTP PORT command to ask the server to connect to a
329       third party host instead of back to curl.
330
331       The fact that FTP uses two connections makes it  vulnerable  in  a  way
332       that is hard to avoid.
333

Denial of Service

335       A  malicious  server could cause libcurl to effectively hang by sending
336       data very slowly, or even no data at all but just keeping the TCP  con‐
337       nection open.  This could effectively result in a denial-of-service at‐
338       tack. The CURLOPT_TIMEOUT(3) and/or CURLOPT_LOW_SPEED_LIMIT(3)  options
339       can be used to mitigate against this.
340
341       A  malicious  server could cause libcurl to download an infinite amount
342       of data, potentially causing all of memory or disk to be  filled.  Set‐
343       ting the CURLOPT_MAXFILESIZE_LARGE(3) option is not sufficient to guard
344       against this.  Instead, applications should monitor the amount of  data
345       received within the write or progress callback and abort once the limit
346       is reached.
347
348       A malicious HTTP server could cause an infinite redirection loop, caus‐
349       ing  a  denial-of-service.  This  can  be  mitigated  by using the CUR‐
350       LOPT_MAXREDIRS(3) option.
351

Arbitrary Headers

353       User-supplied data must be sanitized when used  in  options  like  CUR‐
354       LOPT_USERAGENT(3),   CURLOPT_HTTPHEADER(3),  CURLOPT_POSTFIELDS(3)  and
355       others that are used to generate structured data. Characters  like  em‐
356       bedded  carriage  returns  or ampersands could allow the user to create
357       additional headers or fields that could cause malicious transactions.
358

Server-supplied Names

360       A server can supply data which the application may, in some cases,  use
361       as  a  file  name.  The curl command-line tool does this with --remote-
362       header-name, using the Content-disposition: header to generate  a  file
363       name.   An application could also use CURLINFO_EFFECTIVE_URL(3) to gen‐
364       erate a file name from a server-supplied  redirect  URL.  Special  care
365       must  be taken to sanitize such names to avoid the possibility of a ma‐
366       licious  server  supplying  one  like  "/etc/passwd",  "\autoexec.bat",
367       "prn:" or even ".bashrc".
368

Server Certificates

370       A secure application should never use the CURLOPT_SSL_VERIFYPEER(3) op‐
371       tion to disable certificate validation. There are numerous attacks that
372       are  enabled  by  applications  that  fail  to properly validate server
373       TLS/SSL certificates, thus enabling a malicious server to spoof  a  le‐
374       gitimate  one.  HTTPS  without validated certificates is potentially as
375       insecure as a plain HTTP connection.
376

Showing What You Do

378       Relatedly, be aware that in situations  when  you  have  problems  with
379       libcurl and ask someone for help, everything you reveal in order to get
380       best possible help might also impose certain  security  related  risks.
381       Host names, user names, paths, operating system specifics, etc. (not to
382       mention passwords of course) may in fact be used by intruders  to  gain
383       additional information of a potential target.
384
385       Be  sure to limit access to application logs if they could hold private
386       or security-related data.  Besides the  obvious  candidates  like  user
387       names and passwords, things like URLs, cookies or even file names could
388       also hold sensitive data.
389
390       To avoid this problem, you must of course use your common sense. Often,
391       you  can  just  edit out the sensitive data or just search/replace your
392       true information with faked data.
393

Setuid applications using libcurl

395       libcurl-using applications that set the 'setuid' bit to run  with  ele‐
396       vated  or  modified  rights  also  implicitly  give that extra power to
397       libcurl and this should only be done after very careful considerations.
398
399       Giving setuid powers to the application means  that  libcurl  can  save
400       files  using those new rights (if for example the `SSLKEYLOGFILE` envi‐
401       ronment variable is set). Also: if the application wants  these  powers
402       to  read  or manage secrets that the user is otherwise not able to view
403       (like credentials for a login etc), it should  be  noted  that  libcurl
404       still  might understand proxy environment variables that allow the user
405       to redirect libcurl operations to use a proxy controlled by the user.
406

File descriptors, fork and ntlm_wb

408       An application that uses libcurl and invokes `fork()` will get all file
409       descriptors duplicated in the child process, including the ones libcurl
410       created.
411
412       libcurl  itself  uses  `fork()`  and  `execl()`  if  told  to  use  the
413       `CURLAUTH_NTLM_WB`  authentication  method  which  then will invoke the
414       helper command in a child process  with  file  descriptors  duplicated.
415       Make sure that only the trusted and reliable helper program is invoked!
416

Report Security Problems

418       Should  you  detect  or  just  suspect a security problem in libcurl or
419       curl,  contact  the  project  curl  security  team   immediately.   See
420       https://curl.se/dev/secprocess.html for details.
421
422
423
424libcurl 7.79.1                   June 17, 2021             libcurl-security(3)
Impressum