Nieuwe bestanden van externe bron ( ook internet) worden standaard in Protected View geopend. Weinig tot niets aan de hand dus.

https://support.office.com/en-us/article/What-is-Protected-View-d6f09ac7-e6b9-4495-8e43-2bbcdbcb6653
Nah, dat bewerken inschakelen weiger ik standaard. Waarom iets gaan bewerken (en processen starten).
Voorwaarde is wel dat de herkomst/bron goed aangegeven wordt.
Zo'n attribuut (herkomst/bron) zou een standaard horen te zijn zoals datum/tijd. Het filesystem heeft de internettijd gemist.

"Volledige controle over het systeem," Moet ik daar adminrechten lezen? Zonder adminrechten heb je namelijk geen volledige controle, lijkt me? Volgens het bronartikel van McAfee gaat het om Full Code Execution, maar het zegt daarbij niet dat het adminrechten heeft. Enkel dat het elke vorm van geheugenbescherming omzeilt, maar ik neem aan dat dit gaat om het uitvoeren van code te bewerkstelligen.

Volgens mij klopt dit niet. In de originele tekst staat dat er ook gebruik gemaakt wordt van een lek in Windows zelf. Daarom lijkt het me dat alleen de Windows versies van Office kwetsbaar zijn.

Als men het over lekken in programma's heeft heeft dat meestal betrekking op dat programma i.c.m. één of meerdere Windows versies.

Daarom lijkt het me, dat alleen de Windows versies van Microsoft Office kwetsbaar zijn.
Andere office pakketten, als OpenOffice, LibreOffice, StarOffice, enz. zijn hier vast ongevoelig voor...........

Probeer het maar eens het bewerken is standaard uitgeschakeld in een full MS omgeving.
Er is een indeling gemaakt naar lokaal/machine intranet/lan internet/onbekend wat op een of andere manier als metadata gegeven doorgespeelt wordt. Ik mis het volledige concept in directory of wat dan ook dan aan het bestand gekoppeld wordt.

Nee dat concept ontbreekt in Linux-land net zoals het aanpakken van de informatie in CIA BIV classificatie waarna je de mtitigaties er tegenover zet. Aangezien Microsoft met een herkomst koppeling begonnen is wat ontbreekt in andere office tools is de meer logische conclusie dat MS-office het minst kwetsbaar is en bijvoorbeeld Libreoffice (met macros) kwetsbaar. Als je niet kan weten of het lokaal eigen of extern mogelijk gevaarlijk wat voor acties heb je dan nog?i https://help.libreoffice.org/Basic/Macro http://www.securityweek.com/hackers-can-exploit-libreoffice-flaw-rtf-files In ieder geval niet ongevoelig.
Een hta is iets met vbscript/jscript extensies een valt als een macro uitbreiding op html te zien.

Waarom begin je nu weer te bashen ?
Het enige dat ik wilde opmerken, is dat Office een algemene naam is en dat je wel moet wijzen naar het bedoelde office pakket.
Dit, om misverstanden te voorkomen.

Het lijkt me niet in een filesystem thuis te horen. Office-documenten hebben namelijk geen eenduidige herkomst, er kunnen meerdere mensen aan gewerkt hebben op meerdere computers en als op één van die locaties iets vervelend is toegevoegd dan kan een enkelvoudige herkomst-indicatie nooit betrouwbaar aangeven of iets te vertrouwen is. En iets ingewikkelders hoort al snel niet meer in een filesystem thuis, dat raakt te verweven met de eigenschappen van specifieke applicaties.

Ik weet niet wat die herkomstkoppeling is, ik neem aan dat je meer bedoelt dan de metadata met dingen als een auteursnaam die LibreOffice gewoon ondersteunt.

Alle moderne officeformaten zijn ZIP-files met XML erin. XML is tekst die prima door versiebeheersoftware kan worden bestierd, compleet met een zeer fijnmazige vastlegging van wat precies door wie is gewijzigd en zelfs een goede afhandeling van parallelle bewerkingen door verschillende mensen in de vorm van historie die in verschillende takken splitst die later weer samenkomen.

Je kan zoiets in een office-formaat integreren, maar een documentbeheersysteem dat gespecialiseerd is in dat soort bewerkingen dat je meteen voor meer dan alleen office-documenten kan gebruiken zou wel eens een superieure oplossing kunnen zijn.

Nou ben ik niet thuis in documentbeheersystemen dus hoe goed ze zijn weet ik eigenlijk niet. Maar ik weet genoeg om te overzien dat alle benodigde technische bouwstenen voor dat soort dingen gewoon bestaan. Wie weet dat men bij LibreOffice vanuit de *nix-filosofie dat één programma één taak verricht wel vindt dat deze functionaliteit niet in office-documenten thuishoort maar in een systeem waarmee je ze beheert.

Als die herkomstindicatie die je bedoelt niet in LibreOffice zit en wel in MS Office hoeft dat dus geen symptoom van inferieuriteit van LibreOffice te zijn, het kan ook een symtoom zijn van een andere visie op hoe je functies over softwarecomponenten verdeelt.

Je CIA FBI BIV en andere iso27k data gouvernance en Microsoft voorkeur die niet aan de standaarden voldoen raken kant nog wal. Jouw concept klopt in je hoofd niet en andere tools doe conculderen helemaal mis natuurlijk. Linux BSD HPux hebben ewr niks mee te maken.

Het enige wat ik wilde zeggen is dat er algemene vernieuwing in fileaccess zou moeten komen zodat het generiek -security by design- opgepakt kan worden. Het is toch raar dat we bestanden nog steeds benaderen alsof het om stand-alone machines gaat zoals in de jaren 60.

Daar heb je gelijk in. Mijn idee is iets eenvoudigs als een zonering van herkomst is iets uitgebreider dan https://technet.microsoft.com/en-us/library/dd883248(v=ws.10).aspx de indeling in herkomst/bron. File access via unc names kan intranet of internet zone hebben.
Ms offices lijkt het op zijn eigen manier te doen https://support.office.com/nl-nl/article/Een-vertrouwde-locatie-voor-bestanden-maken-verwijderen-of-wijzigen-f5151879-25ea-4998-80a5-4208b3540a62 Voor office macros (specifiek op tool gericht) moet je het niet in het filesystem zetten.

Die met de herkomst/zonering denk ik wel goed in het filesystem. Als 0 alles open is en 8 alles dicht gezet. met een run-time dan kan je met een actieve eigen setting beweren niets te open horend bij een lager niveau. Als een onbekende bestand level 8 meekrijgt mag er niets actief worden. een bestand met level 0 setting laat alles actief worden.
Bij binnenkomst van een bestand onbekend herkomst standaard waarde 8.

Heb je de titel ook goed gelezen van dit artikel?
Verdere specificaties zouden dan niet meer nodig moeten zijn.

De vraag of de Mac versies van Microsoft Office ook kwetsbaar zijn is logisch - en niet beantwoord.

Nee die vraag is niet logisch en impliciet wel beantwoord.

Nee en wel hierom

HTA formaat is voor Windows.
De uitvoer van de code lukt niet maar is wellicht wel leesbaar als inderdaad willekeurige code.

Alle versies van MS Office?
Nee ook niet want Office for Mac bestrijkt door de jaren heen verschillende OS versies die essentieel van elkaar verschillen.
Is het aannemelijk dat deze Windows code op zowel OS9 windows 2001 als OSX Office 2004 t/m heden werkt?
Nee, dat is buiten dat het windows code is niet waarschijnlijk, OS9 en OSX verschillen essentieel van elkaar en binnen OSX zijn er met een aantal stadia weer grote onderlinge verschillen te vinden.

Kletskous discussie om niks (wat betreft OSX dan).