17:50
22/8/2011
22/8/2011
Uwaga! Jeśli crypt() jest wywołana z MD5 salts, wypluwa tylko wartość “soli”. Wywołania crypt() z “solami” DES i BLOWFISH działają poprawnie.
Błąd jest o tyle ciekawy, że jeśli strona wykorzystuje uwierzytelnienie via crypt($haslo, $md5salt), to wynik tej operacji będzie prawdziwy dla każdego hasła, a zatem można się komuś zalogować na konto z dowolnym hasłem ;)
Posłuchaj jednego z naszych 8 cyberwykładów. Wiedzę podajemy z humorem i w przystępny dla każdego pracownika sposób. Zdalnie lub u Ciebie w firmie. Kliknij tu i zobacz opisy wykładów!
Każdy powinien zobaczyć te webinary! Praktyczna wiedza i zrozumiały język. 6 topowych tematów — kliknij tutaj i zobacz szczegółowe opisy oraz darmowy webinar.
Za każdym razem jak wydaje się że PHP jest skopane do granic możliwości, przesuwają granice możliwości.
Ktoś przeglądał może ichniego SVNa żeby zobaczyć po co w ogóle ruszali kod do crypta?
Meh, przesadzasz – bugi zdarzają się każdemu. Najważniejsze że zauważono i naprawiono i będzie już ok w następnej wersji.
Swoją drogą to ciekawy dylemat jest… Updateować systemy jak tylko się pojawiają nowe wersje (żeby załatać ewentualne poprzednie dziury), czy zaczekać jakiś (jak długi?) czas na wypadek gdyby wyszło tak jak w tym przypadku? ;-)
W przypadku PHP *nigdy* nie instalować na żywioł. Bug z notki to co prawda dość jaskrawy przykład ale nie pamiętam żadnego upgrade’u (o trzeci numer wersji), który by nic nikomu nie zepsuł.
W przypadku innego softu można przejrzeć notatki do wydania — i działać zależnie od powagi problemów, które danej instalacji dotyczą.
Jądro (jeżeli to Linux) to w ramach jednego -stable raczej można w ciemno instalować, chociaż i tu zdarzały się poważne regresje.
No cóż, obecny kernel 2.6.40 ma tyle błędów, że trzeba było go nazwać 3.0 (na kilku maszynach działa, na kilku innych regularnie Oopsuje).
A w PHP zdarzały się już większej klasy błędy, choć trzeba przyznać, że dość szybko łatane. Niestety w to wchodzi inercja przygotowania paczek dystrybucji, które przedłużają cały cykl.
“No cóż, obecny kernel 2.6.40 ma tyle błędów, że trzeba było go nazwać 3.0”.
Płetwy mi opadły. Chyba że to ironia taka. (hint: 3.0 nie nazywa się 2.6.40 tylko i wyłącznie z powodu fanaberii Linusa). Fakt że bywały lepsze wydania ale z numerem wersji to ma niewiele wspólnego (tyle że rozmaite narzędzia są strasznie zdziwione że im `uname -r` nie pasuje do /^2\.[46]\.\d+/)
Tak, to była ironia, umknęła mi emotikona ;) przy pierwszym zdaniu. Chociaż zdanie też odnosi się do wielu wypowiedzi na sieci, gdzie ludkowie śmieją się z ilości błędów wytykając właśnie, że zmiana numeracji przysporzyła tylu błędów, bo przecież w linii stabilnej/bez zmiany numeracji było by to nie do pomyślenia – oczywiście nadal ironicznie.
Dla ciekawskich, commit psujący crypt():
http://svn.php.net/viewvc?view=revision&revision=314438
Zmiany wyglądały tak:
strcat(passwd, “$”); //dobrze
strncat(passwd, “$”, 1); // jeszcze dobrze
strlcat(passwd, “$”, 1); // źle, commiter nie odróżnia strncat od strlcat!
strcat(passwd, “$”); // w końcu jak było… dlaczego nie strlcat(passwd, “$”, 2); ?
Nie ma to jak beztroskie masowe commity pt. “usunę wszystkie wystąpienia X” oraz nieznajomość dokumentacji języka…