Max Home IndustryИдея о том, что ошибки могут быть полезными, не естественна для большинства программистов — или не должна быть таковой. Ошибки не только приводят к сбою вашей программы, они являются способом для плохих людей проникнуть в ваш код. Может быть, можно было бы использовать больше ошибок, чтобы скрыть действительно опасные ошибки?
Безопасность посредством неизвестности — очень привлекательная идея. Если вы не видите, как что-то работает, или если вас заваливают потенциальными целями, то такой подход делает атаку еще более сложной.
Во время Второй мировой войны кто-то изобрел идею «мякины» — небольших полосок алюминиевой фольги, которые выбрасывались облаком, чтобы обмануть радар. Теперь группа исследователей предположила, что облако «грязных» ошибок может защитить вашу программу от хакеров.
Ключевая идея — это ошибка, которую нельзя использовать. В конце концов, не было бы большого преимущества во вставке ошибок, которые мог бы использовать хакер. Проблема в том, что ошибка по-прежнему должна выглядеть как потенциально уязвимая, чтобы поддерживать интерес хакера. Предполагается, что типичный рабочий процесс хакера состоит в том, чтобы найти ошибки, а затем потратить много времени на выяснение, можно ли использовать ошибку, прежде чем тратить еще больше времени на создание эксплойта с ее использованием. Если вы можете сделать так, чтобы неиспользуемая ошибка выглядела так, как если бы она могла быть эксплуатируемой, тогда вы можете потратить много времени и, возможно, так долго задерживать хакера, что он сдастся.
Худшее, что может сделать ошибка с половиной, — это привести к сбою программы. Ждать! сбой программы — это звучит как настоящая ошибка. Чтобы быть правдоподобным, ошибка с половиной должна казаться опасной, но если она приводит к сбою только части приложения, которое можно легко перезапустить, например, вкладки браузера или потока веб-сервера, тогда сбой не так серьезен, как мог бы. быть, и это могло бы быть приемлемо.
Однако все это звучит сложно.
Исследователи, Чжэнхао Ху, Юй Ху и Брендан Долан-Гавитт, все из Нью-Йоркского университета, имели некоторую фору, используя LAVA, программу, которая сканирует программу C / C ++ и находит места для вставки ошибок переполнения. Я должен сказать, что не знал, что это существует, и, вероятно, не догадался бы, что такое было желательно или даже возможно. Он был создан для создания тестового кода для программного обеспечения для обнаружения ошибок. В газете есть один пугающий комментарий:
«Чтобы действительно вызвать ошибку, LAVA также отмечает точки атаки на трассе, то есть места, где сохраненные данные из DUA могут быть использованы для повреждения памяти. В своей исходной реализации LAVA рассматривает любой аргумент указателя на вызов функции. быть точкой атаки; вместо этого в нашей работе мы создаем новые точки атаки, которые вызывают контролируемое переполнение стека и кучи в произвольных точках программы ».
Обратите внимание: «любой аргумент-указатель на вызов функции должен быть точкой атаки» — gulp … Исследователи также обнаружили, что LAVA может добавлять тысячи ошибок в программу. Большую часть времени мы действительно так близки к нерабочей программе.
Ошибки, внедренные в код, представляли собой ошибки переполнения кучи и стека, которые обычно считаются основным путем к эксплойту программы. Проблему предотвращения использования ошибок было нелегко решить. Одна из основных идей заключалась в том, чтобы при переполнении буфера перезаписывались только те переменные, которые фактически не использовались программой. Это означало управление компоновкой стека и кучи или просто использование того, как конкретный компилятор распределяет память. Этот подход работает только для стека.
Второй метод — ограничить значения переполнения, чтобы остановить выполнение кода. Над этим нужно хорошо подумать, чтобы убедиться, что ошибку нельзя использовать.
Хорошо, так что предположим, что клопы безопасны, как нам скрыть это от злоумышленника?
Два описанных выше метода обезопасить нас от шелушения довольно легко обнаружить. Решение — обфускация. Неиспользуемые переменные должны быть включены в программу, чтобы они выглядели так, как будто они используются, а ограничения на значения должны быть распределены в программе, чтобы их было трудно объединить.
Так это работает?
В статье задаются три вопроса.
Программа работает после добавления ошибок?
Ошибки замедляют работу программы?
Насколько хорошо инструменты поиска ошибок справляются с обнаружением ошибок и считают ли инструменты автоматической сортировки их уязвимыми?
Как нетрудно догадаться, в статье представлены доказательства того, что все работает, как ожидалось. Самым важным результатом является то, что известные инструменты фаззинга обнаружили ошибки, и они были оценены как наиболее пригодные для использования или, вероятно, пригодные для использования. Конечно, у нас не было эскалации инструментов сортировки, которые явно учитывают мусор.
Вывод такой:
В этой статье мы представили новый подход к безопасности программного обеспечения, который скорее добавляет, чем удаляет ошибки, чтобы утопить злоумышленников в море заманчивых, но в конечном итоге неиспользуемых ошибок. Наш прототип, который уже способен создавать несколько видов неиспользуемых ошибок и внедрять их тысячами в крупное реальное программное обеспечение, представляет собой новый тип обманной защиты, которая тратит впустую самый ценный ресурс опытных злоумышленников: время. Мы считаем, что при дальнейших исследованиях насекомые-половинки могут стать ценным уровнем защиты, обеспечивающим сдерживание, а не просто смягчение.
Так что ты думаешь?
Лично я только что закончил читать курс о том, как избежать ошибок переполнения в C, и я думаю, что это устранение лучше, чем добавление ловушек. Позор то, что мы дошли до 21 века и до сих пор не можем остановить переполнение буфера. И прежде чем вы подумаете, что предлагаю отказаться от C и использовать что-то еще, я хочу сказать, что если у нас есть инструменты, которые могут внедрять в код тысячи ошибок переполнения, почему у нас нет инструментов, которые могут лучше удалить их, и почему бы нам не использовать те, которые у нас есть? Я думаю, это потому, что значительное количество наших товарищей все еще используют emacs и vi и заявляют, что IDE предназначена для sissys.