Vlákno názorů k článku SCP má desítky let starou chybu, server může podvrhovat soubory od L. - A co zranitelnost, že napadený server může poslat...

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.