‘fork-bomba’ – na czym polega w porównaniu do zachowań zwykłych programów

Question

Py­ta­łem już o spo­sób unie­moż­li­wie­nia wy­ko­na­nia ‘fo­rk-bom­by’ na in­nym fo­rum, ale je­dy­ne od­po­wie­dzi, ja­kie otrzy­ma­łem, wska­zy­wa­ły na ko­nie­cz­ność ogra­ni­cze­nia mak­sy­mal­nej li­cz­by moż­li­wych do uru­cho­mie­nia przez dany program pro­ce­sów. Al­bo z uży­ciem “uli­mit”, al­bo z uży­ciem “cgro­u­ps”.

Je­d­nak ta­kie ogra­ni­cze­nie unie­moż­li­wia wy­ko­ny­wa­nie się zwyk­łych progra­mów, po­nie­waż one two­rzą wielokro­t­nie pro­ce­sy po­tom­ne na przyk­ład z “shel­la”. Spra­w­dzi­łem to prak­ty­cz­nie i na przyk­ład uru­cho­mie­nie progra­mu (uży­wają­ce­go “fo­rk” w spo­sób zwyk­ły) z li­nii ko­mend wy­ma­ga co naj­mniej 30 pro­ce­sów.

Pro­b­lem pole­ga na tym, że po ro­zpo­czę­ciu dzia­ła­nia ‘fo­rk-bom­by’ sys­tem unie­moż­li­wia jej za­trzy­ma­nie. Program “pkill” nie na­dąża z usu­wa­niem pro­ce­sów, częs­to nie moż­na się prze­łą­czyć na­wet do in­ne­go ter­mi­nala, by wy­ko­nać ja­kie­kol­wiek pole­ce­nie. Poza tym je­ś­li szko­d­li­wy program za­wie­ra ja­kieś me­cha­ni­zmy zmie­niają­ce na­zwę pro­ce­su i “pid” ro­dzi­ca, to wte­dy już w ogóle nic się nie da zro­bić rę­cz­nie.

“cgro­u­ps” umoż­li­wia tu­taj us­ta­wie­nie mak­sy­mal­ne­go wy­ko­rzys­ta­nia CPU przez grupę pro­ce­sów, ale prze­cież zwyk­ły program po­trze­buje dzia­łać z peł­ną prę­d­ko­ś­cią. Oraz us­ta­wie­nie in­nych pa­ra­me­trów jak mak­sy­mal­ne uży­cie pa­mię­ci ope­ra­cyj­nej, “swap”, czy wspom­nia­ną li­cz­bę pro­ce­sów po­tom­nych.

Na­to­miast nie su­ge­rując się po­wyż­szy­mi ro­zwią­za­nia­mi, któ­re ni­cze­go tak na­pra­wdę nie ro­zwią­zują, chciał­bym za­py­tać, na czym mia­ło­by pole­gać ogra­ni­cze­nie dzia­ła­nia ‘fo­rk-bom­by’, jej wykry­wa­nie. Ja­kie są ce­chy cha­rak­te­rys­ty­cz­ne ‘fo­rk-bom­by’ w po­ró­w­na­niu do zwyk­łych pro­ce­sów? By móc ewen­tu­al­nie za­im­ple­men­to­wać w sys­te­mie au­to­ma­ty­cz­ne wykry­wa­nie ‘fo­rk-bom­by’ i jej blo­ko­wa­nie.

Fak­tem jest, że ‘fo­rk-bom­ba’ two­rzy ma­so­wo kolej­ne pro­ce­sy w kró­t­kim cza­sie, więc może ja­kieś ogra­ni­cze­nie na ilość pro­ce­sów ut­wo­rzo­nych w je­d­nos­tce cza­su? W pus­tych przyk­ła­dach ‘fo­rk-bomb’ też te pro­ce­sy za­raz po ut­wo­rze­niu usu­wa (je­ś­li zdąży cza­so­wo). Ja­kieś in­ne po­my­s­ły, czym róż­ni się ‘fo­rk-bom­ba’ od zwyk­łe­go progra­mu uży­wają­ce­go “fo­rk”, tak by nie za­b­lo­ko­wać zwyk­łych progra­mów? I ja­ką moż­na by wpro­wa­dzić po­pra­w­kę do sys­te­mu? A może is­tnieje już ja­kieś ro­zwią­za­nie tego ty­pu, np. w sys­te­mach “ha­r­de­ned”?

Answer 1

Raczej nie ma dobrej odpowiedzi na Twoje pytanie.

Tj. to o co pytasz, to heurystyka oparta o zachowanie programu. Z definicji dla każdego heurystycznego rozwiązania znajdą się false-positives i false-negatives, tj. normalne programy, które z jakiegoś powodu spełnią zadane kryteria i zostaną zabite, jak i złośliwe fork-bomby, które nie zostaną wykryte i zabite. Co więcej, w przypadku gdy złośliwa osoba ma w miarę interaktywny dostęp do systemu dochodzi do typowej sytuacji "wyścigu zbrojeń", tj. atakujący modyfikuje fork-bombę żeby obejść detekcje, a admin modyfikuje detekcje żeby wykryć nową fork-bombę. I tak w kółko do końca świata (bo zbyt agresywna detekcja zacznie łapać normalne aplikacje).

Stąd też zazwyczaj walczy się z efektami (tak jak Ci pisali na tym innym forum), a nie próbuje wykryć zachowanie. Łatwiej jest ograniczyć zużycie CPU / liczbę procesów, i w razie czego porozmawiać z userem, który przesadza, niż zrobić idealną heurystykę.

Jeśli natomiast chcesz koniecznie iść w tym przypadku, rzuć sobie okiem na google scholar pod kątem fork bomb detection albo form bomb:

https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=fork+bomb&btnG=
https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=fork+bomb+detection&btnG=

Pomysłów pewnie jest masę, ale każdy ostatecznie można obejść (patrz problem "wyścigu zbrojeń").

Comments

Z linków które podałeś to generalnie są proponowane dwie metody:

1. Rozpoznawianie przez częstotliwość “fork” oparte na nazwie procesu. Do obejścia przez zmianę nazwy procesu.
2. Kwarantanna przez zmniejszanie zasobów dla procesów przekraczających limit “fork”. Nie zapobiega ‚zmuleniu’ systemu, tylko wolniej to następuje.

Pomyślałem jeszcze o trzeciej możliwej metodzie: opierać się na grupie procesów (na podstawie rodzica). Ale to jest do obejścia przez “setsid”.

Pozostaje tylko metoda identyfikacji na użytkownika. Co w systemach okienkowych nie spełnia swojego zadania.