В апреле 2021 года Microsoft анонсировала новую версию своей IDE – Visual Studio 2022, попутно объявив, что она будет 64-битной. Сколько мы этого ждали — больше никаких ограничений по памяти в 4 Гб! Однако, как оказалось, есть нюансы... Кстати, если вы пропустили, вот ссылка на тот пост с анонсом. Но вернёмся к нашему вопросу из заголовка. Я воспроизвёл эту проблему на последней доступной на момент написания заметки версии Visual Studio 2022 Preview — 17.0.0 Preview 3.1. Для воспроизведения достаточно: После этого в созданный XML-файл нужно попробовать скопировать следующий текст: Теперь идём заваривать кофе, возвращаемся и наблюдаем за тем, как Visual Studio отжирает всё больше и больше ОЗУ.  Могут возникнуть 2 вопроса: Что ж, давайте разбираться. Для этого нам нужно будет вспомнить, какие опасности может нести неаккуратная обработка XML-файлов, а также узнать, как со всем этим связан статический анализатор PVS-Studio. Мы продолжаем активно развивать PVS-Studio как SAST решение. Если говорить про C# анализатор, то основной фокус по этому фронту – поддержка OWASP Top 10 2017 (последняя доступная на данный момент версия – с нетерпением ждём обновления). К слову, если вы пропустили, не так давно мы добавили taint анализ, о чём можно почитать здесь. Собственно, для тестирования работы анализатора я и создал (точнее, попытался создать) соответствующий синтетический проект. Дело в том, что одна из категорий OWASP Top 10, над которой сейчас ведётся работа, – A4:2017-XML External Entities (XXE). Она затрагивает уязвимость приложений к различным атакам посредством неправильной обработки XML-файлов. Что подразумевается под неправильной обработкой? Например, излишнее доверие к входным данным (извечная проблема многих уязвимостей) и отсутствие должных ограничений в парсерах XML.  В итоге, если файлы окажутся скомпрометированы, это может вылиться в разные неприятные последствия. Здесь можно выделить 2 основные проблемы: раскрытие каких-то данных и отказ в обслуживании. Обе имеют соответствующие CWE: CWE-611 оставим на другой раз, сегодня нас интересует CWE-776. Я поясню только основную суть проблемы. Если у вас есть желание изучить проблему глубже – топик легко гуглится, не обессудьте. Стандарт XML предусматривает использование DTD (document type definition). DTD даёт возможность использовать так называемые XML-сущности. Синтаксис определения сущностей прост: Получить значение сущности в дальнейшем можно следующим образом: Нюанс состоит в том, что сущности могут раскрываться не только в строки (как в нашем случае — "Entity value"), но и в последовательности других сущностей. Например: В итоге при раскрытии сущности 'lol1' мы получим строку следующего вида: Можно пойти дальше и определить сущность 'lol2', раскрыв её уже через 'lol1': Тогда при раскрытии одной лишь сущности 'lol2' мы получим следующий выхлоп: Погрузимся на уровень ниже и определим сущность 'lol3'? Выхлоп при её раскрытии: Собственно, сгенерированный по такому принципу XML-файл мы и использовали в начале статьи. Думаю, теперь понятно, откуда название "billion laughs". Получается, что если XML-парсер настроен неправильно (обрабатывает DTD и не имеет ограничений на максимальный размер сущностей), то при обработке подобной 'бомбы' ничего хорошего не случится. Если говорить про C#, уязвимый код проще всего продемонстрировать на примере типа XmlReader: Сконфигурировав экземпляр XmlReader подобным образом, вы как бы говорите злоумышленнику этим кодом: "Давай, подорви меня!". Причины две: По умолчанию, кстати, обработка DTD сущностей запрещена: свойство DtdProcessing имеет значение Prohibit, а на максимальное количество символов из сущностей стоит ограничение (начиная с .NET Framework 4.5.2). Так что в современном .NET всё меньше возможностей прострелить себе ногу. Хотя при неаккуратном конфигурировании парсеров это всё ещё возможно. Похоже, что в Visual Studio 2022 при копировании нашей XML бомбы сработали как раз оба условия: Если посмотреть, что происходит в процессе в это время, можно найти подтверждение нашим предположениям.  В списке потоков видно, что основной поток как раз обрабатывает XML. К слову, из-за этого повис весь GUI и IDE никак не реагировала на попытки потыкать её палочкой. Если посмотреть call stack потока VS Main, можно увидеть, что он как раз занят обработкой DTD (исполняется метод ParseDtd).  В ходе экспериментов у меня возник вопрос: а зачем Visual Studio вообще запускает процессинг DTD, почему просто не отображает XML как есть? Ответ пришёл в ходе экспериментов с 'XML-бомбочкой' (суть та же, но нагрузка поменьше). Похоже, всё дело в том, чтобы отображать в редакторе "на лету" возможные значения сущностей.  Небольшие значения обрабатываются успешно, но разрастание XML приводит к проблемам. Конечно, такая проблема не могла обойтись без написания мной баг-репорта. Вот так неожиданным образом удалось посмотреть, как на практике могут выглядеть уязвимости к XML-бомбам. Самое интересное, что удалось пощупать это не на каком-то абстрактном примере, а на вполне знакомом и популярном приложении. Мы планируем добавить поиск кода, уязвимого к проблемам обработки XML-файлов, в PVS-Studio 7.15. Если же интересно посмотреть, что анализатор умеет уже сейчас, предлагаю загрузить его и попробовать на своих проектах. ;) Как всегда, приглашаю подписываться на мой Twitter, чтобы не пропустить ничего интересного. Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Sergey Vasiliev. How Visual Studio 2022 ate up 100 GB of memory and what XML bombs had to do with it. Независимый эксперт