User postgres

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Sob, 16 Sty 1999, 22:02:11 CET


On Sat, 16 Jan 1999, Wojtek Slusarczyk wrote:

> On Sat, 16 Jan 1999, [ISO-8859-2] Tomasz Kłoczko wrote:
> 
> > Wojtek ale sam się zastanów czy z tego cofnięcia uprawnień cokolwiek
> > wynika ?
> > Typowy doświadczony hacker nawet nie zadaje sobie trudu rozpoznawaniem
> > systemu. Nie bedzie się przejmował tym czy na binarkach jest 755 czy 711 i
> > czy widzi niektóre pliki konfiguracyjne czy nie.
> > Taki po wejściu (a jeżeli już mu się udało wejść jakoś to tym bardziej
> > security by obscurity już wida, że nie ma sensu) zasysa plik którego
> > spreparowany w ten sposób że jest to połączone w jeden kawałek skrypt i
> > spakowane archiwum. Po zrobieniu "chmod +x <wytrych>" uruchamia to co
> > ściągnął, a początkowy krypt odcina początek i rozpakowuje resztę w np.
> > /tmp i uruchamia wszystko co tam będzie jak leci.
> 
> "Dziad swoje baba swoje..." ;)
> 
> Tak.. wszystko ladnie pieknie.. tylko najpierw musi dostac tego
> shella rootowskiego

Wystarczy, że dostanie jakiego kolwiek .. root nie koniecznie musi być
ostatnim etapem. Na to są metody bynajmniej nie "informatyczbe" tylko
zachaczające o social spying. Inne metody to tzw. "metoda gumowej rurki"
ale tę to się stosuje już w ostateczności.

> ... Z tego co wyzej napisane wnioskuje, ze zakladasz z
> gory, ze bada z PLD jechali `jak z baranami na sped' i nie ma sensu sie
> trudzic bo i tak shackuja i tak ....

Kwestia w tym, że do pewnego poziomu "zainteresowania" atakującego można
się chronić metodami technicznymi, a do tych zmienianie uprawnień na
plikach nie należy. Do tej wysokości poprzeczki chroni przedewszystkim
mała ilość dziur (lub ich kompletny brak na szac teraźniejszy). Powyżej
to już uzupełnienie o ścisłą kontrola ruchu, która zakłada w dużej części
manualne nadzorowanie.

> Jezeli nawet domorosly roothsellowiec
> przybedzie z zabawkami z http://www.rootshell.com i walnie ze wszystkiego
> co ma to wieksze szanse ze pojawi mu sie na konsolli ~# ma na stable ...
> tak o jakies 90 % (bez przesady) jak na Tornadzie ... Zauwaz ze
> wiekszosc dziur jest w binarkach z Suidami

Wojtek .. nie ma sensu gadać w ten sposób czego jest potencjalnie więcej
czy mniej. Dzira jest dzira, a to na czym się ona zasadza jest najmniej
waną sprawą. Zmiana atrybutów tu nic nie pomaga gdyż dziura tkwi w
konstrukcji samego porogramu, a tę poprzwia się poprzez wypuszczenie
kolenej wersji pakietu.

> -- co przy polityce prowadzonej
> na develu szanse maleja do minimum ... nawet jak masz "S"-ki u nas sa to
> max 4710 (root.icmp ; root.lp itp ...) Jezeli nawet bedzie dziura w
> binarce to nie majac do niej dostepu nie jest w stanie jej wykorzystac ...

W tej chwili sendmail jest praktycznie w 99,999 % wszystkich instalacji
wrażliwy na pewien DoS (szczegóły mogę na priv). Ten DoS jest też obecny w
sendmailu jaki jest w devel. Czy to, że pozmieniane są uprawnienia, że
użytkownik nie ma dostępu od wewnątrz zmienia coś tu ? Nie gdyż jest to
coś _kompletnie_ niezależnego od tego co jest w sirodku tylko od wersji
samego sendmaila, a tu wrażliwe są wszystkie wersje (do 8.9.2, a ta wersja
własnie jest ostatnią oficjalną).

> Dalej mowisz 711 na binarkach -- to dlaczego w takim razie sam dajesz 
> 4711 .. a nie 4755 ?

Zacząłem temu ulegać bez większego zastanowienia. Ostatnio rozmawiałem z
kilkoma osobami przychylnymi PLD i te otworzyły mi oczy na pewne sprawy w
tym na nie skuteczność "securyty by obscurity". Energię poświęcona na
hołdowanie tej taktyce można spożytkować na inne cele.

> Dalej na co prawo do odczytu userom binarek ? Do
> czego to potrzebne ? Do czego uzytkownikom prawa do czytania w plikach 
> konfiguracyjnych (PAM, init-skrypty itp ...) ? 

Pawo odczytu nic nie zmienia jeśli chodzi o ochrone. Zmienia prędkość
podejmowania kroków obronnych (szybciej możesz swierdzić czy coś jest
zmienione czy nie). Poprostu SbO to jest tak jakby budowanie twierdzy w
której przez grubość murów nie można było sobie pozwolić na przestronne
korytaże i pomieszczenia wewnątrz, co urtudnia wszelkie działania wewnątrz
administrującemu.

> > Jeżeli chcesz przestraszyć dzieciarnie ktra zagląda na rootshell to nie
> > tędy droga, bo bać się jeązeli juz trzeba tych co już dzieciarnią nie są,
> > co potrafią skutecznie maskować swoje działania i wchodząc mają konkretny
> > cel, a nie tylko "obszczanie" hosta.
> 
> Nie o to chodzi ze ja sie boje i dlatego daje 711 na binarkach, czy 640 na
> plikach systemowych, ale dlatego ze nie ma sensu dawac praw do czytania
> skoro one sa zbedne ...

Spytam inaczej. Jaki jest sens zabraniania tego w świele pojawiania się
np. remote exploitów ?

> > Poprostu taki fachura (jeszcze raz) wogóle nawet nie będzie tracił czasu
> > na rozpoznanie systemu. Poprostu walnie z wszystkich rurek, a któraś jak
> > zrobi dziurkę to za pomocą dalszej części tego co miał w ściagniętym
> > archiwum posprząta cały bałagan tak, że nic nie zauważysz.
> 
> Qzwa ... jak przyjdzie fachura z zabawka o ktorej nic nikomu nie wiadomo,
> to klapa (ale nikt i nic temu nie zaradzi), jak natomisat przyjdzie buraq
> z "bombonierka-rootshell.c" to jest juz wyscig z czasem -- czy ja pierwszy
> sciagne late czy on wysadzi hosta ... przy czym jak nie maq dostepy do
> czesci binarek to tez moze miec problemy z odpaleniem bombonierki ...  

Spokojnie. Przed "bombonierka-rootshell.c" chroni nie bynajmniej SbO.
Chroni _tylko_ to żeby same pakiety miały odpowinie poprawki usuwające
wrażliwość na (po)znane sposoby ataku.

> > Wojtej .. Władywostok czy jeszcze dalej, wheel czy inna grupa. To czy +s
> > jest czy nie to nie ma nic do rzeczy w momencie kiedy w tym co pozostawisz
> > jest choć jedna dziura. Poprostu to co powziołeś sobie za cel jest tak
> > szilne jak najsłąbszy element tego co próbujesz bronić. To, że mury będą
> > na 100m nie robi nic skoro w jednym miejsu bedzie dziura przez którą wozem
> > będzie moząna przejechać.
> 
> Czy zagladales moze ostatnio do devela ? Czy widziales tam jakies
> stare/dziurawe pkaiety ? Czy ktos oprocz devela w takim tempie upgraduje
> soft (RH, Debian, Suse ) ? Czy sugerujesz mi, za mamy jakies dziury ?
> Moze i sa ale chyba o nich nikt poza grupa kilku osob nie wie ...  

Tak .. sugeruję/wiem (i mam na to zarówno exploita jak i patcha), że w
sendmailu jaki jest w devel jest DoS.

> > Co do developmentu, to obecnie budujemy pakiety z nie roota. Po co więc
> > ograniczać tą strefę sztucznie ?
> 
> Ja wszystko buduje z nie-roota ... nie jestem w grupie root, i nie mam
> zadnych problemow z praca ...

I przy identyfikacji pakietu jaki masz u sienbie nie muszisz korzystać z 
uprawnień niedostępnych zwykłemu użytkownikowi ? To masz inną wersję rpm-a
niż jest w devel lub inaczej skonfigurowaną niż pakiety seryjne (tak czy
inaczej).

> > I jeszcze raz .. ważne jest to aby to co robimy miało jak najmniej dziur,
> > a nie żeby groźnie wyglądało.
> 
> Zatem pokaz mi gdzie mam dziury na develu a ja je szybko usune...

Sendmail już pisałem.
I co z tego, że usuniesz tego DoS kiedy dalej będziesz(my) tracił kupę
czasu na SbO ? Zrozum, że apeluję o zaprzestanie niepotrzebnych działań,
działń które pochłaniają cenny czas, które utrudniają w tej intensyfikację
nad PLD wspólnie w devel i stable, które czynia proces przechodzenia
pakietów z devel do stable trudnym .. cztaj: czas poświęcony na deve
trzeba jeszcze pomnoeyć przez 1.x (x bliskie 9), żeby uzyskać pakiet do
stable. W tej cwili stawiam poprostu pytanie o sens pewnych działań, o to
czy obecny dualizm cxzemuś wogóle służy, czy PLD to są dwie dystrybucje
czy jedna w duch odmianach (produkcyjnej i rozwojowej).

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*



Więcej informacji o liście dyskusyjnej pld-devel-pl