Recently the curl project posted an announcement on Github that there was a severe vulnerability in curl and they would have a fix out in a week. Many people seemed to think that this notice was appreciated and gave people enough time to learn about the issue and know they would have to update in the future. But I’d argue the whole approach curl has taken is ultimately undesirable and put users at risk for no reason.
What is curl?
Curl is both a command-line tool and a library. It’s used widely for working with web requests – though I understand it supports other protocols. Curl is incredibly useful. It’s available on virtually every operating system. Many important projects use its library for working with common Internet protocols. Curl is a ubiquitous tool for today’s technologists.
Why was the notice bad?
When a security issue is found in software it’s common practice to keep knowledge about it internal until it’s fixed. This is done for several reasons:
- It avoids giving attackers knowledge of a vulnerability which they may use to exploit systems before a fix is available.
- It avoids creating unnecessary panic before a fix is out.
- It affords time to get patches out before a release is made.
What curl did was say there was a critical vulnerability while giving stakeholders nothing to protect themselves from it. While they didn’t publish details for a working exploit: for all we know they’ve motivated hoards of attackers to find an exploit and use it. There may also have been parties that already knew about the exploit for years and now they’re motivated to use it.
B-but it gave me time to prepare
People have said that the curl notice was appreciated because it gave affected parties time to prepare for the fix. But I don’t buy that. The reason is the timeframe – 1 week is not long enough to do anything. By saying there’ll be a patch available in a week they’ve forced a mandate on everyone that says ‘everyone currently using curl needs to update within a week or potentially get fuqt (not that severe – guessing it still requires interaction.)’
Unfortunately, it’s going to take time to get the fix out to users. Every distro will have to update packages. Entire tools will need to be written to scan for vulnerable versions of curl. Popular image hosting websites will need to update scores of images (that’s A LOT of builds.) They haven’t given people time to prepare. In fact, by publishing their little notice they’ve robbed them of time since the moment a fix is published in curl it will be possible to reverse-engineer an exploit and most systems still won’t be patched.
So in essence: with this notice they’ve decided on a deadline for all other vendors. Lest they leave their users vulnerable… and the dead line may not be sufficient. I would certainly consider that approach quite amateurish and negligent. A good case-study on how not to handle a security issue.
So what should curl have done?
The correct approach is simple. You privately take as long as you need to and write the fix FIRST. You privately message trusted parties at various mailing lists that include curl in their distros to coordinate the availability of a patched package on a certain date. You could also work with version control companies and image hosts to let them update tools to scan for vulnerable versions of curl and you wouldn’t even have to share the exploit specifics in such a scenario. THEN you write the notice… WITH a patch available.
People have pointed out the above already. But apparently having a different opinion to curls circle-jerk of spastics is considered trolling to them. Ironically, their very own security program asks that researchers report security problems privately. What a fucking joke. I think it’s safe to say you can ignore that.