Dziury w obecnym RH (z naniesionymi poprawkami z updates) (fwd)

[Marcin Bohosiewicz]

Witam po raz pierwszy :-)

> Proponuję rozpocząć nad tym lekką dyskusję. Temat niewątpliwie drażliwy
> ale i ważny.
Drażliwy to temat jest (jak zawsze z dziurami), ale jeśli PLD ma być
bezpieczne, to trzeba dużo na temat dyskutować.
> 
> Ja wiem o conajmniej jednej dziurze. Jest o dziura w lprm. Osoba która
> będzie chciała zająć się tym pakietem proszona jest o zajrzenie do zasobów
> Debianowych po to żeby ściągnąć z tamtąd patcha na BO jaki tam jest.
Czy dziura dotyczy wersji lpr-0.31-4, znajdującej się w updates do 5.1 ?
Jeśli tak, to od razu zabieram się do roboty :-)

I tutaj od razu mam wniosek formalny o podawanie wersji pakietów
podejrzanych o dziury (w przypadku rpm'ów - łącznie z numerem rewizji
i zaznaczeniem skąd pochodzi pakiet, bo z powodu braku koordynacji zdarza
się, że na contrib leży pakiet o tej samej wersji i rewizji co w dystrybucji
albo np w PLD, a zupełnie inaczej wyglądający).

> 
> Od dwuch dni walczę z pewnym osobnikiem tutaj na gruncie 3miejskim i mam w
> tej chwili początki do kłebka na conajmniej dwie, trzy jeszcze inne dziury
> (na ich ślady natknąłem się już blisko 4 miesiące temu), które nie było
> jeszcze dyskutowane na np. bugtraq czy innych takich miejscach. Z moich
> ustaleń wynika, że nie są to bynajmniej rzeczy zależne od tej czy innej
> dystrybucji.
Ja słyszałem o:
- screenie (zresztą na BUGTRAQ była poprawka, a niedługo przygotuję wersję
screen'a BEZ suida).
- sendmailach od 8.9.0 wzwyż

> 
> Niemniej, żeby to wydusić trzeba będzie zorganizować zbiorową
> "pielgrzymkę" w celu "porozmawiania" z pewnym odsobnikiem (zespół
> pielgrzymujący jest już skompletowany ;).
> 
> Przepraszam za kilka drobych opóźnień w wykonywaniu różnych rzeczy (np. 
> CVS) ale te sprawy są w ostatnich dwuch dniach dla mnie na tyle ważne, że
> mają wyższy priorytet nad PLD ale wynikają one włąśnie z pewnych spraw
> związanych z security kilku hostów którymi mam przyjemność kierować od
> strony technicznej.
> 
> Wszystkie pakiety, które potencjalnie mogą zawierać nieszczelne z racji
> podwyższonych uprawnień z jakimi chodzą programy z pakietu trzeba będzie
> na prawdę po kilka razy poprzeglądać pod kontem security i dobrze by było
> żeby osobnik próbujący zając się jakimś nowym pakietem zdobył się na
> porównaie z innymi dystrybucjami (lub bdzie musuiał to wykonać ktoś inny).
Proponuję zrobić spis wszystkich pakietów z których programy posiadają
ustawione bity SUID root i SGID <jakaś_grupa_systemowa> lub są uruchamiane z
uid=0 przy starcie systemu i przejrzeć je dokładnie.
Swoją drogą widzę możliwośc dość dużego ograniczenia ilości suidów poprzez
wykorzystanie modułu do kernela ttyperm (autor: Michał Zalewski), który
zapewnia właściwy chmod/chown plików /dev/tty* bez ustawionego bitu suid
na binarkach programów takich jak xterm,nxterm,screen,mc itp.

> 
> Najgorsze jest to, że środowisko rasowych włąmywaczy jest dość szczelnie
> zamknięte i wiem że niektóży z racji swojego chorobliwego podejścia do
> obszczewania różnych miejsc nie chętnie dzielą się różnymi inforamcjami.
> Jeżeli ktokolwiek posiada takie podziemne kontakty to proszony jest o ich
> cichą eksploatację ku ogulnemu porzyutkowi. Jeżeli uda nam się zamknąć
> kilka furtek, to już choćby najmniej to znacznie ułatwi nam wypłynięcie na
> szersze wody jeśli chodzi o uzyskanie dobrej opini i dalszego wsparcia w
> pracach.
Nie mogę nic tutaj ujawnić, ale takowe kontakty są...

> 
> W tej chwili mogę tylko tyle dodać, że należy uważać na wszelki ruch
> pochodzący z dopmeny arpg.gda.pl. Dalsze wyjaśnienia w tej materii w miarę
> postępu "prac". 
> 
> Poroponuję na razie jeśli chodzi o całość tej tematyki na koordynatora
> spraw w temacie security Marcina Bochosiewicza (alias RMF), który powinien
> być obecny na liście (Marcin jeżeli to czytasz to potwierdź, że możesz się
> tym zająć). Marcin ma lekkie zacięcie do tych spraw i po mimo tego, że
> może nie posiada super doświadczeń w tej materii to IMHO nadaje się do
> powyższego (będzie musiał tylko skrócić sobie język ;).
Oczywiście, akurat dobrze się składa, że będę robił "serwer-fortecę"
dla obsługi kont shellowych w pewnej firmie w pewnym mieście i będę
musiał dokładnie przeanalizować potencjalne możliwości włamania....
Ponieważ problem "security" jest dla mnie szczegolnie ważny - chcę spać 
"w miarę" spokojnie... z chęcią zajmę się security PLD, tak by dziury
nie były zmorą tej dystrybucji....
> 
> Osoba zajmująca się powyższym powinna być wymieniona w "PLD who is
> who" i będzie do pewnego stopnia odpowiedzialna za całą tą materię. Tzn,
> dobrze by było żeby może w mniejszym stopniu zajmowała się sprawami
> bierzącymi związanymi z dystrybucją i żeby skupiała się na zorganizowania
> sobie własnej siatki ludzi i powiązań nie koniecznie jawnych.
Oczywiście, gdyż w przypadku security najważniejszy jest czas, bo to
przypomina zabawę w kotka i myszkę - kto szybszy - administrator czy
hackerzy... dlatego też postulowałbym stworzenie listy PLD-secuirty,
na którą mógłby się zapisać każdy, a byłaby to lista dystrybucyjna, służąca
do szybkiego powiadamiania o zagrożeniach i ich usuwaniu.
> 
> Od razu uprzedzam, że pracy nad tym może by jednak trochę. W -devel
> wprowadzamy narzędzia do ipv6, które tylko działają (nie koniecznie
> jeszcze poprawnie). Ilość potencjanych dziur w tej części może być duża.
Tak, żeby IPv6 nie było taką puszką Pandory jak wczesne wersje glibc'a,
w których dziury to był istny horror....
> 
> Marcin PLS o potwierdzenie, że się zgadzasz lub nie.
Potwierdzam, tylko się troszkę muszę rozejrzeć co jest już w PLD zrobione
- spece od stable juz analizuję, ale devel'a jeszcze nie....
O całej sprawie kooczek mi powiedzial niedawno, więc muszę jeszcze chwilę
poczytać co jest już zrobione i załapać jakie w teamie panują zasady...

Pozdrawiam z Krakowa,

Marcin

-- 
-| == Marcin Bohosiewicz            marcus w venus.wis.pk.edu.pl == |-
-| == tel. +48 (0-601) 48-50-97     marcus w krakow.linux.org.pl == |-
-| == Strona Domowa    -    http://venus.wis.pk.edu.pl/marcus/ == |-
-| == PLUG - Komisja Rewizyjna    -   http://www.linux.org.pl/ == |-