Názor k článku Díra v bashi, které si 20 let nikdo nevšiml od Heron - Tak já si myslím, že co je bezpečně...

Tak já si myslím, že co je bezpečně se docela dobře ví. Alespoň mám tedy ze své praxe ten pocit. Docela dobře se to vysvětluje na kryptofunkcích. Pokud kryptologové označí md5 za prolomenou, nebo v případě sha1 za nalomenou (a dneska už stejně beztak slabou), tak ji nebudu používat. Konec diskuse. Mezitím se i o 10 let později md5 propaguje v knížkách... a v diskusích se vymýšlejí scénáře, kdy její prolomení jako že "nevadí".

O tom, že by se vstupy měly ošetřovat se taky ví už od počátků počítačů. Včera jsem narazil na úklidový skript k jednomu programu, který obsahoval 5 možností SQL Injection jako Brno. A to proto, že víc dotazů tam ani nebylo. Jak o řešení a také varování přes "řešením" sql injection se učí snad už v mateřské školce.

Uživatelský vstup z webu bych rozhodně nefláknul do skriptovacího jazyka, který ze své přirozenosti se snaží vyhodnotit všechno, co vyhodnotit lze. Protože, jak tu kdosi správně řekl, bash je zejména interaktivní příkazový interpret. Ano, při práci na řádce to neskutečně ulehčuje práci. Ale na psaní programů? Programů co berou vstupy z apriori nebezpečného prostředí?

Já mám na starosti několik set webserverů a pouze na jednom z nich je modul cgi. Musí se to nastavit, protože defaultně se nepoužívá nikde (alespoň v těch distribucích, co znám). (A kdyby za mnou někdo přišel, že chce cgi (bez https a bez přihlášení) a ještě jako bonus libovolný bash skript, tak odpověď je ne. Ani omylem. Ať jde za někým jiným, já se pod to nepodepíšu. A to nepíšu proto, že je zrovna na pořadu tato věc s bashem, tohle se prostě nedělá právě proto, že je velmi složité zajistit jakoukoliv bezpečnost.)

Ten jeden cgi je schovaný za http autentizací a celé to běží pochopitelně na https (jinak by to přihlašování nemělo žádný význam, když by si každý mohl odposlechnout heslo). (Jestli někdo provozuje autentizaci na nešifrovaném spojení, tak je to sice hezké, ale u počítačů nemá co dělat.) A pochopitelně je tam povolený pouze ten skript, který má být. Neexistuje možnost, jak tam spustit bash. A i kdyby, tak by běžel pouze s velmi omezenými oprávněními toho uživatele. A ten rozhodně nemá možnost číst kde co všechno.

Takže vrstvy:
* Celé je to šifrované.
* Za přihlášením.
* Omezené pouze na jeden skript.
* Omezený uživatel pro běh toho skriptu.

Kdybych byl co k čemu, tak si nastuduju selinux a bude to ještě zaselinuxované. Další vrstva.

Když cokoliv selže a ten útočník louskne https, auth, spustí bash, tak je mu to stejně na dvě věci. Nikam se nedostane.

Tohle považuji za základ. Za minimum.

Někdo tady uváděl prolomení SFTP a možnost získat shell. Takže co by se muselo stát:

* Útočníkem by musel být přímo majitel soukromého klíče, nebo někdo, kdo by jej získal. V každém případě by bylo rychle dohledatelné, odkud to přišlo.
* Potom by musel prolomit SFTP a získal by shell.

K čemu by se dostal? Dostal by se k datům, ke kterým by se dostal i bez prolomení onoho SFTP omezení. Nic víc. Měl by shell? Nevím jak kdo, ale já když už nastavuji omezení SSH pouze na SFTP, tak vždy společně s chrootem. A jako do toho chrootu opravdu bash nelinkuju. Takže sorry, ani ten shell by nezískal.

Opět několiv vstev:

* Soukromý klíč
* Prolomení SFTP
* Prolomení chroot
* Opět možnost další MAC vrstvy.

aby se dostal na shell s omezenými právy. I kdyby, tak co? Tak nic. Osobně shell nezakazuji ani když vím, že to budou používat jen pro nahrávání souborů. Nevidím k tomu důvod.

To jsou jen dva příklady, ale snad je vidět, co se stane, když se jedna z více vrstev poruší. Nestane se nic.

Já jsem admin, já ti neřeknu jak přesně to naprogramovat. Dovedu si představit, že ten skript na získávání dat od uživatele poběží jako zcela samostatný proces zcela vyhrazeného uživatele, který nebude mít žádná práva k souborům a tento proces po zpracování a ošetření dat za určitých podmínek je předá dál k dalšímu zpracování. Třeba jako frontu souborů na disku typu maildir (new, tmp, cur, přesypávání souborů pomocí rename). I to se dělá, ten skript tam může mít právo zápisu, ale už ne čtení, aby v případě nalomení bezpečnosti nešel přečíst obsah fronty.