Microsoft verhelpt actief aangevallen zerodaylek week later in Office voor Mac
Microsoft heeft een actief aangevallen zerodaylek nu ook in Office voor Mac verholpen, een week nadat de beveiligingsupdate voor de Windowsversies van de kantoorsoftware verscheen. Via de kwetsbaarheid, aangeduid als CVE-2021-42292, kan een aanvaller code op het systeem uitvoeren als er een speciaal geprepareerd Excel-document wordt geopend.
Het gaat hier om een "security feature bypass". Waarschijnlijk betreft het code die normaal pas na toestemming van de gebruiker wordt uitgevoerd, maar door de kwetsbaarheid verschijnt er vermoedelijk geen venster dat hierom vraag. Microsoft bracht op 9 november een beveiligingsupdate voor de kwetsbaarheid uit, maar niet voor Office voor Mac. Op het moment dat de patch verscheen werd er al misbruik van het lek gemaakt. Verdere details over de aanvallen zijn niet gegeven, behalve dat Microsoft het zerodaylek zelf ontdekte.
Nu is de beveiligingsupdate voor de kwetsbaarheid ook voor Office voor Mac verschenen. Die verhelpt daarnaast ook een andere kwetsbaarheid (CVE-2021-40442) waardoor remote code execution mogelijk is bij het openen van een document. Microsoft roept gebruikers van Office 2019 voor Mac en Office LTSC voor Mac 2021 op om de update te installeren en zo beschermd te zijn tegen de kwetsbaarheden.
Een patch moet ook getest worden en dat betekent dat de testers het probleem moeten kunnen reproduceren om later te verifiëren dat de update het fixt. Ik wil best geloven dat zoiets bij Microsoft in een MS omgeving sneller gaat dan onder Mac OS. (Of management geeft prioriteit aan Windows.) Een week later is niet eens erg veel.
Een patch moet ook getest worden en dat betekent dat de testers het probleem moeten kunnen reproduceren om later te verifiëren dat de update het fixt. Ik wil best geloven dat zoiets bij Microsoft in een MS omgeving sneller gaat dan onder Mac OS. (Of management geeft prioriteit aan Windows.) Een week later is niet eens erg veel.
De code van Office-for-Mac zal waarschijnlijk voor een groot deel gedeeld zijn met die van Office voor WIndows, maar ook voor een fors deel _niet_ .
De hele systeem API van MacOS _is_ significant anders - alles wat dingen met windows, muis/keyboard, filesystem doet _is_ anders.
Dan is waarschijnlijk de hele build omgeving anders, en mogelijk is ook de gemeenschappelijke code deels 'geport' naar Mac.
Als ik zo snel kijk, is er volgens mij geen Microsoft C++ compiler voor MacOS.
(en is Office in de loop van de geschiedenis geschreven in deels Assembler, dan C, dan C++ , en deels intern weer in Visual Basic ) .
Ik verwacht dat er best wat werk nodig was om ook die gemeenschappelijke code om te schrijven naar een compiler/ontwikkelomgeving die wel voor de Mac beschikbaar was.
Misschien niet vergelijkbaar, maar je ziet dat het heel langzaam gaat om de Linux kernel naast GCC ook door de clang compiler te kunnen laten compileren.
Ik weet niet hoe ze bij Microsoft Office en Office for Mac in sync houden, of ze een gezamelijke development tree hebben met allerlei ifdef MAC constructies, of dat "team mac" eens in de zoveel tijd een fork maakt en die gaat porten/aanpassen .
Ik vrees dat 'team windows' nog op heel veel plaatsen 32 bit support aanwezig moest laten, en dat is in MacOS vrij snel gedeprecate .
Al met al - goed mogelijk dat veel code - en deze bug - gedeeld zijn, maar het is aannemelijk dat ze niet makkelijk 1:1 de patch blindelings kunnen overnemen. "team mac" zal z'n eigen QA moeten doen , en zal een eigen release/prioriteits systeem hebben.
Een patch moet ook getest worden en dat betekent dat de testers het probleem moeten kunnen reproduceren om later te verifiëren dat de update het fixt. Ik wil best geloven dat zoiets bij Microsoft in een MS omgeving sneller gaat dan onder Mac OS. (Of management geeft prioriteit aan Windows.) Een week later is niet eens erg veel.
De code van Office-for-Mac zal waarschijnlijk voor een groot deel gedeeld zijn met die van Office voor WIndows, maar ook voor een fors deel _niet_ .
De hele systeem API van MacOS _is_ significant anders - alles wat dingen met windows, muis/keyboard, filesystem doet _is_ anders.
Dan is waarschijnlijk de hele build omgeving anders, en mogelijk is ook de gemeenschappelijke code deels 'geport' naar Mac.
Als ik zo snel kijk, is er volgens mij geen Microsoft C++ compiler voor MacOS.
(en is Office in de loop van de geschiedenis geschreven in deels Assembler, dan C, dan C++ , en deels intern weer in Visual Basic ) .
Ik verwacht dat er best wat werk nodig was om ook die gemeenschappelijke code om te schrijven naar een compiler/ontwikkelomgeving die wel voor de Mac beschikbaar was.
Misschien niet vergelijkbaar, maar je ziet dat het heel langzaam gaat om de Linux kernel naast GCC ook door de clang compiler te kunnen laten compileren.
Ik weet niet hoe ze bij Microsoft Office en Office for Mac in sync houden, of ze een gezamelijke development tree hebben met allerlei ifdef MAC constructies, of dat "team mac" eens in de zoveel tijd een fork maakt en die gaat porten/aanpassen .
Ik vrees dat 'team windows' nog op heel veel plaatsen 32 bit support aanwezig moest laten, en dat is in MacOS vrij snel gedeprecate .
Al met al - goed mogelijk dat veel code - en deze bug - gedeeld zijn, maar het is aannemelijk dat ze niet makkelijk 1:1 de patch blindelings kunnen overnemen. "team mac" zal z'n eigen QA moeten doen , en zal een eigen release/prioriteits systeem hebben.
Een patch moet ook getest worden en dat betekent dat de testers het probleem moeten kunnen reproduceren om later te verifiëren dat de update het fixt. Ik wil best geloven dat zoiets bij Microsoft in een MS omgeving sneller gaat dan onder Mac OS. (Of management geeft prioriteit aan Windows.) Een week later is niet eens erg veel.
De code van Office-for-Mac zal waarschijnlijk voor een groot deel gedeeld zijn met die van Office voor WIndows, maar ook voor een fors deel _niet_ .
De hele systeem API van MacOS _is_ significant anders - alles wat dingen met windows, muis/keyboard, filesystem doet _is_ anders.
Dan is waarschijnlijk de hele build omgeving anders, en mogelijk is ook de gemeenschappelijke code deels 'geport' naar Mac.
Als ik zo snel kijk, is er volgens mij geen Microsoft C++ compiler voor MacOS.
(en is Office in de loop van de geschiedenis geschreven in deels Assembler, dan C, dan C++ , en deels intern weer in Visual Basic ) .
Ik verwacht dat er best wat werk nodig was om ook die gemeenschappelijke code om te schrijven naar een compiler/ontwikkelomgeving die wel voor de Mac beschikbaar was.
Misschien niet vergelijkbaar, maar je ziet dat het heel langzaam gaat om de Linux kernel naast GCC ook door de clang compiler te kunnen laten compileren.
Ik weet niet hoe ze bij Microsoft Office en Office for Mac in sync houden, of ze een gezamelijke development tree hebben met allerlei ifdef MAC constructies, of dat "team mac" eens in de zoveel tijd een fork maakt en die gaat porten/aanpassen .
Ik vrees dat 'team windows' nog op heel veel plaatsen 32 bit support aanwezig moest laten, en dat is in MacOS vrij snel gedeprecate .
Al met al - goed mogelijk dat veel code - en deze bug - gedeeld zijn, maar het is aannemelijk dat ze niet makkelijk 1:1 de patch blindelings kunnen overnemen. "team mac" zal z'n eigen QA moeten doen , en zal een eigen release/prioriteits systeem hebben.
Interessant statement - maar bedoel je nou dat ze _overal_ de GNU compiler gebruiken, of alleen in de Office-voor-Mac ?
Het zou me toch verbazen als de Office voor Windows lijn niet met met de MS compiler gebouwd wordt.
En ja - als je codebase groot genoeg is dan heb je beslist _wat_ stukjes in de code waarin de ene en andere compiler verschillen.
Overigens - _minimaal_ die abstractielaag die je voorstelt is natuurlijk 'specifiek voor de Mac' .
Deze posting is gelocked. Reageren is niet meer mogelijk.
Specialiseer je in Forensisch ICT
Online informatieavond 19 november
Wil jij je specialiseren in digitaal forensisch onderzoek? Je kennis verbreden en tech-nische vaardigheden ontwikkelen? Ontdek de cursus- en opleidingsmogelijkheden van Hogeschool Leiden:
- Bachelor Informatica Forensisch ICT (deeltijd)
- Master Digital Forensics (vol- en deeltijd)
- Module Mobile Forensics
- Module Data Analytics
Interesse? Meld je aan!
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
