Jakub jelen (inżynier bezpieczeństwa firmy Red Hat) zasugerował, że protokół SCP został sklasyfikowany jako przestarzały aby później przystąpić do jego eliminacji. Tak jak SCP jest koncepcyjnie zbliżony do RCP i dziedziczy problemy architektoniczne podstawy, które są źródłem potencjalnych słabych punktów.
W szczególności w SCP i RCP serwer akceptuje decyzję o tym, które pliki i katalogi wysłać do klienta, a klient postępuje zgodnie z instrukcjami serwera i sprawdza tylko poprawność zwróconych nazw obiektów.
Łącząc się z serwerem kontrolowanym przez atakującego, serwer może dostarczać inne pliki, co wielokrotnie prowadziło do identyfikacji luk w zabezpieczeniach.
Na przykład do niedawna klient sprawdzał tylko bieżący katalog, ale nie brał pod uwagę, że serwer może wydać plik o innej nazwie i nadpisać pliki, które nie były żądane (na przykład zamiast pliku „test.txt” żądany, serwer może wysłać plik o nazwie ».bashrc« i zostanie on zapisany przez klienta).
W poście opublikowanym przez Jakuba Jelena można przeczytać:
Witajcie użytkownicy Fedory! W ostatnich latach w protokole SCP pojawiło się kilka problemów, które doprowadziły do dyskusji, czy możemy się go pozbyć w początkowej fazie.
Większość głosów powiedziała, że używają SCP głównie do prostych kopii ad-hoc i ponieważ narzędzie sftp nie zapewnia prostego interfejsu do kopiowania jednego lub dwóch plików w tę iz powrotem, a ludzie są przyzwyczajeni tylko do pisania scp zamiast sftp.
Kolejnym problemem związanym z protokołem SCP jest funkcja przetwarzania argumentów.
Skoro o tym wspomniano podczas kopiowania plików na serwer zewnętrzny ścieżka pliku jest dodawana na końcu polecenia scp local, na przykład, po uruchomieniu na serwerze polecenia «scp / sourcefile remoteserver: 'touch / tmp / exploit.sh` / targetfile'», polecenie »touch / tmp / exploit.sh» i plik / tmp został utworzony /exploit.sh, dlatego ważne jest, aby używać poprawnych znaków ucieczki w scp.
Gdy scp jest używany do rekurencyjnego przekazywania zawartości katalogu (opcja „-r”) w systemach plików, które akceptują znak „” w nazwach plików, osoba atakująca może utworzyć plik z apostrofami i kod do uruchomienia.
W OpenSSH ten problem pozostaje nieskorygowany, ponieważ naprawianie go bez naruszania kompatybilności wstecznej jest kłopotliwe, na przykład uruchamianie poleceń sprawdzających, czy katalog istnieje przed skopiowaniem.
Poprzednie dyskusje pokazały, że scp jest zwykle używany do kopiowania plików z jednego systemu do drugiego.
Jednak wiele osób używa scp zamiast sftp ze względu na prostszy interfejs i oczywiste do kopiowania plików lub po prostu z przyzwyczajenia. Jakub sugeruje użycie domyślnej implementacji narzędzia scp, przekonwertowanego na protokół SFTP (w niektórych szczególnych przypadkach narzędzie udostępnia opcję „-M scp”, aby powrócić do protokołu SCP) lub dodanie trybu zgodności do narzędzia sftp co pozwala ci używać sftp in jako przezroczystego zamiennika scp.
Kilka miesięcy temu napisałem łatkę dla scp, aby używać SFTP wewnętrznie (z możliwością zmiany z powrotem za pomocą -M scp) i uruchomiłem ją pomyślnie w niektórych testach.
Ogólne opinie użytkowników były również bardzo pozytywne, więc chciałbym usłyszeć również od naszych użytkowników. Wciąż ma pewne ograniczenia (brakuje wsparcia, nie będzie działać, jeśli serwer nie będzie obsługiwał podsystemu sftp,…), ale powinno wystarczyć do większości typowych zastosowań.
Między ograniczeniami proponowanego podejścia, wspomniana jest niemożność wymiany danych z serwerami, które nie uruchamiają podsystemu sftp, oraz brak trybu transferu między dwoma hostami zewnętrznymi z tranzytem przez hosta lokalnego (tryb „-3”). Niektórzy użytkownicy zauważają również, że SFTP jest nieco w tyle za SCP pod względem przepustowości, co staje się bardziej zauważalne w przypadku słabych połączeń z dużym opóźnieniem.
Do testowania alternatywny pakiet openssh został już umieszczony w repozytorium copr, łatając go implementacją narzędzia scp na protokole SFTP.
źródło: https://lists.fedoraproject.org/