Источник - Хабрахабр

На волне новостей чип-апокалипсиса 2018 года, когда взломано почти всё, а сайты мировых брендов, сами того не подозревая, майнят в наших браузерах криптовалюту, мы решили покуситься на святая святых и взломать документы, подписанные усиленной квалифицированной электронной подписью. И вот что из этого вышло.

Как известно, усиленная квалифицированная электронная подпись (ЭП) позволяет определить лицо, подписавшее документ, и обнаружить факт внесения изменений в документе (см. ст. 5, п. 3 Федерального закона № 63 «Об электронной подписи»). Алгоритм генерации коллизий хеш-функции в этот раз нам не понадобится. Для взлома надо найти способы внесения изменений в электронный документ после его подписания, так, чтобы эти изменения не были обнаружены при проверке ЭП. Начнём.

Сценарий с документом DWG, вектор атаки — внешние ссылки

Здесь и далее предполагается, что в системе уже установлен сертификат квалифицированной электронной подписи:

• Создаём документ HVAC.dwg, который ссылается на файл nothing.dwg, расположенный на шаре в локальной сети предприятия. Файл nothing.dwg содержит выноски на оборудование Поставщика А;

• Отправляем HVAC.dwg на согласование ответственному лицу;

• С помощью программы «Autodesk→AutoCAD→Добавление цифровых подписей» ответственное лицо подписывает HVAC.dwg. Теперь это электронный подлинник:

Реализуем атаку:

• Нужно заменить оборудование Поставщика А на оборудование Поставщика Б изменением nothing.dwg, расположенного на сетевом ресурсе;

• Отдел снабжения получает электронный подлинник HVAC.dwg, руководитель отдела проверяет целостность электронной подписи, она не нарушена, а AutoCAD развеивает последнюю тень сомнения успокаивающей надписью «Чертеж не изменился с момента подписания», поэтому вместо Поставщика А заказ на оборудование уходит к Поставщику Б

Сценарий с документом DOC/DOCX, вектор атаки — шрифт

В этот раз будем использовать наиболее продвинутый комплекс защиты информации КриптоПро CSP 4.0, соответствующий стандарту ГОСТ Р 34.10-2012:

• Создаём приказ о премировании сотрудников prikaz.docx. Основной текст набираем шрифтом Arial. Для размера премии используем похожий шрифт, например, бесплатный Noto Sans Regular от Google. Вводим согласованный с директором размер премии 150 000 руб.;

• Устанавливаем шрифт Noto Sans Regular на компьютер директору и бухгалтеру (понадобятся права администратора);

• Отправляем приказ на подпись директору;

• Директор подписывает prikaz.docx усиленной квалифицированной ЭП с помощью КриптоПро Office Signature 2.0. Получаем электронный подлинник:

Реализуем атаку:

• С помощью бесплатной программы FontForge модифицируем файл шрифта NotoSans-Regular.ttf, заменив векторное изображение глифа 1 на изображение глифа 2

• Модифицированный NotoSans-Regular.ttf файл заменяем на компьютере бухгалтера [и ждём премию];

• Получив подписанный директором подлинник приказа, бухгалтер открывает его и видит действительную подпись. Но размер премии увеличился со 150 000 руб. до 250 000 руб. Здесь важно знать меру, можно было заменить 1 на 9, но это будет слишком заметно.

Это эффективные, но не единственные способы атаки. Есть еще макросы, вычисляемые значения полей, стили. Не защитит от них ни использование системы управления данными (PDM), ни откреплённые подписи, ни применение специализированных криптографических комплексов типа КриптоПро CSP.

Как же обеспечить защиту от такого рода атак? Самый эффективный способ — публиковать документы в нередактируемый формат или формат фиксированной разметки. Эти форматы нацелены на сохранение первоначального вида документа на любом устройстве, в любой точке мира. Вот наиболее распространённые представители форматов фиксированной разметки:

• PDF (Portable Document Format) — разработан компанией Adobe. Стандарт ISO 32000;

• XPS (XML Paper Specification) — разработан компанией Microsoft. Стандарт ECMA-388;

• DWFx — разработан компанией Autodesk. Основан на XPS.

Но и здесь не всё так однозначно. Попробуем провести атаку через шрифт на подписанный PDF-документ:

• Документ prikaz.docx опубликуем в PDF, например, с помощью виртуального принтера PDF-XChange. Полученный файл prikaz.pdf отправляем на подпись директору;

• Директор открывает документ prikaz.pdf в программе Adobe Acrobat Reader DC;

• Подписывает командой "Поставить цифровую подпись" в разделе "Сертификаты".

• Подписанный PDF отправляется бухгалтеру.

Реализуем атаку:

• Так же как и в сценарии с форматом DOCX устанавливаем бухгалтеру модифицированный шрифт NotoSans-Regular.ttf;

• Получив подписанный prikaz.pdf, бухгалтер открывает его в Adobe Reader и видит размер премии 250 000 руб., целостность подписи при этом не нарушена

Для PDF удалось реализовать данный вид атаки потому, что этот формат допускает использование шрифтов по ссылке, поэтому он не подходит для создания подлинников.Существует стандарт PDF/A (подмножество PDF), который обеспечивает необходимую защиту. Поэтому перед подписанием каждого PDF необходимо убедиться, что документ соответствует стандарту PDF/A или отсутствуют зависимости от шрифтов.

Форматы DWFx и XPS не подвержены такого рода атакам, так как на уровне стандарта ECMA-388 регламентируется хранение ресурсов внутри содержательной части документов (F.3.1 M2.6). Но DWFx не подходит для создания многостраничных текстовых документов, поэтому наиболее универсальным вариантом является XPS.

Попробуем по аналогии с PDF провести атаку через шрифт на подписанный XPS-документ:

• Документ prikaz.docx опубликуем в XPS с помощью встроенного в Windows виртуального принтера Microsoft XPS Document Writer. Полученный файл prikaz.xps отправляем на подпись директору;

• Директор открывает документ prikaz.xps в программе Pilot-ICE или в Pilot-XPS. Подписывает командой «Подписать» через КриптоПро CSP;

• Подписанный XPS отправляется бухгалтеру.

Реализуем атаку:

• Устанавливаем бухгалтеру модифицированный шрифт NotoSans-Regular.ttf;

• Получив подписанный prikaz.xps, бухгалтер открывает его в Pilot-ICE, проверяет целостность ЭП и видит тот же размер премии, который был на момент подписания документа — 150 000 руб. Атака на XPS не удалась.

Итоги

Усиленная квалифицированная электронная подпись по прежнему является надёжной технологией для обнаружения факта внесения изменений в документ. Но следует комплексно оценивать эффективность её применения. Эксперимент показал, что редактируемые форматы DWG, DOC, DOCX не подходят для создания электронных подлинников, так как могут быть легко скомпрометированы. Более защищенными и универсальными для создания подлинников являются форматы PDF/А и XPS, так как они содержат всю необходимую информацию для того, чтобы каждый раз отображать документ в неизменном виде.

Дмитрий Поскребышев

Перевод мнения Джо Фитца относительно январских уязвимостей процессоров

Итак, новая тема! Почему Intel не могут просто быстренько пропатчить уязвимости Meltdown и Spectre, выпустив новую линейку процессоров? Почему процесс может растянуться на годы? Разве они не практикуют agile-методы разработки (если простым языком - постоянное тестирование, параллельная работа групп инженеров и т.п., с возможностью отката проблемных изменений за минимальное время) или методы x/y/z? На самом деле, причин множество:

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

Для начала разберем создание программной начинки процессоров. Первое - каждый раз, когда ты кликаешь "build" ("собрать проект" в программе разработки ), ты создаешь очередной степ, который обходится в миллионы долларов и несколько месяцев тестирования. Чтобы новый продукт оставался финансово выгодным, проект следует собирать не более 10 раз. (Вот тут можно глянуть перечень существующих степпингов от Intel - их реально мало)

Более того, половина тех "билдов" не являются полноуровневыми, т.е. разработчик не может менять логические вентили, их соединения. А при работе со слоем степпинга целиком всё равно нельзя менять расположение элементов по своему усмотрению, как это делают в классическом программировании со связанными библиотеками и другими файлами.

Представьте себе ISA (шина ввода-вывода для IBM-PC компьютеров, индустриальный стандарт), которая поддерживает вызовы и прыжки на расстояние не более 8 бит. Можно двигаться вперед-назад не более, чем на 128 байт от текущего адреса. Ты не можешь просто взять и вставить еще 256 байт кода между двумя существующими блоками микропроцессорного кода без массивной переработки существующей архитектуры с соответствующими потерями таймингов (производительности, с точки зрения пользователя).

Что такое "легкий фикс" на уровне чипа? Изменение бита в паре байтов. Добавление операции инверсии проверки, изменение константы в коде, замена "плохой" инструкции на пустую, правка неверной вычислительной ветки, смена порядка if/else инструкций.

Более крупные изменения наверняка отразятся на всём остальном. Из-за увеличения потребляемой энергии может нагреться соседний вентиль, поэтому придется замедлить операцию, что приведет к общей потере скорости в 100 МГц на всех процессорах серии. А увеличение пространства между элементами приведет к увеличению задержек, с которыми вообще ничего поделать нельзя.

Простейший возможный фикс требует пары месяцев на билд схемы, несколько месяцев на тестирование исправления, плюс регрессионные тесты кода, выпущенного за последние 50 лет - новый процессор обязан поддерживать старые программы. Затем - запуск крупносерийного производства. Скажем, 6 месяцев от фикса до появления на полках.

Но на самом деле, малейшее исправление означает билд, тестирование, прогонку (тюнинг), еще билд, еще тестирование, брендинг и выпуск. Исходя из оптимистичных 2-3 степпингов, выпуск переносится уже с 6 месяцев на один год.

А что насчет новых мелких особенностей (которые планировались к реализации в новых сериях)? Если архитектура и спецификация уже готова, то нужно внедрить всё на уровень логики чипа , провести симуляции, подтвердить работоспособность, и снова прогнать через билд/тестирование/выпуск. Итого уже 2 года.

Реальность такова, что новые фичи крайне опасны, если на них отводится мало этапов тестирования. В кремние заложено ОГРОМНОЕ количество возможностей, для которых еще не пришло время - они могут оставаться заблокированными в течение целых поколений, пока инженеры не решат, что новинка безопасна. На практике большинство новых фич проводят около 5 лет в режиме ожидания, а затем еще и ждут софта, который умеет работать с ними.

Но мы еще не закончили! Атаки Meltdown и Spectre затрагивают фундаментальные особенности архитектуры процессоров, на которой те строились десятилетиями. Взгляните на визуализированный жизненный цикл продукции Intel. Пока что всё происходило в желтой фазе "development".

Предполагая, что в исследованиях рынка мы не нуждаемся, мы просто должны изменить архитектуру, написать новые спецификации, внедрить архитектуру на программном уровне, спроектировать чип и запустить конвейер, а также пройти процедуру подтверждения качества перед стартом продаж. И снова речь идет о 4-5 годах работы.

Что же все это значит? Я предполагаю, что уже этим летом мы увидим пару быстрофиксов на уровне железа. Инженеры компаний знали о проблеме уже полгода на момент публикации информации, и 12 месяцев должно хватить на простейшие исправления. Возможно, фиксы повлияют на производительность, но они всё равно должны оказаться быстрее предлагаемых сейчас решений с уровня софта.

В 2019 и 2020 выходят другие продукты, в которые также должны будут внести соответствующие правки, что непременно скажется на производительности. Тем не менее, опять же, они будут быстрее, чем альтернативы с фиксом через ОС.

А тот самый вариант с решением, которое не снизит производительность, я бы не ждал раньше 2021 года.

Я покинул Intel более 5 лет назад и не в курсе их текущих или грядущих продуктов. Всё это - мои личные предположения, основанные на общих знаниях о процессорах и технологии производства чипов.

Примечание: защита от уязвимостей заключается в сбросе кэша после каждого ветвления кода. На практике падение производительности может достигать и 50%, а может колебаться в пределах 5-10%, в зависимости от задач и кода программы. На Хабре можно почитать и про другие проблемы патчей.

Новости кричат об уязвимостях в архитектуре процессоров и мобильных устройств.

Айфоны тормозят на 30-40% после обновления, исправляющего уязвимость.

И никак ее не исправить софтовым путем без солидного падения производительности

Совпадение?

В последние годы шла стагнация в настольном сегменте процессоров, да и айфоны старые работают вполне неплохо. И бах - а давайте раскроем один из бэкдоров архитектуры и стимулируем продажи новых поколений без уязвимостей? По моему гениально, смысл апгрейда будет в компенсации потерь мощностей ввиду исправления ошибок.