Názory k článku Postřehy z bezpečnosti: zmrtvýchvstání maker v dokumentech Office

blokování vybraných služeb Apple, jako jsou FaceTime hovory
Nemají být blokované FaceTime jako takové, ale jen příchozí od kontaktů, kterým uživatel dosud nevolal:
Incoming invitations and service requests, like FaceTime calls, are blocked if you've never called the person before.

Já ta makra nechápu. Jejich primárním účelem je modifikovat dokument, ve kterém jsou spuštěna – tím nemohou nijak škodit. Škodit mohou funkcemi navíc – čtením a zápisem na filesystém, spouštěním externích programů nebo komponent, síťovou komunikací. Představoval bych si, že tohle je v makrojazyce pár funkcí, které je možné izolovat a spouštět je jenom na základě samostatného oprávnění.

Makra v dokumentech = povolený VBA. Tedy v podstatě interpreter víceméně plnotučného programovacího jazyka
To že to umí modifikovat buňky v excelu je sice nejpoužívanější, ale poměrně úzká část jeho možností.

Nejde o programovací jazyk, ale k čemu má přístup ve svém běhovém prostředí. JavaScript je také plnotučný programovací jazyk, přesto jím v prohlížeči nejde napáchat žádné škody (pokud není někde chyba), protože má k vnějšímu světu přístup jenom prostřednictvím sady API, kde jsou ty nebezpečné funkce vždy chráněné samostatným oprávněním.

Sice neznám možnosti VBA, ale pokud by to bylo takhle jednoduché, pak je otázkou, prož zanikla třeba Flash? Taky jde přeci jen o vykreslování do Canvas prohlížeče a těch pár přesahujících metod by šlo nějak opouzdřit :-)

Flash podle mne neměl problém s voláním API, ale a chybami interpretu (buffer overflow apod.).

Protoze se nejednalo o vykreslovani do canvas, ale o binarni plugin, canvas element v te dobe neexistoval. Emulace flashe kreslici do canvas jsou bezpecne.

Tady je otázka, co od maker chcete. A v případě MS Office od nich chcete možnost načítat soubory z filesystému, měnit je a ukládat. Chcete možnost dělat HTTP dotazy včetně POST. Chcete umět si přes OLE Automation (COM, ActiveX nebo jak se to vlastně dneska jmenuje) povídat s jinou aplikací. Chcete možnost přistupovat do všelijakých databází, ať již internetových nebo lokálních souborových.

Prostě to není o tom napsat si makro na změnu velikosti písma. Je to o tom napsat si makra dotazující se do databází, načítajících a procesujících soubory, exportující soubory. Ale hlavní problém je možnost používat "ActiveX" komponenty registrované v OS.

"Dualita" maker v MS Office je ten problém. Na "skutečná makra" nic moc nepotřebujete a ochránit se to dá. Jenže VBA je tam také na "aplikace", kdy stiskem tlačítka stáhnete data z databáze, vyplníte je do šablony dokumentu, vyexportujete do pdf, ten soubor podepíšete a někam odešlete.

Některé funkce se nesnadno omezují (například "uložení dokumentu" je poměrně legitimní přístup k filesystému, nicméně pokud obsah zaměníte za malware...), jiné by mohly obecně vést ke znefunkčnění "wordovské aplikace" (spuštění externího programu, který udělá kouzlo z makra nedosažitelné...).

Ostatně, komplexní makra považuji za (nutné?) zlo spíše, než za užitečnou vlastnost.

Uložení dokumentu ukládá aktuální dokument. Tudíž útočník nemá jak nahradit obsah.
Ano, pokud makro spouští externí program, bylo by nepoužitelné (resp. by vyžadovalo od uživatele svolení ke spuštění toho programu). Jenže takových maker je menšina. A pořád mi připadá lepší znefunkčnit jenom taková makra než je vypnout úplně všechna (a pak zase všechna povolit).

Nezkusil jsem to, ale myšlenkový "proof-of-cocnept": obsah wordovského dokumentu nahradit obsahem spustitelného souboru - "save-as" - prostý text - jméno se "spustitelnou" příponou - odvolat několik posledních kroků - "save-as" - původní typ a jméno dokumentu. Čistě teoreticky by tak šlo uložit kód i bez přímého přístupu k filesystému.

VBA vůbec nebylo navržené s ohledem na bezpečnost - je to záležitost ještě z dob před internetem. Často se používá pro integraci dokumentů (přebíráte data odjinud, a někam jinam je zapisujete, můžete posílat maily, číst email schránku), jde z něj volat win32 API. Prostě taková noční můra sekuriťáka.

Čekal bych, že to volání win32 API půjde přes nějaké jedno místo, kde půjde omezit. Ale vím, že zabezpečit dodatečně něco, kde se s bezpečnostní vůbec nepočítalo, bývá hodně obtížné. Ale zajímalo by mne, kde je v tom VBA zakopaný pes.

Hodně jsem se kolem VBA a VB motal před 20 roky. Netuším jaký je stav dnes. Tipnul bych si, že bez docela zásadního rozbití zpětné kompatibility to nejde moc fixnout, a předpokládám, že se do toho moc nebude nikomu chtít hrabat. Je to mrtvá technologie, která se pořád dost používá. Pro malé věci je možnost propojit skript a data (dokument) dohromady relativně šikovná. Tehdy se cílelo na malé kanceláře. Pro větší organizace, pro větší aplikace je to ale šílenost, a nemyslím si, že office jsou dneska pro MS prioritou.

To chápu. Nicméně ve hře je úplné zrušení maker u souborů stažených z internetu, teď se znovu povolila. Nemyslím si, že je reálné makra nechat v dnešní podobě. A zároveň dost pochybuju, že je možné je zrušit.

Tam jde o to, že VBA umožňuje i takové use case:

1) v Excelu je seznam zaměstnanců s jejich platy
2) ve Wordu šablona oznamující, že se zaměstnanci X zvyšuje plat na Y
3) VBA makro dokáže ten seznam postupně projít, ze šablony vytvořit dokument a ten poslat e-mailem
4) navíc třeba ještě nějak označí v kalendáři, od kdy to zvýšení bude
5) a uloží si log s poslaným oznámením do Accessu (nebo něco takového...)

(neříkám, že bych to uměl udělat, ale už jsem podobné věci viděl, prostě to místní ajťák takto udělal za 1/20 ceny, za kterou by to udělal profík - a mnohdy se stejnými bezpenostními dírami :-p).

Za svého mládí jsem dělal takovou IT ambulanci, měl jsem několik klientů (firem) které byly postavené na podobné technologii. Přesně jak píšete – rezidentní IT mág jim po večerech slepil z různých kousků funkční ekvivalent CRM/ERP programu od Abry.

IT mág odešel, a po uplynutí nějaké doby se musely rychle řešit problémy jako např. že Seznam změnil vzhled nějaké stránky (tuším s kurzovním lístkem) a firmě přestal fungovat excel na tvorbu objednávek mezinárodní kontejnerové přepravy, atd. :-)

Jasně, ale jed mi o to, že by asi bylo lepší odříznout jen tyhle use case a zachovat zbytek maker, než odříznout makra úplně. Navíc předpokládám, že tyhle věci budou spíš interní, takže nevyžadují spouštět makra v souborech stažených z internetu (nebo makra podepisovat a povolit konkrétní podpisy).

Takováhle makra vznikala dávno předtím, než se zrodila mánie vše podepisovat. A ve spoustě firem fungují dodnes.

Jiná firma možná jo. Ale Microsoft přece v rámci zpětné kompatibility udržuje i bugy aby nerozbil nějaký rovnák na ohýbák. Proto je ten ekosystém tak nekonzistentní. Vždycky všechno zabetonují dřív než to dotáhnou. A pak se to snaží zabít a nahradit něčím novým.