1. Обзор

• CVE о SQLite, вероятно, не относятся к вашему использованию SQLite.

• Все исторические слабые места, о которых сообщают в SQLite, требуют по крайней мере одного из этих предварительных условий:

  1. Нападающий может управлять произвольными SQL-операторами.

  2. Нападающий может создать злонамеренно обработанный файл базы данных для приложения, которое откроет и запросит.

• Немного реальных приложений встречают любое из этих предварительных условий, и следовательно немного реальных приложений уязвимы, даже если они используют более старые и неисправленные версии SQLite.

• Группа разработчиков SQLite исправляет ошибки быстро, обычно в течение часов после открытия. Новые выпуски SQLite выпущены, если ошибка кажется вероятно способной повлиять на реальные приложения.

• Хакеры вознаграждены на основе числа и серьезности CVE, которые они находят. Это приводит к быстрому увеличению CVE, которые оказывают незначительное влияние или никакого вообще, но которые предъявляют преувеличенные претензии воздействия.

• Очень немного CVE в SQLite являются реальными слабыми местами в том смысле, что они не дают новых возможностей нападабщему. Рассмотрите:

  1. Почти все CVE требуют способности ввести и управлять произвольным SQL.

  2. Рекламируемое последствие большей части CVE это "denial of service", как правило вызывая катастрофу через NULL, деление на нуль или подобное.

  3. Но если нападающий уже может управлять произвольным SQL, ему не нужна ошибка, чтобы вызвать отказ в обслуживании. Есть много совершенно законных и правильных SQL-операторов, которые будут потреблять неограниченный CPU, объем памяти и дисковый I/O, чтобы создать отказ в обслуживании, не требуя помощи ошибок.

  4. Следовательно, просто то, что у нападающего есть способ ввести и управлять произвольным SQL, уже дает возможность для denial-of-service. То, что произвольный SQL мог бы также использовать ошибку в SQLite и вызвать катастрофу, не является новой уязвимостью.

• Разработчики SQLite не пишут CVE. Любые CVE, которые вы находите на SQLite, произведены третьими лицами, часто без любой связи с основнми разработчиками. Общий сценарий: кто-то сообщит об ошибке в SQLite, которая будет быстро исправлена, затем несколько недель спустя, CVE для той ошибки будет опубликован без ведома разработчиков.

• Вы не должны предполагать, что CVE о SQLite содержит достоверную информацию. CVE часто содержат погрешности. Разработчики SQLite попытались добавить разъяснения и исправления.

2. О CVE

CVE ("Common Vulnerabilities and Exposures") являются сообщениями о программных ошибках, которые могли бы позволить системе быть взломанной. Идея CVE здравая. Они предоставляют общую схему именования, посредством чего программные ошибки, которые могли бы поставить под угрозу информационную безопасность, могут быть легко прослежены.

В то время как оригинальная идея CVE здравая, текущие процессы для создания и управления CVE несоответствующие. Есть бесчисленные хакеры, работающие против большого разнообразия продуктов программного обеспечения с открытым исходным кодом (SQLite, а также многие другие) и описывающие CVE для любых проблем, которые они находят. Они вознаграждены, иногда престижем, иногда в финансовом отношении, числом и серьезностью CVE, которые они пишут. Этот стимул приводит к быстрому увеличению CVE, которые часто не исследуются толком и могли преувеличить воздействие. Процедуры контроля качества CVE неспособны справиться с этим наводнением, мешая исправлять преувеличенные, вводящие в заблуждение, пропущенные или неточные требования.

Нельзя сказать, что CVE бесполезны. CVE действительно все еще (главным образом) сообщают о фактических ошибках. Но в большинстве случаев ошибки не истино слабые места в том смысле, что они не способствуют потере данных. Хорошо, что об ошибках сообщают. Но не каждая ошибка доступна от любого применения. В случае SQLite большинство ошибок, сообщенных CVE, недоступно в большинстве ситуаций. Модернизация до последней версии SQLite всегда хороший план, но это не должно быть чрезвычайной ситуацией просто потому, что анонимный хакер в Интернете описал CVE.

2.1. Отдельная защита от внедрения SQL обычно требуется

Другие C-библиотеки, которые обрабатывают комплексные структурированные входы, будут обычно иметь дело с неисследуемыми входами из источников, которым не доверяют. Таким библиотекам, как libjpeg, libzip или OpenSSL, вручают входные потоки, которые прибывают непосредственно от потенциально враждебных агентов.

Скрипты SQL, которые передаются в SQLite, прибывают из самого приложения которому доверяют, а не от нападающего. Иногда приложения содержат ошибки, которыми внешний нападающий может обмануть приложение и обеспечить отправку нужного SQL в ядро базы данных. Это отдельная ошибка в приложении, названная SQL Injection. Так как текст на SQL это исполняемый код, уязвимость внедрения SQL на самом деле особый случай Remote Code Execution (RCE) vulnerability. Внедрения SQL, возможно, не совсем так же плохи, как другие виды RCE потому что, в то время как SQL сильный язык, это не столь удобно для обработки действий, как Python или машинный код. Тем не менее, внедрение SQL это серьезная проблема.

Большинство CVE, написанных о SQLite, предполагает, что нападающий в состоянии управлять произвольным SQL в SQLite. В большинстве случаев это означает, что должна сначала быть уязвимость внедрения SQL, которая позволяет нападающему вводить злонамеренный SQL.

Несколько приложений действительно позволяют скриптам SQL, которым не доверяют, полученным от потенциально враждебных агентов, быть запущенными прямо в SQLite. Главный пример этого веб-браузеры Chrome и Safari, которые позволяют анонимной веб-странице управлять SQL, используя функции WebSQL JavaScript. Это сделано в песочнице с ограничениями, но скрипт может попробовать устроить denial-of-service. Chrome и Safari имеют в распоряжении инфраструктуру, чтобы позволить враждебному агенту управлять кодом, который не вредит или ставит под угрозу остальную часть машины. Они также управляют JavaScript, который, если не управляется жестко, мог бы нанести еще больше ущерба, чем SQL. Кроме Хрома и Сафари, никакие известные разработчикам SQLite приложения не позволяют анонимному отдаленному агенту управлять произвольным кодом на SQL.

Однако большинство CVE, написанные для SQLite, предполагает, что нападающий свободен управлять любым произвольным SQL в ядре базы данных. Таким образом, это означает, что большинство CVE действительны только пока это используется в Хроме и Сафари. Или другими словами большинство CVE для SQLite не относятся к вам, если вы не один из разработчиков Хрома или Сафари.

2.2. Защита против темных умельцев

Большинство приложений может использовать SQLite, не имея необходимости волноваться об ошибках в неясных входах SQL. Если приложение сознательно не пытается сломать SQLite, то все должно просто работать. Не так уж необходимо иметь последнюю исправленную версию SQLite. Любая более старая версия должна работать просто великолепно.

Однако, есть некоторые случаи, где применение действительно должно быть в состоянии безопасно управлять SQL, которому не доверяют. Разработчики SQLite упорно работают, чтобы сделать SQLite безопасным с этой целью, хотя есть случайные ошибки. Хорошо быть в курсе последних новостей в этом случае. Отдельная глава содержит дополнительные предложения, которые могут помочь предотвратить атаки zero-day в случаях, где SQLite дают вводы, которые прибывают непосредственно из источников, которым не доверяют.

2.3. Политика разработчика SQLite по отношению к CVE

Разработчики SQLite исправляют все ошибки в SQLite, как только о них сообщают, обычно в течение нескольких часов. Исправления немедленно доступны в общественном исходном дереве SQLite. Если будет казаться, что ошибка могла бы вызвать проблемы для существующих приложений, новый выпуск с патчем для SQLite будет выпущен.

Однако, разработчики SQLite не отслеживают CVE. Есть различные причины этого:

1. Разработчики часто не узнают о CVE, пока ошибка не исправлена.

2. CVE это низкокачественный источник информации об ошибках в SQLite, которые, вероятно, затронут большинство приложений.

3. Почти все ошибки, сообщенные CVE, являются просто ошибками и не истинными слабыми местами. Утверждение, что они слабые места, просто растягивает значение слова "уязвимость", и разработчики SQLite не хотят участвовать в этом обмане.

4. Разработчики не имеют никакого редакционного влияния на содержание CVE.

3. Статус недавнего SQLite CVE

Хотя разработчики SQLite не полагают, что CVE это надежный источник информации об ошибках в SQLite, они признают, что многие группы и особенно малочисленные команды иногда должны отслеживать CVE, полезны они или нет. Чтобы помочь в этой тяжелой работе, следующая таблица недавних CVE, затрагивающих SQLite, предоставлена.

Если вы замечаете новый CVE, связанный с SQLite, который не находится в приведенной ниже таблице, пожалуйста, сообщите разработчикам на SQLite Forum.