Текст книги "19 смертных грехов, угрожающих безопасности программ"

Искупление греха

По–настоящему избавиться от ошибок переполнения целого можно, только если вы хорошо понимаете суть проблемы. Но все же опишем несколько шагов, которые помогут не допустить такой ошибки. Прежде всего пользуйтесь всюду, где возможно, числами без знака. В стандарте C/C++ описан тип size_t для представления размеров, и разумные программисты им пользуются. Контролировать беззнаковые целые гораздо проще, чем знаковые. Ну нет же смысла применять число со знаком для задания размера выделяемой памяти!

Избегайте «хитроумного» кода – контроль целых должен быть прост и понятен. Вот пример чересчур заумного кода для контроля переполнения при сложении:

int a, b, c;

c = a + b;

if(a ^ b ^ c < 0)

return BAD_INPUT;

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

int a, b, c;

c = a * b;

if(c < 0)

return BAD_INPUT;

Даже если на входе допустимы только положительные числа, этот код все равно пропускает некоторые переполнения. Возьмем, к примеру, выражение (2 ^А 30 + + 1) * 8, то есть 2 ^А 33 + 8. После отбрасывания битов, вышедших за пределы 32 разрядов, получается 8. Это число положительно, а ошибка тем не менее есть. Безопаснее решить эту задачу, сохранив результат умножения 32–разрядных чисел в 64–разрядном, а затем проверить, равен ли хотя бы один из старших битов единице. Это и будет свидетельством переполнения.

Когда встречается подобный код:

unsigned a, b;

...

if (a * b < MAX) {

...

}

проще ограничить а и b значениями, произведение которых заведомо меньше МАХ. Например:

#include «limits.h»

#define MAX_A 10000

#define MAX_A 250

assert(UINT_MAX / MAX_A >= MAX_B); // проверим, что MAX_A и MAX_B

                                                      // достаточно малы

if (a < MAX_A && b < MAX_B) {

...

}

Если вы хотите надежно защитить свой код от переполнений целого, можете воспользоваться классом Safelnt, который написал Дэвид Лебланк (подробности в разделе «Другие ресурсы»). Но имейте в виду, что, не перехватывая исключения, возбуждаемые этим классом, вы обмениваете возможность выполнения произвольного кода на отказ от обслуживания. Вот пример использования класса Safelnt:

size_t CalcAllocSize(int HowMany, int Size, int HeaderLen)

{

try{

SafeInt<size_t> tmp(HowMany);

return tmp * Size + SafeInt<size_t>(HeaderLen);

}

catch(SafeIntException)

{

return (size_t)~0;

}

}

Целые со знаком используются в этом фрагменте только для иллюстрации; такую функцию следовало бы писать, пользуясь одним лишь типом size_t. Посмотрим, что происходит «под капотом». Прежде всего проверяется, что значение HowMany неотрицательно. Попытка присвоить отрицательное значение беззнаковой переменной типа Safelnt вызовет исключение. Затем Safelnt умножается на переменную Size типа int, при этом проверяется как переполнение, так и попадание в допустимый диапазон. Результат умножения Safelnt * int – это снова Safelnt, поэтому далее выполняется операция контролируемого сложения. Обратите внимание на приведение входного параметра типа int к типу Safelnt – отрицательная длина заголовка с точки зрения математики, может быть, и допустима, но с точки зрения здравого смысла – нет, поэтому размеры лучше представлять числами без знака. Наконец, перед возвратом величина типа Safelnt<size_t> преобразуется обратно в size_t, это пустая операция. Внутри класса Safelnt выполняется много сложных проверок, но ваш код остается простым и понятным.

Если вы программируете на С#, включайте флаг /checked и применяйте unchecked–блоки только для того, чтобы отключить контроль в отдельных предложениях.

Дополнительные защитные меры

Если вы работаете с компилятором gcc, то можете задать флаг–ftrapv. В этом случае за счет обращения к различным функциям во время выполнения будут перехватываться переполнения при операциях со знаковыми и только со знаковыми целыми. Неприятность в том, что при обнаружении переполнения вызывается функция abort().

Компилятор Microsoft Visual С++ 2005 автоматически обнаруживает переполнение при вызове оператора new. Ваша программа должна перехватывать исключения std::bad_alloc, иначе произойдет аварийный останов.

Другие ресурсы

□ «Integer Handling with the С++ Safelnt Class», David LeBlanc, msdn.microsoft.com/library/default.asp?url=/library/en–us/dncode/html/ secure01142004.asp

□ «Another Look at the Safelnt Class», David LeBlanc, http://msdn.microsoft.com/ library/default.asp?url=/library/en–us/dncode/html/secure05052005.asp

□ «Reviewing Code for Integer Manipulation Vulnerabilities*, Michael Howard, http://msdn. microsoft, com/library/default.asp?url=/library/en–us/dncode/ html/ secure04102003.asp

□ «An Overlooked Construct and an Integer Overflow Redux», Michael Howard, http://msdn. microsoft, com/library/default.asp?url=/library/en–us/dncode/ html/ secure09112003.asp

□ «Expert Tips for Finding Security Defects in Your Code», Michael Howard, http://msdn.microsoft.eom/msdnmag/issues/03/l 1/SecurityCodeReview/ default.aspx

□ «Integer overflows – the next big threat», Ravind Ramesh, central.com/tech/story.asp?file=/2004/10/26/itfeature/9170256&sec=itfeature

□ DOS against Java JNDI/DNS, http://archives.neophasis.com/archives/ bugtraq/2004–11 / 0092.html

Резюме

Рекомендуется

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

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

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

Не рекомендуется

□ Не думайте, что ни в каких языках, кроме C/C++, переполнение целого невозможно.

Грех 4.
Внедрение SQL–команд

В чем состоит грех

Уязвимость для внедрения SQL–команд (или просто «внедрение SQL») – это широко распространенный дефект, который может привести к компрометации машины и раскрытию секретных данных. А печальнее всего то, что от этой ошибки часто страдают приложения электронной коммерции и программы, обрабатывающие конфиденциальные данные и персональную информацию. Опыт авторов показывает, что многие приложения, работающие с базами данных, которые создавались для внутреннего использования или обмена информацией с партнерами по бизнесу, подвержены внедрению SQL.

Никогда не интересовались, как хакеры воруют номера кредитных карточек с Web–сайтов? Одним из двух способов: либо внедряя SQL, либо заходя через парадный вход, который вы распахиваете перед ними, открывая порт сервера базы данных (ТСР/1433 для Microsoft SQL Server, TCP/1521 для Oracle, TCP/523 для IBM/DB2 и TCP/3306 для MySQL) для доступа из Интернет и оставляя без изменения принимаемый по умолчанию пароль администратора базы данных.

Быть может, самая серьезная опасность, связанная с внедрением SQL, – это получение противником персональных или секретных данных. В некоторых странах, штатах и отраслях промышленности вас за это могут привлечь к суду. Например, в штате Калифорния можно сесть в тюрьму по закону о защите тайны личной жизни в сети, если из управляемой вами базы данных была похищена конфиденциальная или персональная информация. В Германии §9 DBSG (Федеральный закон о защите данных) требует, чтобы были предприняты должные организационные и технические меры для защиты систем, в которых хранится персональная информация. Не забывайте также о действующем в США Акте Сарбанеса–Оксли от 2002 года, и прежде всего о параграфе 404, который обязывает защищать данные, на основе которых формируется финансовая отчетность компании. Система, уязвимая для атак с внедрением SQL, очевидно, имеет неэффективные средства контроля доступа, а значит, не соответствует всем этим установлениям.

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

Подверженные греху языки

Все языки программирования, применяемые для организации интерфейса с базой данных, уязвимы! Но прежде всего это относится к таким языкам высокого уровня, как Perl, Python, Java, технологии «серверных страниц» (ASP, ASP.NET, JSP и PHP), С# и VB.NET. Иногда оказываются скомпрометированными также и языки низкого уровня, например библиотеки функций или классов, написанные на С или С++ (к примеру, библиотека c–tree компании FairCom или Microsoft Foundation Classes). Наконец, не свободен от греха и сам язык SQL.

Как происходит грехопадение

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

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

Вот классический пример внедрения SQL:

using System.Data;

using System.Data.SqlClient;

...

string ccnum = "None";

try {

SqlConnection sql = new SqlConnection(

@"data source=localhost;" +

"user id=sa;password=pAs$w0rd;");

sql.Open();

string sqlstring="SELECT ccnum" +

" FROM cust WHERE id=" + Id;

SqlCommand cmd = new SqlCommand(sqlstring,sql);

try {

ccnum = (string)cmd.ExecuteScalar();

} catch (SqlException se) {

Status = sqlstring + " failednr";

foreach (SqlError e in se.Errors) {

Status += e.Message + "nr";

}

} catch (SqlException e) {

// Ой!

}

Ниже приведен по существу такой же код, но SQL–предложение строится с помощью замены подстроки, а не конкатенации. Это тоже ошибка.

using System.Data;

using System.Data.SqlClient;

...

string ccnum = "None";

try {

SqlConnection sql = new SqlConnection(

@"data source=localhost;" +

"user id=sa;password=pAs$w0rd;");

sql.Open();

string sqlstring="SELECT ccnum" +

" FROM cust WHERE id=%ID%";

String sqlstring2 = sqlstring.Replace("%ID", id);

SqlCommand cmd = new SqlCommand(sqlstring2,sql);

try {

ccnum = (string)cmd.ExecuteScalar();

} catch (SqlException se) {

Status = sqlstring + " failednr";

foreach (SqlError e in se.Errors) {

Status += e.Message + "nr";

}

} catch (SqlException e) {

// Ой!

}

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

<?php

$db = mysql_connect("localhost","root","$$sshhh...!");

mysql_select_db("Shipping",$db);

$id = $HTTP_GET_VARS["id"];

$qry = "SELECT ccnum FROM cust WHERE id = %$id%";

$result = mysql_query($qry,$db);

if ($result) {

echo mysql_result($result,0,"ccnum");

} else {

echo "No result! " . mysql_error();

}

?>

И снова тот же дефект, но на этот раз в программе на достопочтенном Perl:

#!/usr/bin/perl

use DBI;

use CGI;

print CGI::header();

$cgi = new CGI;

$id = $cgi->param('id');

$dbh = DBI->connect('DBI:mysql:Shipping:localhost',

'root',

'$3cre+')

or print "Ошибка connect : $DBI::errstr";

$sql = "SELECT ccnum FROM cust WHERE id = " . $id;

$sth = $dbh->prepare($sql)

or print "Ошибка prepare : $DBI::errstr";

$sth->execute()

or print "Ошибка execute : $DBI::errstr";

# Вывести данные

while (@row = $sth->fetchrow_array ) {

print "@row<br>";

}

$dbh->disconnect;

print "</body></html>";

exit;

Еще один распространенный язык, Java. Подвержен внедрению SQL по той же схеме.

import java.*;

import java.sql.*;

...

public static boolean doQuery(String Id) {

Connection con = null;

try

{

Class.forName("com.microsoft.jdbc.sqlserver.SQLServerDriver");

con = DriverManager.getConnection("jdbc:microsoft:sqlserver: " +

                                           "//localhost:1433", "sa", "$3cre+");

Statement st = con.createStatement();

ResultSet rs = st.executeQuery("SELECT ccnum FROM cust WHERE id=" +

                                   Id);

while (rx.next()) {

// Полюбоваться на результаты запроса

}

rs.close();

st.close();

}

catch (SQLException e)

{

// Ой!

return false;

}

catch (ClassNotFoundException e)

{

// Не найден класс

return false;

}

finally

{

try

{

con.close();

} catch(SQLException e) {}

}

return true;

}

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

CREATE PROCEDURE dbo.doQuery(@query nchar(128))

AS

exec(@query)

RETURN

А вот следующий код распространен куда шире и не менее опасен:

CREATE PROCEDURE dbo.doQuery(@id nchar(128))

AS

DECLARE @query nchar(256)

SELECT @query = 'select ccnum from cust where id = ''' + @id + ''''

EXEC @query

RETURN

Здесь опасная конкатенация строк выполняется внутри процедуры. То есть вы по–прежнему совершаете постыдный грех, даже если процедура вызвана из корректного кода на языке высокого уровня.

Стоит поискать и другие операторы конкатенации, имеющиеся в SQL, а именно «+» и «||», а также функции CONCAT() и CONCATENATE().

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

Классическая атака состоит в том, чтобы видоизменить SQL–запрос, добавив лишние части и закомментарив «ненужные». Например, если противник контролирует переменную Id, то может задать в качестве ее значения строку 1 or 2>1 – – , тогда запрос примет такой вид:

SELECT ccnum FROM cust WHERE id=1 or 2>1 – –

Условие 2>1 истинно для всех строк таблицы, поэтому запрос возвращает все строки из таблицы cust, другими словами, номера всех кредитных карточек. Можно было бы воспользоваться классической атакой «1 = 1», но сетевые администраторы часто включают поиск такой строки в системы обнаружения вторжений (IDS), поэтому мы применили условие «2>1», которое столь же эффективно, но «проходит под лучом радара».

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

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

Во всех приведенных выше примерах демонстрируются и другие грехи:

□ соединение от имени учетной записи с высоким уровнем доступа;

□ включение пароля в текст программы;

□ сообщение противнику излишне подробной информации в случае ошибки.

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

«Зашивание» паролей в код – почти всегда порочная идея. Подробнее см. грех 11 и 12 и предлагаемые там «лекарства».

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

Где искать ошибку

Любое приложение, обладающее перечисленными ниже характеристиками, подвержено риску внедрения SQL:

□ принимает данные от пользователя;

□ не проверяет корректность входных данных;

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

□ применяет конкатенацию или замену подстроки для построения SQL–запроса либо пользуется командой SQL exec (или ей подобной).

Выявление ошибки на этапе анализа кода

Во время анализа кода на предмет возможности внедрения SQL прежде всего ищите места, где выполняются запросы к базе данных. Ясно, что программам, не обращающимся к базе данных, эта напасть не угрожает. Мы обычно ищем следующие конструкции:

Выяснив, что в программе есть обращения к базе данных[1]1
  Перечень технологий доступа к базам данных, доступных из программ на Perl, см. на странице http://search.cpan.org/modlist/Database_Interfaces.


[Закрыть], нужно определить, где выполняются запросы и насколько можно доверять данным, участвующим в запросе. Самое простое – найти все места, где выполняются предложения SQL, и посмотреть, производится ли конкатенация или подстановка небезопасных данных, взятых, например, из строки Web–запроса, из Web–формы или аргумента SOAP. Вообще, любых поступающих от пользователя данных!

Тестирование

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

Прежде всего определите все точки входа в приложение, где формируются SQL–запросы. Затем создайте тестовую программу–клиент, которая будет посылать в эти точки частично некорректные данные. Например, если тестируется Web–приложение, которое строит запрос на основе одного или нескольких полей формы, попробуйте вставить в них произвольные ключевые слова языка SQL. Следующий пример на Perl показывает, как это можно сделать.

#!/usr/bin/perl

use strict;

use HTTP::Request::Common qw(POST GET);

use HTTP::Headers;

use LWP::UserAgent;

srand time;

# Приостановить исполнение, если найдена ошибка

my $pause = 1;

# Тестируемый URL

my $url = 'http://mywebserver.xyzzy123.com/cgi-bin/post.cgi';

# Максимально допустимый размер HTTP-ответа

my $max_response = 1000;

# Допустимые города

my @cities = qw(Auckland Seattle London Portland Manchester Redmond

Brisbane Ndola);

while (1) {

my $city = randomSQL($cities[rand @cities]);

my $zip = randomSQL(10000 + int(rand 89999));

print «Пробую [$city] и [zip]n»;

my $ua = LWP::UserAgent->new();

my $req = POST $url,

[ City => $city,

ZipCode => $zip,

];

# Послать запрос, получить ответ и поискать в нем признаки ошибки

my $res = $ua->request($req);

$_ = $res->as_string;

die "Хост недостижимn" if /bad hostname/ig;

if ($res->status_line != 200

|| /error/ig

|| length($_) > $max_response) {

print "nПотенциальная возможность внедрения SQLn";

print;

getc if $pause;

}

}

# Выбрать случайное ключевое слово SQL, в 50% случаев перевести

# его в верхний регистр

sub randomSQL() {

$_ = shift;

return $_ if ($rand > .75);

my @sqlchars = qw(1=1 2>1 «fred=»fre" + "d" or and select union

                         drop update insert into dbo < > = ( ) ' .. – #);

my $sql = $sqlchars[rand @sqlchars];

$sql = uc($sql) id rand > .5;

return $_ . ' ' . $sql if rand > .9;

return $sql . ' ' . $_ if rand > .9;

return $sql;

}

Этот код обнаружит возможность внедрения SQL только в случае, когда приложение возвращает сообщение об ошибке. Как мы уже сказали, нет ничего лучше тщательного анализа кода. Другой способ тестирования заключается в том, чтобы воспользоваться приведенной выше Perl–программой, заранее выяснить, как выглядит нормальный ответ, а затем анализировать, на какие запросы получен ответ, отличающийся от правильного, или вообще нет никакого ответа.

Имеются также инструменты третьих фирм, например AppScan компании Sanctum (теперь Watchfire) (www.watchfire.com), Weblnspect компании SPI Dynamics (www.spidynamics.com) и ScanDo компании Kavado (www.kavado.com).

Для оценки инструмента рекомендуем создать небольшое тестовое приложение с известными ошибками, допускающими внедрение SQL, и посмотреть, какие ошибки этот инструмент сумеет найти.