Что происходит на компьютере если объем данных превышает пределы буфера

Обновлено: 06.07.2024

Переполнение буфера (Buffer Overflow)— запись или чтение программой данных за пределами выделенного для этого в памяти буфера. Обычно возникает из-за неправильной работы с данными и памятью, при отсутствии жесткой защиты со стороны подсистемы программирования и ОС. Данный вид ошибок достаточно распространён и часто связан с опечатками при наборе. Существует также родственная ошибка - неполная обработка буфера (Buffer Underflow).

Ошибки Buffer Overflow и Buffer Underflow буфера часто приводят к использованию в программе неинициализированных данных и как следствие к её неопределенному поведению. Переполнение буфера также может стать причиной ошибки сегментации (Access Violation).

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

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

Вот несколько примеров данной ошибки, найденных в коде реальных open-source проектов с помощью статического анализатора PVS-Studio.

Проект MAME (эмулятор игр). Выход за границы буфера.

Массив 'rawheader' состоит из 108 байт. Планируется скопировать его содержимое, начиная с байта под номером 100. Беда в том, что при этом мы выйдем за границы массива. Можно скопировать только 8 байт. А копируется 20 байт.

Теперь рассмотрим пример ошибки неполной очистки буфера (Buffer Underflow). Проект Chromium.

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

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

Нежелательная запись вне буфера может быть вызвана не только чрезмерным объемом данных, но также переполнением (или другим неправильным вычислением) целевого адреса, который указывает, где запись данных должна быть записана в буфере. В этом случае, с помощью , указатель перелива " (от английского указателя , для„ указателя “) разговорного.

Опасность переполнения буфера

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

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

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

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

В защищенном режиме , который был представлен в 80286 , память программ, данных и стека может быть физически отделена друг от друга путем сегментирования линейной памяти . Защита доступа осуществляется через блок управления памятью ЦП. Операционная система просто должна гарантировать, что доступно не больше памяти, чем линейное адресное пространство. OS / 2 была единственной широко используемой операционной системой, в которой использовалась сегментация памяти.

Языки программирования

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

Часто используемый язык программирования C ++ предлагает лишь ограниченные возможности для автоматической проверки границ полей. В качестве дальнейшего развития языка программирования C он берет на себя большинство свойств языка C, но можно в значительной степени избежать риска переполнения буфера при использовании ресурсов современного языка (включая автоматическое управление памятью). Из-за привычки, соображений совместимости с существующим кодом C, системных вызовов в соглашении C и по соображениям производительности эти параметры не всегда используются. В отличие от таких языков, как Pascal или Ada, проверки времени выполнения не являются частью языка, но могут быть модифицированы в некоторых случаях использования (например, с помощью интеллектуальных указателей ).

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

На уровне языка программирования риск переполнения буфера можно уменьшить или исключить, если использовать языки программирования, которые концептуально более безопасны, чем C ++ или C. Риск гораздо ниже, например, в языках программирования семейства Pascal Modula , Object Pascal или Ada.

Переполнение буфера, например, в языке программирования Java , практически невозможно, поскольку выполнение контролируется в байтовом коде . Но в Java также есть переполнение буфера, причина которого кроется в системе времени выполнения и которая влияет на несколько версий JRE . С другой стороны, среда выполнения Java выдает его, java.lang.StackOverflowError если стек вызова метода переполняется из-за неправильной бесконечной рекурсии. Это логическая ошибка программирования прикладного программиста, а не исполняющей системы.

Процессоры и стиль программирования

Другие особенности C и C ++ и наиболее часто используемых процессоров делают вероятным переполнение буфера. Программы на этих языках частично состоят из подпрограмм . У них есть локальные переменные.

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

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

В случае процессоров, которые описывают стек вниз, это выглядит так, прежде чем вызывать get (функция стандартной библиотеки C) (если игнорировать возможно существующий базовый указатель):

Обратный адрес
1000-е символы
. .
3-й персонаж
2-й персонаж
1-й персонаж	← Указатель стека

Стек растет вниз, переменная перезаписывается вверх

00@45eA/%A@4 . . . . . . . . . . . . . 0A&% Ввод, записывается в стек с помощью get (1004 символа)

измененный обратный адрес
строка, 1000-е символы
.
строка, 5-й символ	третий байт в коде
строка, 4-й символ	второй байт в коде
строка, 3-й символ	Назначение обратного адреса, запуск программного кода
строка, 2-й символ
строка, 1-й символ	← Указатель стека

Перезапись адреса возврата и программного кода в стеке

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

Контрмеры

Создание программы

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

Проверка программного кода

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

Поддержка компилятора

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

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

Компилятор и расширения компилятора

Например , для коллекции компиляторов GNU есть два общих расширения, которые реализуют меры, подобные описанным выше:

Stack Smashing Protector от IBM , ранее известный как ProPolice ( домашняя страница, английский ).
Stack Guard , разработанный в Oregon Health & Science University , то время в Linux распределенияImmunix , теперь в Novell .

Переполнение кучи

Переполнение является переполнение буфера , которое происходит на куче . Память в куче выделяется, когда программы запрашивают динамическую память, например, через malloc () или оператор new в C ++ . Если данные записываются в буфер в куче без проверки длины, и если объем данных больше, чем размер буфера, то данные записываются за пределами конца буфера и происходит переполнение памяти.

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

Например, 23 июня 2015 года Adobe объявила, что такое переполнение буфера может привести к запуску любого вредоносного кода в системе и, таким образом, получить контроль над системой, на которой был установлен Flash Player .

пример

Поскольку strcpy () не проверяет размеры источника и цели, а скорее ожидает в качестве источника область памяти с нулевым завершением ('\ 0'), следующий вариант также небезопасен (однако он не будет превышать "buf" , но возможно выше конца области памяти, выделенной для "s").

Команда strncpy, с другой стороны, копирует максимум n символов из источника в место назначения и, таким образом, работает, если s заканчивается нулем или больше, чем BUFSIZE.

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

Все программисты знают о потенциальной угрозе переполнения буфера (buffer) в своих программах. Существует много угроз, связанных с ним, как в новом, так и в старом ПО, независимо от количества выполненных исправлений. Злоумышленники могут воспользоваться такой ошибкой, внедрив код, специально предназначенный для того, чтобы вызвать переполнение начальной части набора данных, а затем записать оставшиеся в адрес памяти, смежный с переполненным.

Определение переполнения буфера

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

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

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

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

Использование переполнения буфера позволяет злоумышленнику контролировать или завершать работу процесса либо изменять его внутренние переменные. Это нарушение занимает место в топ-25 наиболее опасных программных ошибок мира (2009 CWE/SANS Top 25 Most Dangerous Programming Errors) и определяется как CWE-120 в словаре перечислений слабых системных мест. Несмотря на то что они хорошо изучены, они продолжают наносить вред популярным программам.

Простой вектор использования буфера

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

Глядя на код, видно, что проверка границ не выполняется. Если пользователь вводит «возможно», то программа будет аварийно завершать работу, а не запрашивать у него ответ, который записывается в buffer независимо от его длины. В этом примере, поскольку user answer является единственной объявленной переменной, следующие значения в стеке будут значением обратного адреса или местом в памяти, куда программа вернется после выполнения функции ask Question.

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

Если первым шагом для обнаружения переполнения буфера в исходном коде является понимание того, как они работают, вторым этапом является изучение внешнего ввода и манипуляций с буфером, то третьим шагом будет необходимость узнать, какие функции подвержены этой уязвимости и какие могут действовать как «красные флаги». Функция gets отлично подходит для записи за пределами предоставленного ей buffer. На самом деле это качество распространяется на все семейство связанных возможностей, включая strcpy, strcmp и printf/sprintf, везде, где используется одна из этих функций уязвимости переполнения.

Удаление из кодовой базы

Конечно, не всегда возможно полностью изменить язык разработки. В этом случае используют безопасные методы для работы с переполнением буфера команд. В случае функций обработки строк было много дискуссий о том, какие методы доступны, какие безопасны в использовании, а каких следует избегать. Функции strcpy и strcat копируют строку в буфер и добавляют содержимое одного в другой. Эти два метода демонстрируют небезопасное поведение, поскольку не проверяют границы целевого buffer, и выполняют запись за пределами, если для этого достаточно байтов.

Альтернативная защита

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

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

Недостаток заключается в том, что язык C не предоставляет стандартную, безопасную альтернативу этим функциям. Тем не менее имеется и позитив - доступность нескольких реализаций для конкретной платформы. OpenBSD предоставляет strlcpy и strlcat, которые работают аналогично функциям strn, за исключением того, что они усекают строку на один символ раньше, чтобы освободить место для нулевого терминатора.

Аналогично Microsoft предоставляет свои собственные безопасные реализации часто используемых функций обработки строк: strcpy_s, strcat_s и sprintf_s.

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

Уязвимости компиляции

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

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

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

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

Статический анализ покрытия

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

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

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

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

Выполнение атаки через root

Ошибки кодирования обычно являются причиной переполнения buffer. Распространенные ошибки при разработке приложений, которые могут привести к нему, включают в себя неспособность выделить достаточно большие буферы и отсутствие механизма проверки этих проблем. Такие ошибки особенно проблематичны в языках C/C++, которые не имеют встроенной защиты от переполнения и часто являются объектами атак переполнения буфера.

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

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

Атака временной области хранения

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

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

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

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

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

Варианты работы программы:

Уязвимость существует из-за переполнения, если пользовательский ввод argv превышает 8 байтов. Для 32-битной системы (4 байта) заполняют память двойным словом (32 бита). Размер символа составляет 1 байт, поэтому если запросить буфер с 5 байтами, система выделит 2 двойных слова (8 байтов). Вот почему при вводе более 8 байтов Buffer будет переполнен.

Подобные стандартные функции, которые технически менее уязвимы, существуют. Например, strncpy (), strncat () и memcpy (). Проблема с этими функциями заключается в том, что ответственность за определение размера буфера лежит на программисте, а не на компиляторе.

Каждый программист C/C++ должен знать проблему прежде чем начинать кодирование. Многие генерируемые проблемы в большинстве случаев могут быть защищены от переполнения.

Опасности в C/C++

Пользователи C должны избегать применения опасных функций, которые не проверяют границы, если они не уверены, что границы не будут превышены. Функции, которых следует избегать в большинстве случаев, чтобы обеспечить защиту, включают функции strcpy. Их следует заменить такими функциями, как strncpy. Следует избегать использования функции strlen, если пользователь уверен, что будет найден завершающий символ NIL. Семейство scanf (): scanf (3), fscanf (3), sscanf (3), vscanf (3), vsscanf (3) и vfscanf (3) - опасно для использования, его не применяют для отправки данных в строку без контроля максимальной длины, "формат% s" является особенно распространенным сбоем.

Официально snprintf () не является стандартной функцией C в классификации ISO 1990. Эти системы не защищают от переполнения буфера, они просто вызывают sprintf напрямую. Известно, что текущая версия Linux snprintf работает правильно, то есть фактически соблюдает установленную границу. Возвращаемое значение snprintf () также меняется.

Версия 2 спецификации Unix (SUS) и стандарт C99 отличаются тем, что возвращает snprintf (). Некоторые версии snprintf don't гарантируют, что строка закончится в NIL, а если строка слишком длинная, она вообще не будет содержать NIL. Библиотека glib имеет g_snprintf () с последовательной семантикой возврата, всегда заканчивается NIL и, что наиболее важно, всегда учитывает длину буфера.

Переполнение буфера коммуникационного порта

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

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

Чтобы решить проблему, когда обнаружено переполнение стекового буфера в Windows 10, нужно открыть диспетчер устройств. Затем найти COM-порт, для которого изменяют настройки, и открыть свойства. Далее нажимают на вкладку «Дополнительно», появится ползунок, которым изменяют размер переполнения буфера обмена, чтобы UART быстрее включил управление потоком.

Значение по умолчанию в большинстве случаев достаточно. Однако если поступает ошибка переполнения buffer, уменьшают значение. Это приведет к тому, что большее количество прерываний будет отправлено процессору с замедлением байтов в UART.

Методы безопасной разработки

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

Облачная служба Veracode выявляет уязвимости кода, такие как переполнение buffer, поэтому разработчики устраняют их до того, как они будут использованы. Уникальная в отрасли запатентованная технология тестирования безопасности бинарных статических приложений (SAST) Veracode анализирует его, включая компоненты с открытым исходным кодом и сторонние, без необходимости доступа к нему.

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

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

Уязвимость переполнения buffer существует уже почти 3 десятилетия, но она по-прежнему обременительна. Хакеры по всему миру продолжают считать ее своей тактикой по умолчанию из-за огромного количества восприимчивых веб-приложений. Разработчики и программисты затрачивают огромные усилия для борьбы с этим злом IT-технологий, придумывая все новые и новые способы.

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

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

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

Причины возникновения ошибки переполнения стекового буфера

Для размещения данных программами используются блоки памяти (буферы), обычно фиксированной длины, то есть вмещающие ограниченный объём информации. Ошибка переполнения стекового буфера возникает, когда приложение пишет больше данных, чем выделено под стековый буфер, провоцируя перезаписывание, и не исключено, что будут перезаписаны важные избыточные данные в стеке, расположенные следом за массивом или перед ним.

Стек (абстрактный тип данных) являет собой список элементов, располагающихся стопкой, где информация упорядочена таким образом, что добавление элемента делает его головным, а удаление убирает первый элемент, тогда как головным станет следующий за ним. Принцип работы стека часто сравнивается со стопкой тарелок – выдернуть из середины тарелку нельзя, снимаются они поочерёдно, начиная с верхней, то есть порядок взаимодействия осуществляется по принципу LIFO (Last In, First Out – последним пришёл, первым ушёл).

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

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

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

Что делать, если обнаружена уязвимость в данном приложении

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

Использование антивирусного ПО

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

Рекомендуется просканировать систему на вирусы, можно в безопасном режиме, если ОС не загружается, и выполнить проверку и устранение угроз посредством встроенного Защитника Windows.

Как очистить компьютер от вирусов при появлении ошибки «Стековый буфер переполнен»:

Открываем Защитник Windows через поисковую строку меню «Пуск» или в области уведомлений на панели задач;
Выбираем «Защита от вирусов и угроз» и переходим к параметрам сканирования;
Отмечаем флажком «Автономное сканирование Защитника Windows» и жмём соответствующую кнопку для начала проверки.

Чистая загрузка ОС Windows

Если переустановка софта и перезагрузка не помогли, и ошибка переполнения стекового буфера не исчезла, стоит попробовать выполнить чистую загрузку системы. Возможно, причины проблемы не относятся к данному приложению, ведь кроме работающих программ в Windows запущен ряд прочих процессов, которые и могут провоцировать баг. Для выполнения загрузки ОС в чистом виде нужно войти под учётной записью администратора компьютера, некоторые функции и приложения при этом будут недоступны, поскольку в данном режиме запускаются только необходимые системе файлы.

Для чистой загрузки Windows выполняем следующие действия:

Открываем консоль «Выполнить» (Win+R), вводим в поле команду msconfig, жмём «Ок» или клавишу Enter.
В окне «Конфигурация системы» на вкладке «Общие» снимаем отметку с пункта «Загружать элементы автозагрузки». Затем на вкладке «Службы» отмечаем пункт «Не отображать службы Майкрософт» и жмём кнопку «Отключить все».
Идём на вкладку «Автозагрузка» и жмём ссылку «Открыть диспетчер задач» (для Windows 10), в открывшемся окне Диспетчера задач поочерёдно отключаем каждую программу в списке.
Возвращаемся к окну конфигурации и жмём «Ок», после чего перезагружаемся и проверяем, исчезла ли ошибка.

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

Специализированный софт

Восстановление Windows

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

отключаем от компьютера лишние устройства, не требуемые для работы;
вставляем загрузочный накопитель и загружаемся с него, предварительно выставив приоритет загрузки в BIOS;
выбираем «Восстановление системы» – «Диагностика» – «Дополнительные параметры» – «Восстановление при загрузке», далее выбираем ОС, которую требуется восстановить, и ждём окончания процесса, перезагружаемся.

Читайте также: