Заплатка для процессора. Защита от кибератак может замедлить работу компьютеров

Заплатка для программы исправляет ошибки в коде

Фото Thomas Trutschel / Photothek via Getty Images

Новый 2018 год начался с сообщений об уязвимостях Meltdown и Spectre, которые потенциально позволяют злоумышленнику украсть информацию, используя особенности работы процессора. Производители начали предлагать обновления программного обеспечения, но решат ли они проблему полностью?

Сложность современных микросхем уже настолько велика, что сообщения об обнаружении аппаратных ошибок в процессорах в профессиональной среде перестали восприниматься как нечто экстраординарное. Например, для процессора Intel последнего поколения их обнаружено уже 103.

Однако обычно злоумышленнику не представляется возможным использовать их для атаки: «багов» может быть много и почти всегда они не касаются безопасности. Напомню, что одна из первых широко известных ошибок в процессорах Intel была связана с операцией деления: при определенных условиях процессор возвращал неверный результат. В общем есть ошибки, которые не могут быть использованы для кибератаки, а есть те, которые позволяют злоумышленнику воровать данные. Последних немного, к тому по мере выявления проблем конкретного чипа производитель выпускает документы, в которых кратко описывает, в чем собственно заключается проблема и как ее можно решить. Исправляются они чаще всего написанием дополнительного программного кода, который не столько устраняет ошибку, сколько делает ее невидимой конечному пользователю.

К сожалению, Meltdown и Spectre — другой случай. Если коротко описать ситуацию, то с точки зрения компьютера все программы представляют собой последовательность процессорных инструкций, которые выполняются поочередно, одна за одной. В погоне за производительностью в процессоры AMD, Intel, IBM, а также чипы с ARM-архитектурой (используется в смартфонах и планшетах, например в iPhone), разработчики добавили блоки, которые пытаются предугадать поведение программы и заранее выполнить требуемую операцию. Они меняют порядок исполнения инструкций и производят так называемое спекулятивное выполнение (Speculative execution). Таким образом, процессор пытается «подстроиться» под конкретную программу, если ему это не удается и результат выполнения не является корректным, произведенные действия отменяются.

Но, как выяснили исследователи Google Project Zero, Cyberus Technology, и Технического университета Граца, при неудачной попытке угадать отменяются не все действия, что позволяет получить первоначальные данные одной программы из другой, которая на доступ к ним права не имеет, но может угадать (получить) их по ряду косвенных признаков (например, по времени доступа) в ходе так называемой атаки по сторонним каналам.

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

Обновления решили не все проблемы

Конечно, разные производители по-разному реализуют процесс спекулятивного выполнения с алгоритмической точки зрения. Но в совокупности обе уязвимости — Meltdown и Spectre — используют особенности реализации таких механизмов и в итоге позволяют получить практически любые данные. Уязвимости Meltdown, позволяющей читать память ядра операционной системы, подвержены ARМ-процессоры и продукция компании Intel. Эта уязвимость была исправлена в операционных системах Windows, Linux, MacOS, iOS программным способом: в ходе обновления весь код пользовательских приложений полностью отделили от ядра ОС.

К сожалению, привычный путь установки программных заплаток может сопровождаться ощутимыми потерями производительности (в некоторых случаях до 30%) и затрагивает ключевые элементы ОС (например, управление памятью). Это чревато проблемами при установке, например, антивирусных программ, или в принципе некорректной работой ПК.

Spectre сложнее реализовать на практике, но ее и ликвидировать программными методами сложнее. Это связано с тем, что разработчики, устраняя данную уязвимость, будут вынуждены вручную внедрять специальные инструкции во все программы, для которых утечка данных может быть критична.

Пора ли беспокоиться?

Meltdown и Spectre, с одной стороны, позволяют только читать данные из оперативной памяти компьютера и злоумышленник не может перехватить управление компьютером жертвы с их помощью. Однако эти уязвимости можно использовать для обхода одной из технологии защиты от взлома — ASLR (address space layout randomization), при которой программы грузятся в регионы памяти по случайным адресам, которые не известны атакующему.

Под обе уязвимости уже выпущены обновления, но только для основных пользовательских операционных систем: Windows, Linux, MacOS, iOS. Пока их нет для ряда серверных операционных систем (таких, например, как FreeBSD). Учитывая риски потери производительности, разработчики Windows и Linux предусмотрели возможность отключать защиту от этих уязвимостей и скорее всего часть пользователей будет использовать эту возможность. Причина проста: в некоторых условиях (масштаб парка обновляемых машин, специфика их использования и т. п.) просадка производительности каждой машины складывается существенные потери для бизнеса или производства. Также нельзя забывать и об общей статистике, иллюстрирующей недостаточную внимательность пользователей к своевременной установке рекомендуемых производителями обновлений в принципе. Исследование нашей компании в 2016 году показало, что 82% проверенных корпоративных информационных систем использовали уязвимые версии ПО, в 64% — уязвимые версии веб-серверов, а в 18% хакеры могли воспользоваться ошибками в устаревших версиях веб-приложений.

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

Фатальный сюрприз под аппаратным капотом

Тем не менее Meltdown и Spectre, о которых в последние дни говорят и пишут многие, — всего лишь часть айсберга, который мы называем «аппаратные атаки».

Это новая тенденция, которая быстро набирает обороты последние 2 года — потенциальное использование злоумышленниками аппаратных уязвимостей. Полагаю, что это вызвано в том числе и несформировавшимися правилами и требованиями к безопасности низкоуровневого кода и аппаратных платформ. Только за последний год исследователями было опубликовано несколько уязвимостей в конструкции чипов, от которых невозможно полностью защититься.

Например, в декабре прошлого года на конференции Black Hat Europe было представлено исследование уязвимости в технологии Intel Management Engine, открывающей доступ потенциальному злоумышленнику к любому компьютеру, ноутбуку, мобильному устройству, где есть процессор Intel поколения Skylake или более позднего — это миллионы устройств по всему миру. Через Intel Management Engine злоумышленник может получить доступ к изображению на экране, клавиатуре и мышке (вне зависимости от используемой операционной системы). При этом такой «захват» происходит совершенно незаметно для средств защиты, установленных в операционной системе. Причем такой зловредный код настолько «живуч», что даже полное форматирование диска и/или полная переустановка системы не окажут на него сколько нибудь значимого влияния.

Да, пока мы не зафиксировали ни одного случая такого взлома, выполненного «плохими парнями» (история ограничилась работой исследователей безопасности в рамках официального сотрудничества с Intel). Но опыт показывает, что это всего лишь вопрос времени.

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

10 полезных советов для отладки и устранения неполадок в программировании

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

Ваш набор инструментов для борьбы с ошибками

1. Оператор печати

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

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

2. Отладчик

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

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

3. Система отслеживания ошибок

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

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

Простой текстовый файл может служить начальной системой отслеживания ошибок для проекта. С ростом объема кода количество ошибок выйдет за рамки текстового файла.

Существует большой выбор систем отслеживания ошибок в программном обеспечении, как коммерческих, так и с открытым исходным кодом. Самым важным критерием в выборе такой системы является доступность для сотрудников-непрограммистов, которым нужно работать с файлом ошибок.

4. Верификация программ

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

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

5. Контроль версий

Также как и использование системы отслеживания ошибок, применение системы контроля версии – это самая лучшая практика в разработке программного обеспечения, которая не может быть игнорирована при разработке любого проекта значительного размера.

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

6. Модульность

Плохо спроектированный код – это главный источник трудно исправляемых ошибок. Если код легко понять, и он может быть « выполнен » в уме или на бумаге, есть большая вероятность, что программисты смогут быстро находить и исправлять ошибки.

Самый лучший способ добиться этого – писать функции, выполняющие что-то одно. А вот участок кода с большим количеством функций имеет большую склонность к возникновению ошибок, которые сложно отслеживать.

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

Например, программист, разрабатывающий систему электронной коммерции, мог бы, рассматривая модуль обработки кредитной карты, видеть, как он связан с остальным кодом, не вдаваясь в детали самой обработки кредитной карты. С другой стороны, детали модуля (в нашем примере того, который занимается обработкой кредитной карты) могут быть рассмотрены и поняты без обращения к не имеющему отношение к этому модулю коду.

7. Автоматизированные тесты

Модульные тесты и другие типы автоматизированных тестов идут рука об руку с модульным программированием.

Автоматизированный код – это участок кода, который выполняет программу с определенными входными параметрами и проверяет, соответствует ли поведение программы ожидаемому.

Модульные тесты проверяют функционирование отдельных функций или методов класса, в то время как функциональные тесты проверяют специфичное поведение всей программы, а интеграционные тесты проверяют большие части системы или всю систему в целом.

8. Метод «Плюшевый мишка» (или отладка «Резиновая уточка»)

Если верить легендам программирования Брайану Кернигану и Робу Пайку (Brain Kernighan и Rob Pike), отладка по типу «Резиновая уточка» возникла в университетском компьютерном центре, где студенты должны были садиться напротив плюшевого мишки и объяснять ему их ошибки, прежде чем обращаться за помощью к живому человеку.

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

Важной частью этого метода является то, что нужно объяснять код и проблему вслух в простых и понятных терминах. Есть подобная методика, которая также полезна – вести журнал программирования, в который нужно записывать мысли о коде до и после его реализации.

9. Пишите комментарии к коду

Комментарии должны объяснять цель кода на низком уровне. Должна существовать возможность легко ответить на вопросы о том, что строка кода делает и как она это делает, прочитав сам код. Это достигается путем написания читаемого кода, который разработан настолько просто, насколько это возможно, и использует осмысленные имена для функций и переменных.

Комментарии к коду должны заполнять пробелы информации в максимально возможной степени, отвечая на такие вопросы, как: почему используется конкретная реализация, или как данный участок кода взаимодействует с остальной частью программы.

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

10. Пишите документацию

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

Написание документации демонстрирует понимание программной системы, и часто указывает на те части системы, которые не до конца понятны и являются вероятным источником ошибок.

На пути к мастерству: избавляемся от ошибок

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

Какими из этих 10 средств отладки вы пользуетесь сейчас? Какими вы могли бы начать пользоваться с сегодняшнего дня? Какие из этих инструментов требуют времени на практику и освоения новых навыков?

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