I currently have several update scripts that I run periodically, which use curl to pull and install updates from various places. In my current configuration however, I have curl blocked by my firewall, and must manually allow it each time I run these scripts. Life would be simpler if I could just always allow curl from my machine (at least to a few specific sites like github.com, over http and https). Is there any reason not to allow this? Are there potential insidious side-effects to running curl this way?

  • Are you blocking curl specifically? How does that work - does it inspect http requests and filter by user agent? – Xiong Chiamiov Feb 4 '17 at 15:17
  • @XiongChiamiov: Using Little Snitch. – orome Feb 4 '17 at 15:20
  • Oh, so it's a local software firewall, not a dedicated hardware firewall. That means that when you say "allow curl", you're probably allowing curl, the command-line utility, because the firewall manages exclusion rules via process name. – Xiong Chiamiov Feb 4 '17 at 16:56

Well, it's possible that curl contains a yet-undiscovered flaw, such as a buffer overflow, and that a carefully crafted site out there might put up data that, when pulled with curl, would run malicious code on your machine with the rights of the user that ran curl.

Depending on how isolated your machine is, opening up a hole in your firewall for curl could lead to another, malicious process on your machine using the same firewall hole to extract data from your machine and upload it to one of the sites curl was allowed to connect to.

The first scenario is unlikely, but within the realm of the possible. The second scenario assumes your machine is highly isolated and you're worried about secrets being extracted from it. In that case, it probably shouldn't be connected to the internet at all, so scenario two is probably not really relevant.

If you're talking about a normal desktop machine, I wouldn't worry about curl.

Updated to answer your comment: A correctly functioning curl itself which was under your control wouldn't send arbitrary data out. But if I managed to install a malicious program on your machine, I could then tell it to use curl to post data I stole from your machine to one of the sites that you allowed curl to connect to.

The technical explanation for this is that curl sends an HTTP request and receives the answer in an HTTP Response. An HTTP request can contain arbitrary data; this is how HTTP is designed. If you only want to allow very specific HTTP requests, you'll have to configure your firewall to use deep packet inspection to block everything but white-listed HTTP requests.

Even that will not be enough to be perfectly safe, since once there is a hole in your firewall, another process might mimick curl and send out information using a covert channel (such as sending out information not in the actual bytes it sends, but in the frequency of the requests).

However, you probably don't have to worry about such attacks unless you're doing very important or very secret work that might interest state-level adversaries.

  • Let's set aside potential flaws in curl itself, and assume it is properly functioning. If I understand what you're saying: even then it's entirely possible that (without knowing more) a request to use curl to connect to a site over HTTP could easily mean that it's taking arbitrary data from my machine and transferring it to that site? I'd have no way of knowing without some understanding of how curl was being invoked? – orome Feb 4 '17 at 13:21
  • Thanks for your edit. In my case most of my curl invocations will be either under my control (that is in scripts where I've written the invocation, or at direct command line entry). But the most frequent one is actually embedded somewhere in my Homebrew update invocations (brew ...), and I don't know what those are doing. – orome Feb 4 '17 at 13:42

The curl project consists of two parts. First, there is libcurl, which is a C library that handles making network requests of many sorts (including http). Then there is curl, the command-line utility that's built on top of libcurl.

Libcurl is extremely widely used. There is a long list of applications using it that isn't remotely close to complete. (There is a similarly large and incomplete list of companies using libcurl as well.) Even for people who don't use it directly, it forms the basis of most popular http request libraries. The home page has this to say:

curl is used in command lines or scripts to transfer data. It is also used in cars, television sets, routers, printers, audio equipment, mobile phones, tablets, settop boxes, media players and is the internet transfer backbone for thousands of software applications affecting billions of humans daily.

The point here is that blocking curl is going to prevent most software that uses the network from working properly.

Now, why is there a built-in setting (I'm guessing) for this on your firewall? Worms like to spread, Trojans like to poke backdoors, botnets like to contact control servers, attackers like to exfiltrate (that is, steal) private data, and all these things have a reasonable chance of using curl. This isn't because curl is popular among hackers, but because curl is popular among programmers. So will blocking curl help prevent these sorts of attacks? Possibly, although depending on how it's implemented it's probably pretty easy to get around. And keeping that setting turned on is also probably going to cause you major headaches. It doesn't seem worthwhile except in a very locked-down environment, in which you probably want to just whitelist the allowed connections.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.