Ruby's safe mode uniemożliwia korzystanie ze skażonych danych przez potencjalnie niebezpieczne operacje. Różni się poziomami, 0 jest wyłączone, a następnie 1-4 poziomami bezpieczeństwa. Jakie luki są możliwe, gdy włączony jest tryb bezpieczny? Czy znasz jakieś numery CVE wydane dla programu ruby, gdy włączony jest tryb bezpieczny? Co CWE Violations (lub rodziny cwe) są możliwe przy włączonym trybie awaryjnym?
Wszystkie luki w poziomie aplikacji nie mają wpływu na poziom $ SAFE. Ataki wtrysku, które nie przechodzą przez "niebezpieczną operację", jak na przykład cross-site scripting i SQL injection. Obejmuje to mniej więcej wszystkie klasy luk w zabezpieczeniach aplikacji internetowych, z wyjątkiem być może lokalnego i zdalnego włączania plików. Zobacz OWASP Top 10, $ SAFE nie pomaga w wielu z nich.
Poziom $ SAFE chroni jednak nieco przed lukami na poziomie systemu. Jeśli atakujący jest w stanie napisać kod Ruby do pliku w/tmp, nie będzie wtedy w stanie oszukać twojego programu do załadowania tego kodu, jeśli $ SAFE> = 2.
I to oczywiście nie obejmuje wszelkie luki w zabezpieczeniach z samą Ruby. Są one znacznie poważniejsze i mogą całkowicie ominąć $ SAFE.
lub zwykły stary przepełnienia bufora, etc przepełnienia całkowitą, w sam interpreter Ruby, które nie mają nic wspólnego z $ SAFE.
Rails ma historię luki występujące czy $ SAFE jest włączony czy nie.Jest to skomplikowane ze względu na fakt, że dane wejściowe użytkownika są przechowywane w aplikacjach Rails, a złośliwe dane mogą pojawiać się ponownie w późniejszym czasie.
raporty Luka w zabezpieczeniach aplikacji Ruby inne niż Rails i MRI są trudne do zdobycia.
Kolejny duży problem z $ BEZPIECZNY jest brak prawdziwej listy (o której mi wiadomo), która określa dokładnie, co $ SAFE robi i nie chroni. Jedyna rzecz, jaką możesz zrobić, to wyszukać ruby_safe_level w eval.c (jest to starszy plik eval.c z wersji 1.8.4). Komentarze podają ten opis, ale jest on dość niejasny.
/* 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
*/
Domyślam się, że próbuję powiedzieć, że $ BEZPIECZNY to bezpieczeństwo systemu. Wykonuje dobrą pracę, ale nie ma prawdziwego sposobu, aby dokładnie wiedzieć, co jest i nie jest chronione. Nie powinna to być twoja jedyna linia obrony, to raczej sieć bezpieczeństwa, więc nic nie prześlizgnie się przez "niebezpieczną operację". Z drugiej strony nie ma nic wspólnego z bezpieczeństwem aplikacji i nie chroni twoich danych ani użytkowników przed włamaniem. Co więcej, MRI ma historię luk w zabezpieczeniach, które całkowicie ominęły $ SAFE.
Od $SAFE >= 1 chroni tylko ty tworząc za pomocą wejścia skażoną w niebezpiecznych operacji, takich jak eval i tak dalej, każda luka w bezpieczny metody Ruby nadal będzie problemem. Na przykład: CVE-2009-4124 wymaga tylko, aby użyć funkcji ljust//center/rjust na wejściu, a przynajmniej moja wersja ruby 1.8.7 uważa te funkcje za bezpieczne. Oto fragment, który wykorzystuje $SAFE = 4 Ruby, a na pewno byłoby narażone powyższego problemu:
$SAFE = 4; ARGV[0].ljust(ARGV[1].to_i)
Ogólnie, większość luk Ruby nadal może być kierowane nawet jeśli skrypt Ruby pracuje w trybie awaryjnym.
Również z $SAFE = 1, wy can untaint zmienne, a więc aplikacja jest podatny jak najszybciej untaint i następnie używać tej zmiennej w non-bezpieczny sposób, aplikacja jest wciąż zagrożone.
+1 świetny punkt, każda funkcja może być pochłaniaczem, jeśli cierpi z powodu uszkodzenia pamięci w języku lub w bibliotece. – rook
Czekaj, myślałem, że PHP był jedynym, na który wpłynął zdalny plik. Czy ruby nie akceptują adresu URL? Czy masz jakieś linki dotyczące ataków rubinowych LFI/RFI? – rook
Ruby nie jest tak naprawdę wrażliwa na RFI, o ile wiem. Jeśli jednak masz otwartą bibliotekę uri, każde otwarcie może potencjalnie otworzyć URL. Nie wpłynie to na wymaganie ani obciążenie (użyte do załadowania kodu Ruby), ale może potencjalnie wpłynąć na wszystko, co spowoduje otwarcie pliku. Chociaż warunki, w których może się to zdarzyć, są ograniczone, ponieważ musi być użyte jądro # open zamiast "File # open" (zwykle idiom do otwierania plików). Jest tak samo podatna na LFI, że ktoś jest na tyle głupi, aby wprowadzić dane użytkownika do ładunku lub wymagać oświadczenia. $ SAFE powinno to złapać. – AboutRuby
Kernel # open ma inne luki, które nie są od razu oczywiste. Na przykład, jeśli pierwszy znak jest potokiem, otworzy on podproces i użyje jego wyjścia jako strumienia plików. – AboutRuby