1libcurl-security(3) libcurl security libcurl-security(3)
2
6 libcurl-security - security considerations when using libcurl
7
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 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
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 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
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 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 To avoid these problems, don't use .netrc files and never store pass‐
49 words in plain text anywhere.
50
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 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
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 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 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 Remedies:
82 Restrict operations to authenticated transfers
84 Ie use authenticated protocols protected with HTTPS or SSH.
85 Make sure the server's certificate etc is verified
87 Never ever switch off certificate verification.
88
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 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 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 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 The CURLOPT_REDIR_PROTOCOLS(3) and CURLOPT_NETRC(3) options can be used
115 to mitigate against this kind of attack.
116 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 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
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 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 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 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 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
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
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
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 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 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
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
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 scp://user:pass@host/a;date >/tmp/test;
213 Applications must not allow unsanitized SCP: URLs to be passed in for
215 downloads.
216
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 By default, libcurl prohibits redirects to file:// URLs.
224
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 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 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 Remedies:
244 Use --proto
246 curl command lines can use --proto to limit what URL schemes it
247 accepts
248 Use CURLOPT_PROTOCOLS
250 libcurl programs can use CURLOPT_PROTOCOLS(3) to limit what URL
251 schemes it accepts
252 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
258 curl supports URLs mostly according to how they are defined in RFC
259 3986, and has done so since the beginning.
260 Web browsers mostly adhere to the WHATWG URL Specification.
262 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
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 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 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 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 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 The fact that FTP uses two connections makes it vulnerable in a way
297 that is hard to avoid.
298
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 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 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
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
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
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
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
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 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 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.
363libcurl 7.69.1 July 16, 2019 libcurl-security(3)