Даниэль Стенберг опубликовал анализ первого для проекта curl спора о CVE. В материале он объясняет, почему команда не хотела присваивать идентификатор сообщённой проблеме.

Проект curl является CNA и сам решает, присваивать ли CVE проблемам в своей зоне ответственности. Команда сначала определяет, относится ли отчёт к безопасности, а затем оценивает подтверждённые проблемы по шкале от LOW до CRITICAL с точки зрения curl.

Ошибка затрагивала проверку соответствия имени хоста шаблону wildcard в сертификате и проявлялась для URL с именем хоста, начинающимся с точки. В сборках с TLS-бэкендом семейства OpenSSL или Schannel функция Curl_cert_hostcheck() в этой комбинации ошибочно принимала wildcard-сертификат за соответствующий имени хоста.

Проблему исправили 8 декабря 2025 года и добавили модульные тесты для этого сценария. 24 июня MITRE TL-Root согласился с оценкой curl и решил не присваивать проблеме CVE, поскольку для превращения бага в уязвимость требовался локальный атакующий с привилегиями.

Проверка утверждений:

  • Даниэль Стенберг опубликовал анализ первого для проекта curl спора о CVE и объяснил, почему команда не хотела присваивать идентификатор сообщённой проблеме. (подтверждено первоисточником: доказательство; «Our first ever CVE dispute since we became a CNA reached us on February 10th, 2026 for a report submitted to us two months earlier. The reporter thinks we should have assigned their reported problem a CVE but we think not. Now they want to force the issue to get a CVE anyway, by escalating the situation to MITRE.»)
  • Проект curl является CNA и самостоятельно решает, присваивать ли CVE проблемам в своей зоне ответственности. (подтверждено первоисточником: доказательство; «A few years years ago the curl project signed up and became a CNA . This means that we are masters of and can allocate our own CVE identifiers. For any security problems within our territory, it is we who decides if the issue should get a CVE or not.»)
  • За время работы в статусе CNA команда curl опубликовала 57 уязвимостей с CVE, а получение нового номера сводится для неё к вызову API. (подтверждено первоисточником: доказательство; «During these years we have published fifty-seven separate security vulnerabilities with their associated CVE identifiers. Getting a CVE for an issue is easy and really quickly done when you are a CNA. No hassle, no friction and as we are a small and lean security team it just works as smoothly as you could ask. Just an API call and we have new number.»)
  • Команда сначала определяет, является ли отчёт проблемой безопасности, а подтверждённые проблемы оценивает по шкале LOW, MEDIUM, HIGH или CRITICAL с точки зрения самого curl. (подтверждено первоисточником: доказательство; «For every report we work hard to first assess and decide if the issue is actually a vulnerability or a security problem at all. If we deem that there is a security problem in there, we then grade it into LOW, MEDIUM, HIGH or CRITICAL. Since we don’t know how users use curl or libcurl we cannot take that into account but rather observe and set a severity of the problem from a pure curl point of view.»)
  • Стенберг оценивает распространённость libcurl примерно в 30 млрд установок и поэтому считает, что каждый CVE создаёт значительные издержки на исправления и обновления во всей экосистеме. (подтверждено первоисточником: доказательство; «libcurl is installed in somewhere around thirty billion instances on the globe. If we imagine that at least a sizeable portion of those installs are managed by people who want to make sure they use a secure version, it means that every CVE we publish trigger activities in many security teams all over the world, leading to a significant number of patches and subsequent software updates.»)
  • Спорная ошибка находилась в функции curl, проверяющей соответствие имени хоста шаблону wildcard в сертификате, и проявлялась для URL с именем хоста, начинающимся с точки. (подтверждено первоисточником: доказательство; «The issue is quite technical (of course) but is based on a bug in curl’s function that checks if the used hostname matches a wildcard provided in a certificate. First: the user must use a hostname in a URL with a leading dot, like https://.example.com/»)
  • Имя хоста с ведущей точкой недопустимо в DNS, поэтому для соединения его адрес пришлось бы задавать через /etc/hosts или сходный механизм. (подтверждено первоисточником: доказательство; «This name is not possible to use with DNS (it is an illegal name there), but you can provide an IP address for it in your /etc/hosts file or similar, but still this condition is already making this issue really niche.»)
  • При сборке curl с TLS-бэкендом семейства OpenSSL или Schannel функция Curl_cert_hostcheck() в описанной комбинации ошибочно принимала wildcard-сертификат за соответствующий имени хоста. (подтверждено первоисточником: доказательство; «If curl was built to use an OpenSSL flavor or Schannel for TLS (remember that curl supports many different TLS backends), it then calls the Curl_cert_hostcheck() function to check if the wildcard covers the used hostname. This function had a bug . The above mention combination then erroneously would return TRUE. A match. When in reality it is not a match according to the spec.»)
  • Проблему исправили 8 декабря 2025 года и добавили модульные тесты для этого сценария. (подтверждено первоисточником: доказательство; «We fixed this problem on December 8, 2025 , and we added unit tests for exactly this scenario to make sure that the problem doesn’t come back.»)
  • Команда curl оценила риск как ниже LOW: для эксплуатации требовалось одновременно использовать явно заданное имя с ведущей точкой, подключиться к подконтрольному атакующему хосту с подходящим wildcard-сертификатом и допустить выдачу вредоносных данных из-за неверной проверки. (подтверждено первоисточником: доказательство; «The explicitly set, weirdly dot prefixed name, then needs to connect to a host that has a wildcard set for that same name and an attacker manage to run this impostor host and can now serve the application malicious data because curl did not properly reject the connection because of the wildcard mismatch. A series of highly unlikely conditions that all need to be fulfilled for this to become a vulnerability. A lower than LOW situation. Too unlikely; no CVE.»)
  • 24 июня MITRE TL-Root завершил разбирательство, согласился с оценкой CNA и решил не присваивать проблеме CVE, поскольку для превращения бага в уязвимость требовался локальный атакующий с привилегиями. (подтверждено первоисточником: доказательство; «Based on this review, the MITRE TL-Root has determined that a CVE ID will not be assigned for the reported issue. CNA Determination (Summary): “This is a bug, now fixed in the master branch. It is not considered a security vulnerability because of how it requires a local attacker with privileges present to make it so.” After evaluating the available evidence and the CNA’s assessment, the MITRE TL-Root agrees with this determination and considers the matter resolved.»)

Первоисточники:

оценка 63.5 · тип analysis · ревизия 1 · истории st-oqwpq2