Наверх, к Содержание | ||
Назад, к Безопасность на стороне клиента | Вперед,
к Библиография |
Детали использования лазейки не были опубликованы, однако вы можете найти более подробное описание проблемы в оригинальной статье на URL http://www.sddt.com/files/library/98/06/25/tbc.html.
Netscape сообщила, что исправления разрабатываются. Проверте наличие исправлений на сайте Netscape. Если Вы используете вставки на сервере, то вам необходимо воспользоваться исправлениями немедленно после их выпуска.
Серверы O'Reilly WebSite и WebSite Professional также содержат эту лазейку. Microsoft IIS видимо не содержит ее.
Netscape обещает выпустить исправления. По состоянию на 16 января 1998 года, исправления еще не доступны на сервере Netscape.
Эта ошибка затрагивает также сервер Microsoft IIS . Есть сообщения о том, что последние версии сервера WebSite Professional не содержат этой лазейки.
/cgi-bin/perl.exe?&имя_скрипта.pl
.
К сожалению, это позволяет любому пользователю в Internet выполнять на вашем
сервере произвольные команды Perl, например:
/cgi-bin/perl.exe?&-e+unlink+%3C*%3E
(при обращении стираются
все файлы в текущем директории сервера). Это плохо. Текущие
рекомендации Netscape состоят в заключении вашего скрипта в .bat файл. Однако
это не безопаснее из-за похожей проблемы с .bat файлами.
Поскольку серверы для NT EMWACS, Purveyor и WebSite используют механизмы NT для распознавания имен файлов, вы можете использовать скрипты на Perl на этих серверах не помещая perl.exe в директорий cgi-bin. Указанные серверы безопаснее в этом отношении.
Рассмотрим файл test.bat: @echo off echo Content-type: text/plain echo echo Hello World! Если обратиться к нему как "/cgi-bin/test.bat?&dir", то вы получите вывод программы, за которым последует список файлов в директории. Похоже, что сервер генерирует команду system("test.bat &dir"), которая, не без оснований, выполняется командным интерпретатором так же, как это было бы сделано оболочкой /bin/sh - выполнить test.bat и, если все в порядке, выполнить команду dir.
Детали использования лазейки не были опубликованы, однако вы можете найти более подробное описание проблемы в оригинальной статье на URL http://www.sddt.com/files/library/98/06/25/tbc.html.
В O'Reilly сообщают, что исправления будут сделаны в серверах WebSite и WebSite Professional версии 2.3. Если вы используете вставки на сервере, то вам остро необходимо подумать об обновлении версии.
Серверы Netscape для Windows также содержат эту лазейку. Microsoft IIS видимо не содержит ее.
Эта лазейка исправлена в версии 1.1c. Вы должны обновить вашу версию с использованием исправлений, доступных на сервере WebSite.
Подробная информация о действиях, необходимых для закрытия этой лазейки, доступна на этой странице разработчика сервера WebSite.
Исправления можно найти на Microsoft's security pages. Свежие версии сервера не содержат этой ошибки.
Такая же ошибка присутствует в серверах Netscape Enterprise и Commerce. Сообщается об отсутствии этой проблемы в последних версиях WebSite Professional.
Microsoft выпустил исправление этой ошибки, доступное по адресу http://www.microsoft.com/infoserv. Кроме того, все копии сервера, полученные после 5 марта 1996 года, не должны содержать этой ошибки. Если вы используете этот сервер, то проверте дату создания вашей копии, и если необходимо - обновите ее.
Microsoft IIS версий до 3.0 содержат лазейку, позволяющую удаленному пользователю получить доступ к содержимому выполняемых скриптов, и, возможно, таким образом - к важной информации: структура сети, или имена баз данных, или алгоритмы вычисления скидок. Лазейка присутствует, если для директория со скриптами разрешен доступ на чтение и на выполнение. Удаленный пользователь имеет возможность получить файл скрипта просто добавив точку в конец адреса URL. Для защиты запретите доступ для чтения ко всем дмректориям, содержащим скрипты CGI. Или получите исправления от Microsoft, доступные по адресу
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postsp2/iis-fix
Точная длина запроса, вызывающего сбой, варьирует от сервера к серверу, и зависит от таких вещей, как размер используемой памяти. Магический размер обычно составляет число, близкое к 8192 символам, что позволяет предположить наличие ошибки переполнения буфера. В прошлом подобные ошибки часто использовались знающими хакерами для выполнения команд на сервере, что позволяет опасаться, что данная лазейка может потенциально быть более опасной.
Исправления можно получить у Microsoft: ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postSP3/iis-fix
Версия JavaWebServer для Windows NT содержит лазейку, позволяющую удаленному пользователю получать доступ к исходным файлам классов Java. Ошибка похожа на ошибки в серверах O'Reilly WebSite Professional и Netscape Enterprise Server. Добавив определенные символы к URL, пользователь может заставить сервер передать ему целый сервлет, который можно декомпилировать с применением программ типа Mocha. Проблема заслуживает внимания, поскольку сервлеты могут содержать важную информацию, включая пароли для доступа к базам данных.
Компания Sun пока не объявляла об исправлениях. Проверте их доступность на корпоративном сайте Sun. Подробности можно прочесть на http://www.sddt.com/files/library/98/06/29/tbd.html
Согласно Jeff Forristal, нашедшему эту лазейку, MetaWeb содержит проблему "двойной точки", имевшуюся в ранних версиях Microsoft IIS. Включая двойные точки ("..") в состав URL, можно получить доступ к директориям за пределами дерева документов Web, включая системные директории Windows. Это позволяет получить доступ к конфиденциальной информации. Хуже того, один из вариантов нападения позволяет запускать на выполнение программы, установленные на сервере.
MetaWeb пока не предоставила исправлений или новых версий сервера. Обновите вашу версию сразу после выпуска исправлений. Хорошим временным решением проблемы будет отключение удаленного администрирования через WWW.
Более подробную информацию можно получить на сайте Jeff Forristal.
Недавно стало известно, что пример кода на C
(cgi_src/util.c
) распространявшийся долгое время с NCSA httpd в
качестве примера того, как надо писать безопасные скрипты CGI, не содержит
символа перевода строки в списке символов, запрещенных для передачи оболочке
операционной системы. Тем самым в любой скрипт, написанный с использованием
этого примера, внесена серьезная лазейка - хакер может использовать эту ошибку
для выполнения произвольной команды Unix на сервере. Это еще один пример опасности
применения команд оболочек ОС в скриптах CGI.
Кроме того, исходные тексты самого сервера NCSA (версии 1.5a и более ранние)
содержат ту же самую ошибку. Ошибочная процедура идентична, но находится в файле
src/util.c
, а не в cgi_src/util.c
. При изучении
текстов программ сервера автор не нашел места, где строка, введенная
пользователем, передавалась бы оболочке ОС после обработки этой функцией,
поэтому он думает, что это не является серьезной лазейкой. Однако
безопаснее применить исправления, приведенные ниже.
Сервер Apache, версии 1.02 и ниже, также содержит эту ошибку и в директории
cgi_src
, и в src/
. Возможно, аналогичная ошибка
имеется и в других серверах - производных от NCSA.
Способ исправления лазейки в двух файлах util.c
прост. "phf" и
любой другой скрипт, использующий эту библиотеку, должен быть заново
скомпилирован после внесения исправлений (программа GNU patch может быть
получена по ftp: ftp://prep.ai.mit.edu/pub/gnu/patch-2.1.tar.gz).
Вы должны дважды применить эту "заплату": один раз - находясь в директории
cgi_src/, потом - в src/:
tulip% cd ~www/ncsa/cgi_src tulip% patch -f < ../util.patch tulip% cd ../src tulip% patch -f < ../util.patch ---------------------------------- линия отреза ---------------------------------- *** ./util.c.old Tue Nov 14 11:38:40 1995 --- ./util.c Thu Feb 22 20:37:07 1996 *************** *** 139,145 **** l=strlen(cmd); for(x=0;cmd[x];x++) { ! if(ind("&;`'\"|*?~<>^()[]{}$\\",cmd[x]) != -1){ for(y=l+1;y>x;y--) cmd[y] = cmd[y-1]; l++; /* length has been increased */ --- 139,145 ---- l=strlen(cmd); for(x=0;cmd[x];x++) { ! if(ind("&;`'\"|*?~<>^()[]{}$\\\n",cmd[x]) != -1){ for(y=l+1;y>x;y--) cmd[y] = cmd[y-1]; l++; /* length has been increased */ ---------------------------------- линия отреза ----------------------------------
Серверы Apache до 1.1.3 содержат две гораздо более серьезные лазейки. Первая относится к серверам, откомпилированным с модулем "mod_cookies". Пользователь имеет возможность посылать очень длинные cookies и вызывать переполнение стека, что дает возможность выполнения произвольных системных команд. Поскольку в этом случае удаленный пользователь имеет возможность получить доступ к системе, в этом случае опасность гораздо более серьезная, чем в предидущем, когда лазейка может быть использована только локальным пользователем.
Вторая проблема с версией 1.1.1 касается автоматического просмотра директориев. Обычно пользователь не имеет возможности получить список файлов из директория, если там есть "страница приветствия", такая, как файл "index.html". Ошибка вызывает нарушение этой проверки при определенных условиях, и пользователь имеет возможность просмотра содержимого директория даже если там есть "страница приветствия". Ошибка менее серьезна, чем первая, но оставляет возможность для утечки информации.
Подробную информацию и текущие версии сервера Apache можно получить по адресу:
http://www.apache.org/
Однако, хорошо известны два случая, когда была взломана система шифрования, используемая в Netscape Secure Commerce Server. В первом случае сообщение, зашифрованное с менее надежным 40-разрядным ключем, было вскрыто методом грубой силы с использованием сети рабочих станций. 128-разрядные ключи, используемые для шифрования в пределах США, считаются устойчивыми к такого рода атакам.
Во втором случае было обнаружено, что генератор случайных чисел, используемый сервером для построения ключей шифрования, относительно предсказуем, что позволяет использовать программу-взломщик для быстрого нахождения правильного ключа. Эта лазейка была закрыта в последних версиях программы, и вы должны обновить вашу версию если вы используете шифрование для защиты передаваемых данных. И сервер, и браузер должны быть обновлены для того, чтобы полностью закрыть эту лазейку. Для получения дальнейшей информации см. http://home.netscape.com/newsref/std/random_seed_security.html.
Согласно Richard L. Gray (rlgray@us.ibm.com>) из IBM, все известные проблемы исправлены в версиях 4.2.1.3 и более поздних. Lotus Domino Go теперь существует для систем Windows 95, Windows NT, OS/390, HPUX и Solaris.
Есть причины предполагать, что сам по себе сервер WebSTAR более безопасен, чем серверы для Unix и Windows. Поскольку Macintosh не имеет оболочки ОС с командным языком, и поскольку он не позволяет удаленного входа (remote login) в систему, можно ожидать, что Mac по своей природе более безопасен, чем другие платформы. Эти ожидания пока оправдываются: до сих пор не было сообщений о проблемах с безопасностью ни в сервере WebStar, ни в его shareware предшественнике MacHTTP.
В начале 1996 года консорциум разработчиков программ Internet для Macintosh, в состав которого входит производитель WebStar - StarNine, объявил о награде в размере 10000 долларов любому, кто сможет прочесть защищенную паролем страницу Web на Macintosh под управлением WebStar. Как написано в статье с объявлением конкурса в Tidbits#317/04-Mar-96, в течение 45 дней никто не подал заявки на приз.
Хотя "проникнуть" на Macintosh обычным образом нельзя, могут обнаружиться следующие потенциальные лазейки:
На самом деле, повторный конкурс "взломай Мак" (Crack-a-Mac) в 1997 году, организованный шведской консалтинговой компанией, был не так успешен. В этом случае взломщик смог проникнуть на сервер и украсть защищенную страницу, используя для этого ошибки в двух надстройках сервера, предназначенных для удаленного администрирования и редактирования. Это является примером рисков, привносимых использованием скриптов CGI, дополнительных модулей и надстроек сервера. Детали истории и исправления модулей можно найти на http://hacke.infinit.se/
(Информация предоставлена Paul DuBois <dubois@primate.wisc.edu>).
Наверх, к Содержание | ||
Назад, к Безопасность на стороне клиента | Вперед,
к Библиография |
Lincoln D. Stein (lstein@w3.org)
Перевод - Дмитрий Громов
Last modified: Wed Jul 1 06:46:41 EDT 1998