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

[Tomasz Kłoczko]

On Sat, 29 Aug 1998, Marcin Bohosiewicz wrote:
[..]
> > 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 :-)

Tak.

> 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).

Największe podejrzenia mam wobec perla i xterma (nadal).

> > 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).

Do czego ten suid jest tak naprawdę wykorzystywany ? Czy tylko do
zmienienia użytkownika na /dev/pty* ?
Z powyższego wnioskuję, że nie jest on bezwzględnie potrzebny (??)

> - sendmailach od 8.9.0 wzwyż

Hmm ... to którą wersję pakujemy do spable ?

[..]
> 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.

Marcin. Jeżeli bierzesz się za powyższe, to tą listą i jej prześwietleniem
będziesz muysaiał się zająć sam. My możemy Ci co najwyej pomagać.

> 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.

Krzysiek i reszta .. co Wy na to ?

> > 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.

Wydaje się to rozsądne. MNielibyśmy odseparowaną jedną tematykę. Co na to
zarządzający majordomo ?

> > 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....

Są duże szanse, że tak może być ;)

> > 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...

OK. Dziekuję.
Jeśli chodzi o spece to nie analizuj ich oddzielnie. Forma speców będzie
taka sama miedzy devel i stable. różnice będą przedwszystkim takie, że
pakiety są rekompilowane na glibc 2.0.9x i zawierają wszystkie potrzebne
do tego patche. Reszta jest reużywalna.

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*