Zoals ik https://technet.microsoft.com/en-us/library/security/4022344 lees en interpreteer is MMPE versie 1.1.13701.0 de *laatste* versie die *kwetsbaar* is. Versie 1.1.13704.0 is de eerste versie die niet kwetsbaar is.

Microsoft Security Advisory 4022344
https://technet.microsoft.com/en-us/library/security/4022344
First version of the Microsoft Malware Protection Engine with this vulnerability addressed: Version 1.1.13704.0

Volgens die informatie moet de versie van de engine dus niet 1.1.10701.0 of nieuwer zijn,
maar 1.1.13704.0 of nieuwer.


Edit:
Inmiddels al bijgewerkt door de redactie zie ik:

Mooi, dank voor het corrigeren.

"Door het versturen van een e-mail met een kwaadaardige bijlage of bij het bezoeken van een kwaadaardige website zou een aanvaller willekeurige code met systeemrechten kunnen uitvoeren als de virusscanner de inhoud van de e-mail of website scande."

Allemachtig, wat slecht is dit toch eigenlijk.

Klopt. Dit gebeurt nog vaker bij third-party AV-vendors.

Voor mensen die Norton AV draaien, waardoor je niet bij Windows Defender komt: ik heb net gechat met Norton en de live update patched alles.

N.B.
Geldt dat ook wel wanneer de Microsoft beveiligingssoftware is uitgeschakeld door andere beveiligingssoftware of door de gebruiker? Ik neem aan van niet. Ik neem aan dat de "built-in mechanism for the automatic detection and deployment of updates" dan eveneens uitgeschakeld is en dus niet werkt.

Ook was ik er niet volkomen zeker van of de kwetsbaarheid niet te misbruiken is wanneer de Microsoft beveiligingssoftware is uitgeschakeld. Ik vermoedde van niet, maar ik was er niet volkomen zeker van.
Aanvulling hierop,
naar aanleiding van de reactie van Anoniem (Blondie) van 15:00 uur:
Microsoft Security Advisory 4022344 vermeldt:
Zoals Blondie aangaf, als de Microsoft beveiligingssoftware is uitgeschakeld, en dus nooit scant, dan kan de kwetsbaarheid dus niet misbruikt worden, zo volgt uit die passage in Microsoft Security Advisory 4022344.

Niettemin lijkt het me niet onverstandig om zekerheidshalve de uitgeschakelde Microsoft beveiligingssoftware tijdelijk even in te schakelen, zodat de update automatisch kan worden gedownload en geïnstalleerd, en vervolgens te controleren of de Microsoft Malware Protection Engine correct is bijgewerkt naar versie 1.1.13704.0.
Vervolgens kan de Microsoft beveiligingssoftware dan weer worden uitgeschakeld.
 

Hoe kan een update van Norton een heel ander programma updaten? Van een andere vendor? Huh?

Van:
https://technet.microsoft.com/en-us/library/security/4022344
If the affected antimalware software has real-time protection turned on, the Microsoft Malware Protection Engine will scan files automatically, leading to exploitation of the vulnerability when the specially crafted file scanned. If real-time scanning is not enabled, the attacker would need to wait until a scheduled scan occurs in order for the vulnerability to be exploited. All systems running an affected version of antimalware software are primarily at risk.

Als Windows Defender nooit scant, loop je geen gevaar. Tenminste, zo interpreteer ik het.

~ Blondie

Dankjewel, Blondie.
Ik had daar overheen gelezen.
Ik vermoed dat je gelijk hebt.
Ik heb een aanvulling gemaakt in mijn eerdere post van 14:50 uur.

>ik heb net gechat met Norton en de live update patched alles.
>gechat met Norton ... live update patched alles
Not sure if troll.
No wait, pretty sure.

Wat vreemd is in de Kb van ms is dat enkel 64 bit systemen getroffen zijn en de 32 bit geen problemen hebben.
Dat duidt op gemist stuk data layout in software beheer.

Voor de concepten van deugdelijk alm mis ik nogal wat. Je wordt doodgegooid net de versiebeheertools om ontwikkelaars uit elkaar te houden. Welke afhankelijkheden met alle ci's er zijn bij ds artifacts mis ik. Niets over te vinden.
Nu is dat laatste veel belangrijker dan dat geruzie bij de code kloppers.

Voordeel is tenminste wel dat je na deze update niet weer hoeft te herstarten.

Zonder 'codekloppers' zou jij als data-analist geen werk hebben.
Dan hebben we het nog niet eens over controverses rondom gedrag van zelfbenoemde data-analisten.

Misschien een vraagje voor @Spiff ?

Zoals gewoonlijk installeer ik alles met de MS update catalog ... Alleen beveiliging.

Makkelijker kan M$ het niet maken ...

De betreffende update voor (o.a.) Windows Defender kon ik niet vinden en ook niet installeren. Defender was uitgeschekeld, speciaal voor de update had ik heb ingeschakeld en ook weer geupdated .. niks, noppes ... Natuurlijk maar weer uitgeschakeld.

Windows 7 64 bit.

Ik kan het natuurlijk later nog eens proberen ... zonder de "dependencies" (als dat de juiste term is) was ik er al niet eens aan begonnen.
Suggesties ?

Welke kb bedoel je precies? Ik zie helemaal geen referenties aan 32- of 64-bit in de in het artikel gelinkte pagina's.
Er kan een fout in software zitten zonder dat er een fout in de tools en procedures voor softwarebeheer zit. Dat een bug die door ontwikkelaars en testers gemist is pas geconstateerd wordt als de software live is gegaan is een open deur. Goede tools en procedures helpen de kwaliteit te verhogen maar ze vangen niet alles af.
Vraag je je nu af of Microsoft zelf wel gebruikt maakt van de tools die ze leveren voor softwarebeheer?
Welke ruzie?

Je bent heel warm. Nee ik ben niet een echte data analist of business analyst (naam 40 jaar terug) hoewel ik er dicht tegen aan zit. Ik voel me meer een hardcore ict, dat is ook mijn achtergrond.
Die controverses tussen ict data analisten en de policies met alle ethiek zouden niet mogen bestaan. Ja ik heb gezien hoe marketing oplossingen er door kwamen omdat ict service niet voldeed. Ik heb gezien hoe er met data omgesprongen werd omdat ..... het veel beter en eenvoudiger kon (goedkoper).

Dat is nu net de reden waarom ik me druk maak. Data analisten hebben moeite met ict en data governance. Ict nerds hebben niets met data analisten. Die werelden moeten samen kunnen gaan betekent dat die controverses er uit dan wel verminderd moeten wprden.

https://technet.microsoft.com/library/security/2846338
Door geklikt uit de deployment information in de link hierboven. In het artikel. Beter kijkend zie ik nu een datum van 2013 staan. Waarom dat is geen idee verkeerde link of standaard structureel.


Als je versiebeheertool inzet dan zie je de aandacht op het bouwen dat de bouwers elkaar niet in de weg zitten elkaars code overschrijven dan wel te niet doen. (de ruzies)

In het uitrollen van releases en veranderingen is het veel belangrijker om afhankelijkheden en impact in koppelvlakken goed op te lossen. Daar zie je niets van in de tools.
Inderdaad zoals je stelt er kunnen fouten in de software zitten zonder dat de bouwers en testers het merken. Als ze zich verschuilen achter dat ze de processen en instructies voor de tools goed gevolgd hebben blijft het dweilen met de kraam open. De impact en afhankelijkheden ...

De vraag of de Tools voor scm zelf goed ingezet hebben is een aardige. Ooit meegemaakt (llang geleden) dat de leverancier die scm tools leverde zelf de laatste fixes vergeten had in wen nieuwe versie. Kwam er fraai uit net testen.

Dank.
"For more information about the affected software" staat er bij de link. Ik vermoed dat ze naar een vergelijkbare kwetsbaarheid in dezelfde software van een paar jaar terug verwijzen voor uitleg over de software. Of die "alleen x64"-opmerking ook nu van toepassing is vraag ik me af, dat zou bij de informatie van nu expliciet vermeld moeten worden.
Die zin rammelt zo dat ik me afvraag of wat er staat wel iets betekent. Mag ik suggereren dat je zelf leest wat je geschreven hebt en correcties aanbrengt voor je het verstuurt?

Goed, je lijkt het over conflicten te hebben die voortkomen uit parallel onderhoud. In de decennia dat ik als softwareontwikkelaar heb gewerkt heb ik dat soort ruzies niet meegemaakt. Natuurlijk kwam het voor dat je aan dezelfde software werkte (incidenteel, je kan het meeste ervan door een goede organisatie voor zijn), maar dat leverde geen ruzie op maar afstemming tussen mensen die professioneel genoeg waren om het samen op te lossen. Ik herken dit niet.

Updaten van Windows Defender onder Windows 7 gebeurt naar ik vermoed enkel bij ingeschakelde Windows Defender.
Na inschakelen van Windows Defender haalt Windows Defender zelf de laatst beschikbare update binnen.
Gebeurt dat niet, dan kun je Windows Defender naar updates laten zoeken via het interne menu:
Klik in Defender op het pijltje rechts naast de vraagteken-knop (Help) en klik vervolgens "Controleren op updates".
Nadat Defender de update heeft binnengehaald, klik opnieuw op het pijltje rechts naast de vraagteken-knop en klik "Over Windows Defender".
Controleer nu of de weergegeven "Versie van engine" 1.1.13704.0 (of nieuwer) is.

Ik zou Defender ook graag even inschakelen, zodat ik de update kan binnenhalen. Maar zelfs als ik mijn huidige antivirusprogramma tijdelijk deactiveer, krijg ik Defender niet opgestart. Ik hoop dan maar dat er op de achtergrond niets gebeurt waar ik geen zicht op heb. Waarom hebben ze dit nu niet even in de maandelijkse rollup gestopt?! Zou wel handig geweest zijn.

Ik vermeld niet een conflict dat uit het parallel onderhoud kan voort komen.
Ik heb het over de focus van de tools op dat mogelijke probleem. Zo'n tool wordt door een verkoper als het wondermiddel gebracht dan wel het is een architect/ manager die dat inbrengt. Het gaat er mij om dat er werkvoorschriften aan zo'n tool leidend en dicterend gemaakt worden terwijl het te vaak niet de werkelijke functionele eis is. De functionele is namelijk dat je het change/release proces in de productie omgeving op orde hebt. (welke versie is wanneer met welke data gebruikt).

Eens met je dat je in een niet zo groot team met de onderlinge afstemming makkelijk verder komt.
Maar waarom heb je dan zo'n complex tool daarvoor nodig?

Het wordt pas echt leuk als je het over onderdelen gaat hebben die helemaal niet in de bedachte processen en aanwezige tools passen. Dan heb je echt bonje. Wat voorbeelden:
- Probeer eens een DDL database change via GIT door te voeren,
- Koppel het testproces met de resultaten (pdf formaat) eens aan de overdracht van de componenten je mag het met PVCS proberen
- Op het moment dat er een aanpassing nodig is in een middelware component security setting/ generieke structure voor een bus / kernel (eg PAM) dan wordt een versiebeheer tool steeds meer een onmogelijkheid.
Wat je mist en veel belangrijker is dan het codeerwerk bij bouwers is een consistente afhankelijkheidscheck van ketens.

Overigens heb ik de strijden bij bouwers wel waargenomen. Met name in testdrivers testhulpmiddelen om de code te valideren gaat het snelst mis. Die aparte hulpmiddelen zou je ook productiestatus in een leefcyclus moeten brengen. Je wilt ze om anderen redenen mogelijk nooit op productiedata gebruiken.

Zoals je merkt zit de pijn niet op korte termijn projecten. Je moet het in de lange termijn concepten en lange termijn stabiliteit en kwaliteit zoeken waar dat speelt. Gaan we voor de korte termijn snel klaar project af of voor die lange termijn?

Nee, als ik wat miste kwam dat door een onbegrijpelijke zin van jou, en ook niet onbelangrijk gezien het onderwerp van het nieuwsbericht: ik mis totaal wat dit met Microsoft te maken heeft. Je voerde het allemaal aan als reactie op dat bericht, en ik zie niet in wat jouw ervaringen en meningen zeggen over wat er al dan niet bij Microsoft intern goed of fout is gegaan.

Toch nog wat reacties op wat je verder schreef:
Er zijn lieden die zich door verkopers laten inpakken, ja, dat probleem is niet specifiek voor dit onderwerp. En dergelijke tools komen echt niet altijd met in beton gegoten werkvoorschriften, het is gereedschap dat je inzet en inricht op de manier die bij jouw organisatie past. Als je ze goed inzet sluiten ze aan bij je functionele eisen. En dat dat niet altijd goed gedaan wordt klopt, maar ook dat is niet specifiek voor dit onderwerp.

Je noemt zelf git als voorbeeld. Een ontwikkelaar die alles alleen doet heeft daar al een hoop plezier van. Het is niet voor niets zo populair geworden.
Het SQL-statement waarin dat vastligt is tekst en is prima met git te beheren. Het uitvoeren van de wijziging in een DBMS is geen taak van een source code management tool. Wat je er wel weer prima mee kan beheren is het goed geteste script waarmee de change kan worden aangebracht in een DBMS. Is het probleem hier niet dat jij van een versiebeheertool voor broncode verwacht dat het meer doet dan versiebeheer voor broncode? Bouw je niet een voor het doelplatform geschikt pakket waarin de installatie, inclusief dergelijke scripts, in geregeld is? Dat is iets anders dan het versiebeheer van broncode.

PVCS ken ik niet, maar ook hier geldt dat je functies vermengt. Dat het procedureel een geheel is wil nog niet zeggen dat een tool dat een deel ervan voor zijn rekening neemt meteen voor alles ingezet moet worden, net zomin als ik van een schroevendraaier verwacht dat ik er het gat mee kan boren waar de schroef straks ingedraaid moet worden.
Als je het over PAM hebt is de kans groot dat de configuratie van die middleware-component een tekstbestand is. Voor het versiebeheer daarvan kan je gewoon versiebeheersoftware inzetten.

Je hebt dus in deze context ruzies bij "codekloppers" waargenomen? Het zal voorkomen, ik heb dat soort ruzies niet waargenomen. Generaliseer je dat zodat het lijkt alsof dat iets met Microsoft en deze bug te maken lijkt te hebben?

Ik weet niet waar je opeens kortetermijnprojecten vandaan haalt. Nagenoeg alle softwareontwikkeling die ik heb meegemaakt was voor de lange termijn bedoeld, systemen met een levensduur van tientallen jaren. Wat is je punt?