Re: systemd
Egorov N.V. -> Artem Chuprina @ Mon, 16 Nov 2015 22:10:56 +0300:
>> EN> А у вас есть гарантия что вам отвечает ваша-же программа, или что
>> EN> программа той-же версии что ваша? Если нет, то валидация всех
>> EN> полей, особенно на переполнение, преобразование во внутренне
>> EN> представление и так далее.
>>
>> EN> Та же самба торпеду в протокол много раз получала, причем с
>> EN> исполнение произвольного кода - ну что-то не провалидировали.
>>
>> EN> С текстом устроить такую подлость гораздо сложнее...
>>
>> Ой, да ладно... SQL injection, Javascript injection, XSS...
>>
>> Проблема валидации недоверенных данных для текста стоит в тот же
>> полный рост.
EN> Разговор начался с оверхеда в текстовых протоколах, и быстроты разбора.
EN> Несомненно, все типы взаимодействия с недостоверными источниками
EN> требуют валидации. Просто не надо утверждать что валидация двоичных
EN> данных менее затратна, чем валидация текста.
Обратного тоже утверждать не стоит. Они имеют примерно равные затраты
на валидацию.
EN> Хочу отметить что все приведенные вами примеры атак и происходят в
EN> случае интерпретации текстового протокола как простого потока двоичных
EN> данных, и решается все семантическим, или хотя-бы грамматическим
EN> разбором поступивших данных.
Ну, тут палка как минимум о двух концах. Сами эти атаки возможны только
потому, что некий движок как раз занимается их грамматическим разбором и
последующим семантическим выполнением.
И проблема, как ни смешно, встает как раз оттого, что протокол-то
текстовый. Что в результате код и данные идут в одном потоке (текст -
очень слабо структурированная штука, в нем иначе не получается), и их
легко перепутать.
Другое дело, что в случае реализации чего бы то ни было на C/C++ любой
бинарный протокол обладает ровно тем же недостатком. Ключевые слова -
buffer overflow. А вот если памятью управляет рантайм языка, то
бинарный протокол внезапно может оказаться надежнее - идея засунуть
полученные оттуда данные в eval (или любой его аналог, начиная с
SQL-выражения) без предварительного даже не анализа, а преобразования,
немедленно оказывается дурацкой. Тупое втыкание СРАЗУ не работает. А
раз уж требуются какие-то прыжки и ужимки, то уж берется API, где код и
данные разделены (даже если там внутри они снова будут сложены в один
текст, как в случае с многострадальнм SQL).
Правда, как раз в случае с SQL быстро выясняется, что к нему не
существует API, дающих одновременно и разделение, и полную
функциональность... В большинстве даже банальный LIKE уже требует
injection и экранирования вручную, что уж говорить об ORDER BY
RANDOM()...
Reply to: