Jakub jelen (Red Hat drošības inženieris) ierosināja SCP protokolu klasificēt kā novecojušu lai vēlāk turpinātu to novērst. Kā SCP ir konceptuāli tuvu RCP un pārņem arhitektūras problēmas pamati, kas ir potenciālās ievainojamības avots.
Jo īpaši SCP un RCP serveris pieņem lēmumu par to, kurus failus un direktorijus nosūtīt klientam, un klients seko servera norādījumiem un pārbauda tikai atgriezto objektu nosaukumu pareizību.
Savienojot ar serveri, kuru kontrolē uzbrucējs, serveris var piegādāt citus failus, kas vairākkārt ir novedis pie ievainojamību identificēšanas.
Piemēram, vēl nesen klients pārbaudīja tikai pašreizējo direktoriju, taču neņēma vērā, ka serveris var izdot failu ar citu nosaukumu un pārrakstīt failus, kas nav pieprasīti (piemēram, "test.txt" vietā pieprasīts, serveris var nosūtīt failu ar nosaukumu ». bashrc«, un to uzrakstīs klients).
Jakuba Jelenas publicētajā ierakstā varat lasīt šādi:
Sveiki Fedora lietotāji! Pēdējos gados SCP protokolā ir bijuši vairāki jautājumi, kas mūs vedina uz diskusijām, vai mēs varam no tā atbrīvoties sākotnējās fāzēs.
Lielākā daļa balsu teica, ka SCP galvenokārt izmanto vienkāršām ad-hoc kopijām un tāpēc, ka sftp lietderība nenodrošina vienkāršu saskarni viena vai divu failu kopēšanai turp un atpakaļ, kā arī tāpēc, ka cilvēki tiek izmantoti tikai scp rakstīšanai sftp vietā.
Vēl viena problēma ar SCP protokolu ir argumentu apstrādes funkcija.
Tā kā tas ir minēts kopējot failus uz ārējo serveri, faila ceļš tiek pievienots komandas scp beigām lokāli, piemēram, palaižot komandu «scp / sourcefile remoteserver: 'touch / tmp / exploit.sh` / targetfile'» serverī, komanda »touch / tmp / exploit.sh» un fails / tmp bija izveidots /exploit.sh, tāpēc scp ir svarīgi izmantot pareizas aizbēgšanas rakstzīmes.
Ja scp tiek izmantots, lai rekursīvi pārsūtītu direktoriju saturu (opcija "-r") failu sistēmās, kas failu nosaukumos pieņem rakstzīmi "", uzbrucējs var izveidot failu ar apostrofiem un padarīt to par palaišanas kodu.
OpenSSH šī problēma paliek neizlabota, jo ir grūti to labot, nesabojājot saderību ar atpakaļejošu datumu, piemēram, palaižot komandas, lai pārbaudītu, vai direktorijs pastāv, pirms tā kopēšanas.
Iepriekšējās diskusijas ir parādījušas, ka scp parasti izmanto failu kopēšanai no vienas sistēmas uz otru.
Tomēr, daudzi cilvēki izmanto scp nevis sftp vienkāršākas saskarnes dēļ un acīmredzami kopēt failus vai vienkārši pieraduma dēļ. Jakubs iesaka izmantot noklusējuma scp utilītu, kas pārveidota par SFTP protokola izmantošanu (dažos īpašos gadījumos utilīta nodrošina opciju "-M scp", lai atgrieztos pie SCP protokola), vai arī pievienot sftp utilītai saderības režīmu kas ļauj izmantot sftp kā caurspīdīgu scp aizstājēju.
Pirms dažiem mēnešiem es uzrakstīju plāksteri scp, lai iekšēji izmantotu SFTP (ar iespēju mainīt to atpakaļ, izmantojot -M scp), un veiksmīgi to izpildīju dažos testos.
Arī sākotnējā atgriezeniskā saite bija diezgan pozitīva, tāpēc es vēlētos dzirdēt arī mūsu lietotājus. Tam joprojām ir daži ierobežojumi (atbalsta trūkst, tas nedarbosies, ja serveris nedarbina sftp apakšsistēmu…), taču tam vajadzētu būt pietiekami labam visbiežāk izmantotajiem gadījumiem.
Starp ierobežojumiem piedāvāto pieeju, tiek pieminēta neiespējamība apmainīties ar datiem ar serveriem, kuri neuzsāk sftp apakšsistēmu, un pārsūtīšanas režīma neesamība starp diviem ārējiem resursdatoriem ar tranzītu caur vietējo resursdatoru ("-3" režīms). Daži lietotāji arī atzīmē, ka SFTP joslas platuma ziņā nedaudz atpaliek no SCP, kas kļūst pamanāmāks sliktos savienojumos ar lielu latentumu.
Pārbaudei alternatīvā pakete opensh jau ir ievietota koplietošanas krātuvē, aizlāpot to, izmantojot scp utilītu, izmantojot SFTP protokolu.
Fuente: https://lists.fedoraproject.org/