Názory k článku SCP má desítky let starou chybu, server může podvrhovat soubory

> objevil bezpečnostní chybu, která je v SCP klientech nejméně tři dekády.

To je nějaká časová smyčka, ne? Pokud si dobře vzpomínám, SSH vzniklo v roce 1995, což jsou dvě dekády a kousek zpátky.

-Yenya, autor RPM balíčků Ylonenova SSH pro Red Hat Linux/i386 někdy v roce 1998.

A co zranitelnost, že napadený server může poslat jiný obsah souboru, než na něm je? Třeba kopíruji ze vzdáleného serveru skript, server mi podstrčí škodlivý kód, já ho v dobré víře spustím (kdo kontroluje známý skript, který si právě zkopíroval z jiného serveru) a voilá, můj počítač je napadený! Na to CVE a fix je? ;)

Ked uz je raz server kompromitovany to je velky problem. A asi preto existuju aj tieto zranitelnosti v klientovi lebo autor klienta to chape rovnako. Ak je server kompromitovany pan boh nam pomahaj, klient uz si velmi nepomoze. Ale OK, opravia dalsie chyby, ide sa delej. Je dobre ze sa niekto venuje takymto veciam.

Pokud je server kompromitovan, v dobre vire se neda delat nic.

Přesně tak, měli by zavést zákon, že když je server kompromitován, měl by to jasně napsat do banneru při připojení, aby člověk věděl, kdy může použít dobrou víru a kdy ne! :-D

Tak ty klíče snad jsou v ~/.ssh/authori­zed_keys a ~/.ssh/known_hosts, ne? Nastavím pro /home/*/.ssh jako vlastníka root, povolení k zápisu jenom pro vlastníka, zákaz připojení roota na dálku a pak má útočník jedinou možnost - SSH + su s heslem na roota... Nějaký SCP se další spojení nepřidá. Ani klient, ani server. Ani oblbnutý uživatel.

Btw, pokud se dostaneš k serveru, jaká je šance, že máš klíče, kterýma se k danýmu stroji dá připojit?

SSH ale kontroluje prava ke konfiguraci, zmena vlastnictvi na roota by asi neprosla, ne?
Me by prislo zajimavejsi zakazat urcite cilove cesty. Tedy nejdrive data po siti zkopirovat do nejakeho docasneho lokalniho adresare, tam je zkontrolovat a az potom premistit do cile.

LOKÁLNĚ si nastavím práva a vlastníka k souborům v /home/$user/.ssh tak, aby je $user nemohl spustit.
SSH klient v kontextu uživatele $user pak nemůže měnit ani přidávat klíče. Uživatel $user si bez SU nemůže přidat další servery, na který se smí připojit. A dokonce ani smazat/přegenerovat klíče, takže ti odpadne řešení situací, že včera to fungovalo a dneska ne.

Zákaz přihlášení jako root je standardní doporučovaná věc, přihlásíš se jako jiný uživatel a přepneš se přes SU.

Co je v tom za problém?

A jak bys to chtěl řešit, pokud nemáš jinou informaci, než ti poskytuje ten server? Když máš k dispozici checksum pravého souboru, můžeš ověřit ten zkopírovaný soubor proti němu, ale to je tak všechno.

Úplně stejně, jako se ověří, že když dám scp server:adresar/.* ~, tak že se nemá přenést .ssh/authorized_ke­ys, ne? ;-)

A kdo ten blacklist bude udržovat? Kdo bude zodpovědný za to, že se nepřenese, co nemá?

Nebo přidáme ještě .ssh/disabled_files a .ssh/allowed_dirs ?

Nebo přidáme ještě .ssh/disabled_files a .ssh/allowed_dirs ?

To by bylo také zcela na lejno - řešíme obsah souboru, ne název.

Kde jsem mluvil o nějakém blacklistu?

Co to kecáš? Když nemáš obsah souboru s čím porovnat, jak chceš ověřit jeho správnost? Pokud jde o seznam souborů, které chceš kopírovat (včetně nějakého blacklistu, který zabrání přepisu některých lokálních souborů), ten si můžeš na klientovi definovat a porovnat se seznamem souborů, které přicházejí ze serveru, a podle toho se zachovat. S obsahem souboru to uděláš jak?

Vtip je v tom, že ani ten "správný" seznam souborů na klientovi (v některých případech) nesestavíš. Protože prostě nevíš, které soubory na serveru reálně jsou a které ne. Polopaticky. Dám příkaz:

scp server:adresar/.* ~

Server pošle soubor (třeba) .bashrc. Jak rozhodneš, jestli je "opravdový" a máš ho uložit a zkopírovat, nebo jestli je podvržený? Nezjistíš, stejně jako v mém příkladu nezjistíš jestli ten skript je nebo není podvržený (leda by ho prozkoumal člověk, což ovšem v 99.99% případů neudělá).

Celý ten můj příspěvek byl takový inteligenční test, jestli lidem tahle analogie dojde nebo ne. Ty jsi evidentně neprošel. Ale nevěš hlavu, aktuální skóre je že 7 lidi prošlo a 10 ne, takže jsi s většinou.

V zavere sa odporuca SFTP. To asi nieje integralna sucast SSH ako SCP? Teda treba instalovat dalsi SW na server?

jak mi může SCP přepsat Bash, když tomu klientovi zadávám plnou cestu kam se mají relativní cesty přicházející ze severu ukládat?

A vo tom je prave ten bug ze ten klient to nema osetrene takze sa to da.

Ne, bug je v tom, že server může poslat DO CÍLOVÉHO ADRESÁŘE i jiné soubory. Tedy problém je pouze pokud kopírujete do home. Že by server mohl uložit soubory i do adresáře nadřazeného cílovému se v popisu chyby nepíše. Viz: https://sintonen.fi/advisories/scp-client-multiple-vulnerabilities.txt

takze realne zneuziti = 0

Ne nula, ale k nule se to limitně blíží. Už proto, že remote AFAIK nezná cílový adresář, takže by soubory musel posílat naslepo. A když by se ti začaly při kopírování ze serveru v cílových adresářích objevovat .bashrc, .ssh/authorized_ke­ys a další soubory s podezřelým obsahem, tak bys asi zpozorněl.

Musel jsem se podívat na popis těch CVE - jestli to dobře chápu, tak problém je v zásadě, že napíšu "scp server:/soubor ." a server mi pošle a vytvoří "./tohle_jsi_necht­el".

Takže jediný opravený je klient pro studenty a frikulíny tolik nenáviděné Windows ?

Tvle to je zes chyba s velkym CH ... (a zdejsi banda tardu zas vede diskusi s velkym, D)

Co ze asi tak udela klient, kdyz se pripoji? Nj, rekne si o seznam souboru(a linku/adresaru) v aktualni ceste ... a co ze se asi tak dela, kdyz se neco kopiruje? Mno to samy jako lokalne ze ... tzn kdyz dam kopirovat celej folder, tak taky nikdo neresi, jesli tech souboru vevnitr je 10 nebo 11. Ale jo, muzeme to delat frikulinsky, nejdiv se nacte seznam vsech souboru (trebas 100k), pak se predhodi userovi ke kontrole (lol) a pak bude klient pekne jeden podruhym asi tak 100000x dyl kopirovat (megalol).

BTW: Prave sem analyzoval ... sambu, chova se uplne stejne. NFS jakbysmet ... jinak receno, kdyz mi "zlej" server pri kopirovani cely struktury do ni vlozi nejaky dalsi soubory, tak je ... zcela vzdy a kazdej klient (vcetne blbyho cp) ... co jinyho nez zkopiruje.

ale proc bych sakra neco takoveho delal? ;-)

Spravne, proc by nekdo chtel pristup ke tvym datum nebo nainstalovat malware, to se preci nikdy nikomu nestalo... OMFG opravdu je tak tezke pochopit ze je to bezpecnostni problem?

OMFG
Bezpecnostni problem je to jenom pro idioty, kteti napisou scp -r a poslou to do ~. Pro takove je hrozba i rm.

Jasne nekola a kdyz si napisu cp -r /cosi/odkudsi/ ~ ... tak ... jo aha, on mi kernel muze predhodit naprosto cokoli a prepsat tudiz ... trebas ten .bashrc ...

Ale on vubec neni problem v tom kernelu, problem je prece v cp, protoze to nekontroluje ... lol ...

Pořád nepochopil. Takže znova: Pokud napíšu

scp -r server:adresar ~

jak můžu jako klient zvalidovat, že serverem zaslané .bashrc je/není podvržené (má/nemá být přenesené)?

Za poslední roky se začínám přiklánět k názoru, že software bez zneužitelné bezpečnostní chyby prostě neexistuje.