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.
Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime
Ben jij er klaar voor om de leiding te nemen in het bevorderen van de regionale samen-werking in de strijd tegen gedigitaliseerde criminaliteit en cybercrime? Samen met collega's, politie en regionale en landelijke partners? Dan is de dynamische rol van Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime bij het Regionaal Samenwerkingsverband Integrale Veiligheid (RSIV) jouw op het lijf geschreven!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Cyber Security Trainer
"You know that feeling after you have been to the cinema and seen an exciting movie? It's the same after this training. I can only say that this is probably the BEST TRAINING that I've ever done!!!”
Are you ready for a challenge?
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.