-1
"Erre igazából a LUKS önmagában sosem biztosított garanciát, a legtöbb disk titkosításra praktikus módszer (CBC, CTR, XTS) kisebb-nagyobb mértékben bit-flipping támadásokra sebezhető."
Ez igaz CBC-re es CTR-re, de az XTS-re nem egeszen. Kifejezetten integritasvedelmet nyilvan az XTS sem biztosit, de ott kontrollaltan csak min. egy egesz AES blokk regebbi tartalmat tudod visszamasolni (vagy nem kontrollalt tartalommal felulirni). Az egy erdekes kerdes, hogy ez milyen attack model mellett kihasznalhato (szvsz min. traffic analysis kell hozza), de messze nem trivialis.
Masreszt letezik olyan device mapper target, ami kifejezetten integritas-ellenorzest vegez (es mielott valaki beleokoskodik: igen, hasznaljak ezeket androidon kivul is). A lenyeg: nem indulhatsz ki abbol, hogy ugysincs integritasvedelem.
A konkret vulnrol: egyreszt a linkelt oldalon eleg vilagosan leirjak: az, hogy "fizikai hozzaferes" csak egyesek fejeben egy kategoria, a gyakorlatban eleg nagy kulonbseg van akozott, hogy korlatlan ido all rendelkezesedre FIB-el modositani barmelyik IC-t az alaplapon es hogy talaltal a halon egy IP-KVM-et default jelszoval. Ez a vuln minden olyan esetben kihasznalhato, amikor a konzolhoz hozzaferesed van, a diszkhez meg nem. Kioszk, ATM, cloud, random szerver szereles alatt radugva egy IP-KVM-re, barmelyik gep tamperproof hazzal, etc.
Masreszt (amit nem irnak le): a grub es a szoban forgo szornyuseg bizony jobb hijan resze a trusted boot chain-nek, ergo itt nem csak egy random root promptod van, hanem egy root promptod abban a kornyezetben, ami vegigment a trusted boot check-en, tehat pl. kiolvashatod vele az FDE kulcsot a TPM-bol.
--
"You're NOT paranoid, we really are out to get you!"