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

Question

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

Говорят, что дамп ядра происходит, и в этот момент на сервере может быть запущен произвольный скрипт (сохраненный как часть текста поля ввода), который может поставить под угрозу сайт. Они говорят, что это не то, от чего они могут защитить в своей конфигурации Apache / Perl & mdash; что это зависит от сценария 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

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

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

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

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

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

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

Answer 3

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

Answer 4

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

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