УДК 004.056.5

Санкт-Петербургский государственный университет телекоммуникаций им. проф. М.А.Бонч-Бруевича, 193232,Санкт-Петербург, пр. Большевиков д.22, к.1

«ИССЛЕДОВАНИЕ АТАК ТИПА ПЕРЕПОЛНЕНИЯ БУФЕРА»

С момента зарождения индустрии информационной безопасности переполнение буферов нашло способ оставаться достойным новостей. В конце 1980—х годов переполнение буфера в программе fingerd UNIX позволило Роберту т. Моррису создать червя, который заразил 10% интернета-за два дня. Это событие впервые в истории вывело кибербезопасность на передний план заголовков компьютерных наук. Почти три десятилетия спустя, в 2014 году, была раскрыта уязвимость переполнения буфера в криптографической библиотеке OpenSSL. Этот недостаток стал известен как "сердечная кровь". "Это подвергло сотни миллионов пользователей популярных онлайн-сервисов и программных платформ уязвимой версии программного обеспечения OpenSSL.Чтобы воспрепятствовать следующему червю Heartbleed или Morris, сначала необходимо понять переполнение буфера и то, как его обнаружить. Далее, важно понять процесс и последствия, связанные с успешной эксплуатацией перерасхода. Только после того, как они будут созданы, можно будет разработать план предотвращения переполнения буфера и смягчения его последствий.

St. Petersburg state University of telecommunications named after Prof. M. A. Bonch-Bruevich, 193232, 22 Bolshevikov Ave., building 1, Saint Petersburg.

«INVESTIGATION OF BUFFER OVERFLOW ATTACKS»

Since the birth of the information security industry, buffer overflow has found a way to stay newsworthy. In the late 1980s, a buffer overflow in the UNIX program fingerd allowed Robert T. Morris created a worm that infected 10% of the Internet in two days. This event brought cybersecurity to the forefront of computer science headlines for the first time in history.Almost three decades later, in 2014, a buffer overflow vulnerability was discovered in the OpenSSL cryptographic library. This deficiency became known as "heart blood". "This exposed hundreds of millions of users of popular online services and software platforms to a vulnerable version of the OpenSSL software.To prevent the next Heartbleed or Morris worm, you first need to understand the buffer overflow and how to detect it. Next, it is important to understand the process and consequences associated with successfully operating overspending. Only after they are created, it will be possible to develop a plan to prevent buffer overflow and mitigate its effects

Что такое переполнение буфера и как его обнаружить.

Прежде чем искать переполнение буфера в коде, давайте посмотрим, что это такое в первую очередь. Как следует из названия, уязвимости переполнения буфера связаны с буферами или распределением памяти в языках, которые предлагают прямой низкоуровневый доступ к памяти для чтения и записи.В случае таких языков, как C и Assembly, чтение или запись в один из этих распределений не влечет за собой автоматической проверки границ. Другими словами, нет никакой проверки того, что количество байтов, подлежащих записи или чтению, действительно поместится в рассматриваемый буфер. Таким образом, программа может "переполнить" емкость буфера. Это приводит к тому, что данные записываются мимо своего конца и перезаписывают содержимое последующих адресов в стеке или куче, или дополнительные данные считываются. На самом деле именно это и произошло в случае с жуком Heartbleed. Имея в виду это определение, мы можем исследовать, как обнаружить эти недостатки. При работе с исходным кодом короткий ответ на переполнение буфера - это просто обратить особое внимание на то, где буферы используются, модифицируются и становятся доступными. Особо следует отметить функции, имеющие дело с входными данными, предоставляемыми пользователем или другим внешним источником, поскольку они обеспечивают наиболее простой вектор для использования переполнения. Например, когда вы задаете пользователю вопрос " да " или "нет", представляется возможным сохранить строковый ввод пользователя в небольшом буфере—достаточно большом только для строки " да”, как показано в следующем примере: Рис. 1. Строковый ввод

Глядя на код, становится ясно, что проверка границ не выполняется. Если пользователь вводит “возможно", то программа, скорее всего, выйдет из строя, а не попросит пользователя дать правильный ответ и не предложит вопрос повторно. Ответ пользователя просто записывается в буфер, независимо от его длины. В этом примере, поскольку user_answer является единственной объявленной переменной, следующими значениями в стеке будет значение адреса возврата или расположение в памяти, к которому программа вернется после выполнения функции askQuestion. Это означает, что если пользователь вводит четыре байта данных (достаточно, чтобы заполнить память, специально отведенную для буфера), а затем действительный адрес в памяти, то обратный адрес программы будет изменен. Это позволяет пользователю заставить программу выйти из функции в другой точке кода, чем предполагалось изначально, что потенциально может привести к опасному и непреднамеренному поведению программы. Если первый шаг для обнаружения переполнения буфера в исходном коде-это понимание того, как они работают, а второй шаг-это знание поиска внешних входных данных и манипуляций буфером, то третий шаг - это знание того, какие функции подвержены этой уязвимости и могут выступать в качестве красных флагов для ее присутствия. Как показано выше, функция gets совершенно счастлива при записи за пределы предоставленного ей буфера. Фактически, это качество распространяется на все семейство связанных функций (включая strcopy, strcat и printf / sprint). Везде, где используется одна из этих функций, вероятно, существует уязвимость переполнения буфера.