Атака миллиарда смехов

Атака типа «отказ в обслуживании» на XML-парсеры, использующая расширение сущности

В компьютерной безопасности атака «миллиард смеха» — это тип атаки типа «отказ в обслуживании» (DoS) , направленной на парсеры XML - документов. ^[1]

Его также называют XML-бомбой или атакой экспоненциального расширения сущности. ^[2]

Подробности

Пример атаки состоит из определения 10 сущностей, каждая из которых определяется как состоящая из 10 предыдущих сущностей, при этом документ состоит из одного экземпляра самой большой сущности, которая расширяется до одного миллиарда копий первой сущности.

В наиболее часто цитируемом примере первой сущностью является строка " lol ", отсюда и название "billion laughs". На момент первого сообщения об этой уязвимости объем памяти компьютера , используемый миллиардом экземпляров строки " lol ", вероятно, превысил бы объем памяти, доступный процессу анализа XML.

Хотя первоначальная форма атаки была нацелена конкретно на XML-анализаторы, этот термин может быть применим и к схожим объектам. ^[1]

Впервые о проблеме сообщили еще в 2002 году ^[3] , но широкое обсуждение ее началось в 2008 году ^[4].

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

Пример кода

< ? xml  version= "1.0" ? > <!DOCTYPE  lolz  [  <!ENTITY  lol  "lol" >  <!ELEMENT  lolz  ( #PCDATA ) >  <!ENTITY  lol1  "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;" >  <!ENTITY  lol2  "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;" >  <!ENTITY  lol3  "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;" >  <!ENTITY  lol4  "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;" >  <!ENTITY  lol5  "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;" >  <!ENTITY  lol6  "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;" >  <!ENTITY  lol7  "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;" >  <!ENTITY  lol8  "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;" >  <!ENTITY  lol9  "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;" > ]> <lolz > &lol9; </лолз >

Когда XML-анализатор загружает этот документ, он видит, что он включает один корневой элемент, "lolz", который содержит текст "&lol9;". Однако "&lol9;" — это определенная сущность, которая расширяется до строки, содержащей десять строк "&lol8;". Каждая строка "&lol8;" — это определенная сущность, которая расширяется до десяти строк "&lol7;" и так далее. После обработки всех расширений сущностей этот небольшой (< 1 КБ) блок XML фактически будет содержать 10 ⁹ = миллиард "lol", занимая почти 3 гигабайта памяти. ^[5]

Вариации

Описанная выше атака «миллиард смеха» может занять экспоненциальное количество пространства или времени. Квадратичная вариация взрыва вызывает квадратичный рост требований к ресурсам, просто повторяя большую сущность снова и снова, чтобы избежать контрмер, которые обнаруживают сильно вложенные сущности. ^[6] (См. теорию вычислительной сложности для сравнения различных классов роста.)

Атака «миллиард смеха» может существовать для любого формата файла, который может содержать макрорасширения, например, эта YAML- бомба:

a : &a [ "lol" , "lol" , "lol" , "lol" , "lol" , "lol" , "lol" , "lol" , "lol" ] b : &b [ *a , * a , *a , * a , *a , *a , *a , *a ] c : &c [ *b , *b , *b , * b , *b , *b , *b , *b , *b ] d : &d [ *c , *c , *c , *c , *c , * c , *c , *c , *c ] e : & e [ *d , *d , * d , *d , *d , *d , *d , *d , *d ] f : &f [ *e , *e , *e , *e , *e , * e , *e , *e , *e ] g : &g [ *f , *f , * f , *f , *f , *f , *f , *f ] h : &h [ *g , *g , *g , *g , *g , *g , * g , *g , *g ] i : &i [ *h , *h , *h , *h , * h , * h , *h , *h , *h ]                  

Это приводило к сбою более ранних версий Go , поскольку процессор Go YAML (вопреки спецификации YAML) расширяет ссылки так, как будто они являются макросами. Процессор Go YAML был изменен, чтобы не давать парсингу, если объект результата становится слишком большим.

Корпоративное программное обеспечение, такое как Kubernetes, подверглось этой атаке через свой парсер YAML. ^{[7] [8]} По этой причине для данных, поступающих из ненадежных источников, предпочтительным является либо парсер с намеренно ограниченными возможностями (например, StrictYAML), либо форматы файлов, не допускающие ссылок. ^{[9] [ неудавшаяся проверка ]}

Смотрите также

• Fork bomb : аналогичный метод истощения ресурсов системы посредством рекурсии.
• Zip-бомба : аналогичная атака с использованием zip-архивов.
• Атака на внешнюю сущность XML : атака XML для возврата произвольных файлов сервера
• Определение типа документа : шаблон для проверки XML-файлов

Ссылки

1. Гарольд, Эллиот Расти (27 мая 2005 г.). "Совет: настройте парсеры SAX для безопасной обработки". IBM developerWorks . Архивировано из оригинала 5 октября 2010 г. Получено 4 марта 2011 г.
2. Салливан, Брайан (ноябрь 2009 г.). «XML Denial of Service Attacks and Defenses». Журнал MSDN . Корпорация Microsoft . Получено 31 мая 2011 г.
3. "SecurityFocus". 2002-12-16. Архивировано из оригинала 2021-04-16 . Получено 2015-07-03 .
4. "CVE-2003-1564". Распространенные уязвимости и риски . Корпорация MITRE. 2003-02-02 . Получено 2011-06-01 .
5. Брайан Салливан. "XML Denial of Service Attacks and Defenses" . Получено 21.12.2011 .
6. «19.5. Модули обработки XML — документация Python 2.7.18».
7. "CVE-2019-11253: Анализ JSON/YAML сервера API Kubernetes уязвим для атаки на исчерпание ресурсов · Проблема № 83253 · kubernetes/Kubernetes". GitHub .
8. Уоллен, Джек (9 октября 2019 г.). «Уязвимость Kubernetes „Billion Laughs“ — не повод для смеха». The New Stack .
9. «XML — тост, да здравствует JSON». 9 июня 2016 г.