У Perl CGI-программ есть переполнение буфера или уязвимость скрипта для форм HTML-контактов?

Question

Моя хостинговая компания заявляет, что можно заполнить поле ввода текста в виде HTML только с нужным количеством байтов мусора, чтобы вызвать проблему переполнения/ресурса буфера при использовании с Apache/HTTP POST для скрипта CGI-Bin Perl (например, NMS FormMail).

Говорят, что происходит сбой ядра, в этот момент на сервере может быть запущен произвольный скрипт (сохраненный как часть текста поля ввода), который может поставить под угрозу сайт. Они говорят, что это не то, что они могут защитить в своей конфигурации Apache/Perl —, что для сценария Perl это предотвращает это, ограничивая количество символов в опубликованных полях. Но похоже, что основной дамп может произойти до того, как скрипт сможет ограничить размеры полей.

Этот вид контактной формы и метода широко используется тысячами сайтов, поэтому мне интересно, верно ли то, что они говорят. Можете ли вы экспертов по безопасности просветить меня — это правда? Мне также интересно, может ли то же самое происходить с PHP-скриптом. Что вы рекомендуете для безопасного сценария/метода контакта с сайтом?

Answer 1

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

use CGI qw/:standard/; 
$CGI::POST_MAX=1024 * 100; # max 100K posts 
$CGI::DISABLE_UPLOADS = 1; # no uploads 

Answer 2

Попросите их предоставить вам конкретную ссылку на уязвимость. Я уверен, что есть версии Apache, где можно вызвать переполнение буфера с помощью специально созданных запросов POST, но я не знаю никаких специфических для NMS FormMail.

Answer 3

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

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

Answer 4

Вам определенно следует задать специфику вашей хостинговой компании. В нем много несвязанных заявлений.

«Переполнение буфера» и «проблема с ресурсами» - это совершенно разные вещи. Переполнение буфера предполагает, что вы будете разбивать perl или mod_perl или httpd сами. Если это так, то в одном из этих компонентов есть ошибка, и они должны ссылаться на указанную ошибку и предоставлять временные рамки, когда они будут применять обновление безопасности. Такая ошибка, несомненно, заставит Бугтрака.

Проблема с ресурсами, с другой стороны, совершенно другая вещь. Если я отправлю вам много мегабайт в свой POST, я бы мог съесть произвольный объем памяти. Это можно решить, настроив директиву LimitRequestBody в httpd.conf. Значение по умолчанию не ограничено. Это должно быть установлено хостинг-провайдером.

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

Опять же, если это создает дамп ядра в HTTPD (или mod_perl), то он представляет собой ошибку в HTTPD (или mod_perl).Динамическое управление памятью Perl и сборкой мусора не связано с переполнением буфера или плохими указателями в принципе. Это не означает, что ошибка в perl сама по себе не может вызвать этого, просто, что сам язык perl не имеет языковых функций, необходимых для создания основных дампов таким образом.

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