Какие уязвимости возможны в ruby ​​с $ SAFE> = 1? - PullRequest
9 голосов
/ 05 августа 2010

Безопасный режим Ruby запрещает использование испорченных данных в потенциально опасных операциях.Он варьируется по уровням, 0 отключен, а затем 1-4 для уровней безопасности.Какие уязвимости возможны при включенном безопасном режиме?Знаете ли вы какие-либо номера CVE, выданные программе ruby, когда включен безопасный режим?Какие нарушения CWE (или семейства cwe) возможны при включенном безопасном режиме?

Ответы [ 2 ]

8 голосов
/ 25 августа 2010

Уровень $ SAFE не затрагивает все уязвимости на уровне приложений. Инъекционные атаки, которые не проходят через «небезопасную операцию», например межсайтовый скриптинг и SQL-инъекцию. Это включает в себя, более или менее, каждый класс уязвимости для веб-приложений, за исключением, возможно, локального и удаленного включения файлов. Смотрите OWASP Top 10 , $ SAFE не помогает со многими из них.

Уровень $ SAFE защищает вас от уязвимостей системного уровня. Если злоумышленник сможет записать код Ruby в файл в / tmp, он не сможет заставить вашу программу загрузить этот код, если $ SAFE> = 2.

И это, конечно, не включает никаких уязвимостей в самом Ruby. Это намного серьезнее и может полностью обойти $ SAFE.

Или обычные старые переполнения буфера, целочисленные переполнения и т. Д. В самом интерпретаторе Ruby, которые не имеют ничего общего с $ SAFE.

В Rails есть исторические уязвимости, которые возникают независимо от того, включен $ SAFE или нет. Это осложняется тем фактом, что пользовательский ввод хранится в приложениях Rails, и вредоносные данные могут появиться позже.

Отчеты об уязвимостях в приложениях на Ruby других , отличных от Rails и MRI, трудно найти.

Другая большая проблема с $ SAFE состоит в том, что нет реального списка (о котором я знаю), который бы описывал точно , что $ SAFE делает и не защищает. Единственное, что вы можете сделать, это найти ruby_safe_level в eval.c (это более старый eval.c из 1.8.4). В комментариях приведено это описание, но оно довольно расплывчато.

/* safe-level:
   0 - strings from streams/environment/ARGV are tainted (default)
   1 - no dangerous operation by tainted value
   2 - process/file operations prohibited
   3 - all generated objects are tainted
   4 - no global (non-tainted) variable modification/no direct output
*/

Я думаю, что я пытаюсь сказать, что $ SAFE - это все о безопасности системы. Это делает нормальную работу, но нет никакого реального способа точно знать, что находится и что не защищено. Это не должно быть вашей единственной линией защиты, это скорее защитная сетка, поэтому ничто не ускользает от «небезопасной операции». С другой стороны, это не имеет ничего общего с безопасностью приложений и не спасет ваши данные или пользователей от взлома. Кроме того, у MRI есть история уязвимостей, которые полностью обходят $ SAFE.

5 голосов
/ 06 августа 2010

Поскольку $SAFE >= 1 защищает вашу форму только с использованием испорченного ввода в небезопасных операциях, таких как eval и т. Д., Любая уязвимость в безопасном методе Ruby все равно проблема. Например, CVE-2009-4124 требует только, чтобы вы использовали функции ljust / center / rjust на входе, и по крайней мере моя версия ruby 1.8.7 рассматривает эти функции сейф . Вот фрагмент Ruby, который использует $SAFE = 4 и определенно будет уязвим для указанной выше проблемы:

$SAFE = 4; ARGV[0].ljust(ARGV[1].to_i)

Как правило, большинство уязвимостей Ruby все еще могут быть уязвимы, даже если скрипт Ruby работает в безопасном режиме.

Кроме того, с помощью $SAFE = 1 вы можете untaint переменных, и, следовательно, ваше приложение уязвимо, как только вы untaint и впоследствии используете эту переменную небезопасным способом, приложение все еще уязвимо.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...