openssh

undefine@aramin.one.pl undefine w aramin.one.pl
Sob, 29 Cze 2002, 12:18:47 CEST


On Sat, Jun 29, 2002 at 01:54:24AM +0200, Jakub Bogusz wrote:
> > > > Była chyba kiedys mowa że pakiety w test powinny trochę czasu leżeć?
> > > > security jak security ale sytuacja gdy na ftp znajdują się pakiety które
> > > > zmuszają do wycieczki gdzies tam jest niedopuszczalna. jak ktoś chce
> > > > sobie szybciej zainstalować coś nowszego to ma test/nest.
> > > 
> > > Nie przesadzaj.
> > > To było pilne i wtedy nie było alternatywy.
> > jak to nie było?
> 
> Była tylko taka: świadome zostawienie dziurawej wersji.
nie, dlaczego? Każdy kto wiedział o dziurze mógłby sobie z test tego
spartaczonego openssh skompilować. A korzystając z test robi się to już
na własne ryzyko...

> > można było zostawić to w tescie. każdy kto wiedział o bugu mógłby sobie
> > na własne ryzyko sprawdzić openssh z testu.
> 
> Śledziłeś na bieżąco przebieg zdarzeń?
troszkę.

> Poprawka stała znana w momencie wypuszczenia wersji 3.4.
> Rzetelne informacje o dziurze pojawiły się parę godzin później.
> Natomiast przedtem - jakieś dwa dni po ukazaniu wersji 3.3 pojawiły się
> informacje o tym, że:
> - wersje < 3.3 mają dziurę dającą zdalnego roota
> - wersja 3.3 nie ma załatanej dziury, ale daje tylko bardzo ograniczony
>   dostęp do uid>0
> - warunki podatności nie były publicznie znane.
czy to powód żeby narażac wszystkich na tracenie kilku godzin na dojazd
do maszynek?
to może przy kolejnej dziurze zamiast binarki "dziurawego" programu na
ftp pojawi się pakiet z linkiem /bin/true -> /bin/dziurawy_program?
System przestanie mieć dziurę, a efekt będzie podobny do tego jaki
wystąpił teraz.

sory, ale jak dla mnie sytuacja że na ftp ląduje pakiet który jest
krytyczny do zdalnej administracji systemem i on _nie działa_ jest po
prostu niedopuszczalna.

> Jakub Bogusz    http://prioris.mini.pw.edu.pl/~qboosh/



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