Обнаружение в коде дефекта «разыменование нулевого указателя»
Разыменование нулевого указателя (CWE-476) представляет собой дефект, когда программа обращается по некорректному указателю к какому-то участку памяти. Такое обращение ведет к неопределенному поведению программы, что приводит в большинстве случаев к аварийному завершению программы.
Ниже приведен пример обращения по нулевому указателю. В данном случае, скорее всего, программа отработает без выдачи сообщений об ошибках.
#include
class A {
public:
void bar() {
std::cout << "Test!\n";
}
};
int main() {
A* a = 0;
a->bar();
return 0;
}
А теперь рассмотрим пример, в котором программа аварийно завершит свою работу. Пример очень похож на предыдущий, но с небольшим отличием.
#include
class A {
int x;
public:
void bar() {
std::cout << x << "Test!\n";
}
};
int main() {
A* a = 0;
a->bar();
return 0;
}
Почему же в одном случае программа отработает нормально, а в другом нет? Дело в том, что во втором случае вызываемый метод обращается к одному из полей нулевого объекта, что приведет к считыванию информации из непредсказуемой области адресного пространства. В первом же случае в методе нет обращения к полям объекта, поэтому программа скорее всего завершится корректно.
Рассмотрим следующий фрагмент кода на C++:
if( !pColl )
pColl->SetNextTxtFmtColl( *pDoc->GetTxtCollFromPool( nNxt ));
Нетрудно заметить, что если pColl == NULL, выполнится тело это условного оператора. Однако в теле оператора происходит разыменование указателя pColl, что вероятно приведет к краху программы.
Обычно такие дефекты возникают из-за невнимательности разработчика. Чаще всего блоки такого типа применяются в коде для обработки ошибок. Для выявления таких дефектов можно применить различные методы статического анализа, например, сигнатурный анализа или symbolic execution. В первом случае пишется сигнатура, которая ищет в абстрактном синтаксическом дереве (AST) узел типа «условный оператор», в условии которого есть выражение вида! а, a==0 и пр., а в теле оператора есть обращение к этому объекту или разыменование этого указателя. После этого необходимо отфильтровать ложные срабатывания, например, перед разыменованием этой переменной может присвоиться значение:
If(!a) {
a = new A();
a->bar();
}
Выражение в условии может быть нетривиальным.
Во втором случае во время работы анализатор «следит», какие значения могут иметь переменные. После обработки условия if (! a) анализатор понимает, что в теле условного оператора переменная a равна нулю. Соответственно, ее разыменование можно считать ошибкой.
Приведенный фрагмент кода взят из популярного свободного пакета офисных приложений Apache OpenOffice версии 4.1.2. Дефект в коде был обнаружен при помощи статического анализатора программного кода AppChecker. Разработчики были уведомлены об этом дефекте, и выпустили патч, в котором этот дефект был исправлен).
Рассмотрим аналогичный дефект, обнаруженный в Oracle MySQL Server 5.7.10:
bool sp_check_name(LEX_STRING *ident)
{
if (!ident || !ident->str || !ident->str[0] ||
ident->str[ident->length-1] == ' ')
{
my_error(ER_SP_WRONG_NAME, MYF(0), ident->str);
return true;
}
..
}
В этом примере если ident равен 0, то условие будет истинным и выполнится строка:
my_error(ER_SP_WRONG_NAME, MYF(0), ident->str);
что приведет к разыменованию нулевого указателя. По всей видимости разработчик в процессе написания этого фрагмента кода, в котором ловятся ошибки, просто не учел, что такая ситуация может возникнуть. Правильным решением было бы сделать отдельный обработчик ошибок в случае, когда ident=0.
Нетрудно догадаться, что разыменование нулевого указателя — это дефект, не зависящий от языка программирования. Предыдущие два примера демонстрировали код на языке C++, однако с помощью статического анализатора AppChecker можно находить подобные проблемы в проектах на языках Java и PHP. Приведем соответствующие примеры.
Рассмотрим фрагмент кода системы управления и централизации информации о строительстве BIM Server версии bimserver 1.4.0-FINAL-2015–11–04, написанной на языке Java:
if (requestUri.equals("") || requestUri.equals("/") || requestUri == null) {
requestUri = "/index.html";
}
В данном примере сначала идет обращение к переменной requestUri и только после этого происходит проверка на нулевой указатель. Для того чтобы избежать этого дефекта, достаточно было просто поменять очередность выполнения этих действий.
Теперь рассмотрим фрагмент кода популярной коллекции веб-приложений phabricator, написанной на php:
if (!$device) {
throw new Exception(
pht(
'Invalid device name ("%s"). There is no device with this name.',
$device->getName()));
}
В данном случае условие выполняется только если $device = NULL, однако затем происходит обращение к $device→getName (), что приведет к fatal error.
Подобные дефекты могут оставаться незамеченными очень долго, но в какой-то момент условие выполнится, что приведет к краху программы. Несмотря на простоту и кажущуюся банальность такого рода дефектов, они встречаются достаточно часто, как в open-source, так и в коммерческих проектах.
Комментарии (3)
AllexIn
10 января 2017 в 12:23
+2↑
↓
Разжевывание совсем уж для детей.10 января 2017 в 13:16
0↑
↓
Рассмотренные проекты явно не детьми разрабатываются, а ошибки такие допускаются…
andreymal
10 января 2017 в 13:27
0↑
↓
Но не потому что не знают, что это такое, а по невнимательности.В том числе поэтому языки, не имеющие NULL, рулят)
