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
14       potential risky operations. If used the right way, you can use  libcurl
15       to 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
35       option 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
105       authentication is also at risk.  A redirect such  as  ftp://some-inter‐
106       nal-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
131       address  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
142       file://localhost/etc/passwd and display the result.   Applications  can
143       mitigate  against  this with the CURLOPT_PROTOCOLS(3) option as well as
144       by similar 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    http://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
158       machine that runs the application or a machine on the same  local  net‐
159       work,  might be possible to exploit by an attacker who then perhaps can
160       "port-scan" the particular hosts - depending on how the application and
161       servers acts.
162

IPv6 Addresses

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

Uploads

179       When  uploading,  a  redirect  can cause a local (or remote) file to be
180       overwritten. Applications must not allow  any  unsanitized  URL  to  be
181       passed  in  for  uploads. Also, CURLOPT_FOLLOWLOCATION(3) should not be
182       used on uploads.  Instead, the applications  should  consider  handling
183       redirects itself, sanitizing each URL first.
184

Authentication

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

Cookies

202       If cookies are enabled and cached, then a user could craft a URL  which
203       performs  some  malicious  action  to  a  site  whose authentication is
204       already  stored  in  a  cookie.  e.g.   http://mail.example.com/delete-
205       stuff.cgi?delete=all  Applications  can  mitigate  against this by dis‐
206       abling cookies or clearing them between requests.
207

Dangerous SCP URLs

209       SCP URLs can contain raw commands within the scp: URL, which is a  side
210       effect of how the SCP protocol is designed. e.g.
211
212         scp://user:pass@host/a;date >/tmp/test;
213
214       Applications  must  not allow unsanitized SCP: URLs to be passed in for
215       downloads.
216

file://

218       By default curl and libcurl support file:// URLs. Such a URL is  always
219       an  access,  or attempted access, to a local resource. If your applica‐
220       tion wants to avoid that, keep control of what URLs to use and/or  pre‐
221       vent curl/libcurl from using the protocol.
222
223       By default, libcurl prohibits redirects to file:// URLs.
224

What if the user can set the URL

226       Applications  may find it tempting to let users set the URL that it can
227       work on. That's probably fine, but opens up for mischief  and  trickery
228       that  you  as an application author may want to address or take precau‐
229       tions against.
230
231       If your curl-using script allow a custom URL do you also, perhaps unin‐
232       tentionally,  allow  the user to pass other options to the curl command
233       line if creative use of special characters are applied?
234
235       If the user can set the URL, the user can also specify the scheme  part
236       to  other protocols that you didn't intend for users to use and perhaps
237       didn't consider. curl supports over 20 different URL schemes. "http://"
238       might be what you thought, "ftp://" or "imap://" might be what the user
239       gives your application. Also, cross-protocol operations might  be  done
240       by  using  a particular scheme in the URL but point to a server doing a
241       different protocol on a non-standard port.
242
243       Remedies:
244
245       Use --proto
246              curl command lines can use --proto to limit what URL schemes  it
247              accepts
248
249       Use CURLOPT_PROTOCOLS
250              libcurl  programs can use CURLOPT_PROTOCOLS(3) to limit what URL
251              schemes it accepts
252
253       consider not allowing the user to set the full URL
254              Maybe just let the user provide data for parts of it?  Or  maybe
255              filter input to only allow specific choices?
256

RFC 3986 vs WHATWG URL

258       curl  supports  URLs  mostly  according  to how they are defined in RFC
259       3986, and has done so since the beginning.
260
261       Web browsers mostly adhere to the WHATWG URL Specification.
262
263       This deviance makes some URLs copied between browsers (or returned over
264       HTTP  for redirection) and curl not work the same way. This can mislead
265       users into getting the wrong thing, connecting to  the  wrong  host  or
266       otherwise not work identically.
267

FTP uses two connections

269       When  performing an FTP transfer, two TCP connections are used: one for
270       setting up the transfer and one for the actual data.
271
272       FTP is not only un-authenticated, but the  setting  up  of  the  second
273       transfer is also a weak spot. The second connection to use for data, is
274       either setup with the PORT/EPRT command that makes the  server  connect
275       back  to  the client on the given IP+PORT, or with PASV/EPSV that makes
276       the server setup a port to listen to and tells the client to connect to
277       a given IP+PORT.
278
279       Again, un-authenticated means that the connection might be meddled with
280       by a man-in-the-middle or that there's a malicious server pretending to
281       be the right one.
282
283       A malicious FTP server can respond to PASV commands with the IP+PORT of
284       a totally different machine. Perhaps even a third party host, and  when
285       there  are many clients trying to connect to that third party, it could
286       create a Distributed Denial-Of-Service attack out of it! If the  client
287       makes  an  upload  operation,  it  can make the client send the data to
288       another site. If the attacker can affect what data the client  uploads,
289       it  can  be made to work as a HTTP request and then the client could be
290       made to issue HTTP requests to third party hosts.
291
292       An attacker that manages to control curl's  command  line  options  can
293       tell curl to send an FTP PORT command to ask the server to connect to a
294       third party host instead of back to curl.
295
296       The fact that FTP uses two connections makes it  vulnerable  in  a  way
297       that is hard to avoid.
298

Denial of Service

300       A  malicious  server could cause libcurl to effectively hang by sending
301       data very slowly, or even no data at all but just keeping the TCP  con‐
302       nection  open.   This  could  effectively result in a denial-of-service
303       attack.  The   CURLOPT_TIMEOUT(3)   and/or   CURLOPT_LOW_SPEED_LIMIT(3)
304       options can be used to mitigate against this.
305
306       A  malicious  server could cause libcurl to download an infinite amount
307       of data, potentially causing all of memory or disk to be  filled.  Set‐
308       ting the CURLOPT_MAXFILESIZE_LARGE(3) option is not sufficient to guard
309       against this.  Instead, applications should monitor the amount of  data
310       received within the write or progress callback and abort once the limit
311       is reached.
312
313       A malicious HTTP server could cause an infinite redirection loop, caus‐
314       ing  a  denial-of-service.  This  can  be  mitigated  by using the CUR‐
315       LOPT_MAXREDIRS(3) option.
316

Arbitrary Headers

318       User-supplied data must be sanitized when used  in  options  like  CUR‐
319       LOPT_USERAGENT(3),   CURLOPT_HTTPHEADER(3),  CURLOPT_POSTFIELDS(3)  and
320       others that are used  to  generate  structured  data.  Characters  like
321       embedded  carriage returns or ampersands could allow the user to create
322       additional headers or fields that could cause malicious transactions.
323

Server-supplied Names

325       A server can supply data which the application may, in some cases,  use
326       as  a  file  name.  The curl command-line tool does this with --remote-
327       header-name, using the Content-disposition: header to generate  a  file
328       name.   An application could also use CURLINFO_EFFECTIVE_URL(3) to gen‐
329       erate a file name from a server-supplied  redirect  URL.  Special  care
330       must  be  taken  to  sanitize  such names to avoid the possibility of a
331       malicious server supplying  one  like  "/etc/passwd",  "\autoexec.bat",
332       "prn:" or even ".bashrc".
333

Server Certificates

335       A  secure  application  should  never use the CURLOPT_SSL_VERIFYPEER(3)
336       option to disable certificate validation. There  are  numerous  attacks
337       that  are enabled by applications that fail to properly validate server
338       TLS/SSL certificates, thus enabling  a  malicious  server  to  spoof  a
339       legitimate  one. HTTPS without validated certificates is potentially as
340       insecure as a plain HTTP connection.
341

Report Security Problems

343       Should you detect or just suspect a  security  problem  in  libcurl  or
344       curl,   contact   the  project  curl  security  team  immediately.  See
345       https://curl.haxx.se/dev/secprocess.html for details.
346

Showing What You Do

348       Relatedly, be aware that in situations  when  you  have  problems  with
349       libcurl and ask someone for help, everything you reveal in order to get
350       best possible help might also impose certain  security  related  risks.
351       Host names, user names, paths, operating system specifics, etc. (not to
352       mention passwords of course) may in fact be used by intruders  to  gain
353       additional information of a potential target.
354
355       Be  sure to limit access to application logs if they could hold private
356       or security-related data.  Besides the  obvious  candidates  like  user
357       names and passwords, things like URLs, cookies or even file names could
358       also hold sensitive data.
359
360       To avoid this problem, you must of course use your common sense. Often,
361       you  can  just  edit out the sensitive data or just search/replace your
362       true information with faked data.
363
364
365
366libcurl 7.69.1                   July 16, 2019             libcurl-security(3)
Impressum