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.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?