Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Microsoft dicht opnieuw door Google ontdekt Defender-lek

Door , 82 reacties

Tavis Ormandy, beveiligingsonderzoeker bij Googles Project Zero, heeft opnieuw een lek gevonden in de onderliggende anti-malware-engine van Windows Defender. Microsoft heeft het lek volgens de onderzoeker gedicht.

Ormandy meldt dat hij dit lek met behulp van een fuzzer vond in de Malware Protection Engine, oftewel MsMpEng, van Windows. Met behulp van een fuzzer kan een programma geautomatiseerd van willekeurige data of gedeeltelijk geldige inputs worden voorzien. Zo is het mogelijk om vast te stellen of het programma op een onverwachte manier reageert, bijvoorbeeld door te crashen. Via deze weg vond Ormandy een heap corruption in een api, die volgens hem een 'krachtige aanzet voor een exploit' vormt. Het zou niet moeilijk zijn om er gebruik van te maken.

Volgens de beveiligingsonderzoeker heeft Microsoft het lek, met kenmerk CVE-2017-8558, gedicht in versie 1.1.13903.0 van de engine. Ormandy heeft twee keer eerder lekken gevonden in Defender, dat gebeurde begin en eind mei. De engine, die naast Defender de basis vormt van Security Essentials en Endpoint Protection, is volgens de onderzoeker voorzien van een volledige x86-emulator, die geen sandbox heeft, standaard is ingeschakeld en op afstand toegankelijk is voor aanvallers. Op basis van zijn huidige bevinding vermoedt Ormandy dat de kwetsbare api nog nooit is onderworpen aan fuzzing.

Reacties (82)

Wijzig sortering
Fuzzing is ook een testing-techniek die nooit waterdicht kan zijn, net door zijn willekeurige aard. Het kan dus zijn dat MS ook aan fuzzing deed maar gewoon pech had dat de data die de crash veroorzaakt nooit gegenereerd werd.

Software testing is een hele kunst en er komt veel meer bij kijken dan wat je op het eerste zicht zou denken.
Dit dus. Software testing is tegenwoordig waarschijnlijk een lastiger vakgebied dan software bouwen (zo, die stelling is even gedeponeerd :o ). Het gemiddelde stukje commerciële software is al zodanig groot en complex dat alles even lichtjes raken in een test-cyclus al vrijwel onmogelijk is, laat staan alles goed doorzagen in test.

Neem dan een OS dat vele malen groter en complexer is dan een gemiddeld stukje software en het moge duidelijk zijn dat het soort bugs / issues waar het hier over gaat waarschijnlijk niet intern gevonden gaan worden.

Ga er maar vanuit dat code van Google en Apple ook soortgelijke kwetsbaarheden bevat...de vraag is of die ooit ontdekt gaan worden. Of je er iets over gaat lezen als dit gebeurt is dan weer een tweede.
Een ander probleem dat speelt bij WIndows is dat het initieel niet gebouwd is met "security by design". Je hebt dus te maken met heel veel p.v.g. (puin van gisteren).

Dat wit uiteraard niet zeggen dat software die gebouwd is met "security by design" geen fouten bevat.
Mwah, Windows NT (waarop iedere huidige versie gebouwd is) is wel secure by design; maar in eerste instantie vooral tegen de dreigingen uit begin jaren 90 (want dat was bekend)
Windows NT security by design? Grappenmaker. Standaard staan vele (onnodige) services aan en stonden poorten open. Wachtwoord database zonder salt. Drivers in kernel space. Etc, etc.

Ook is een groot deel aan code afkomstig van Windows 95.
Hoe kan de code van NT 3.1 (1993) afkomstig zijn van 95 (1995)?
Je hebt gelijk. Van NT 3.1 is die afkomstig van Windows 3.1. NT 4.0 is afkomstig van Windows 95.
Dat klopt niet; Windows NT was een aparte lijn van het Windows-besturingssysteem. Windows NT (New Technology) had een andere codebase dan de consumentenlijn, welke op MS-DOS was gebaseerd, zie ook Wikipedia.
Uit het door jouw gerefereerde Wikiperia artikel
Notably, in Windows NT 3.x, several I/O driver subsystems, such as video and printing, were user-mode subsystems. In Windows NT 4, the video, server, and printer spooler subsystems were moved into kernel mode. Windows NT's first GUI was strongly influenced by (and programmatically compatible with) that from Windows 3.1; Windows NT 4's interface was redesigned to match that of the brand new Windows 95, moving from the Program Manager to the Windows shell design.
Dat poorten openstaan en wgatever heeft bar weinig te maken met security by design in de kernel.

Als je op Debian of Ubuntu random poorten opengooit, is Linux dan onveilig?
Als je standaard allerlei services beschikbaar stelt die voor de gebruiker niet van belang zijn en de bijbehorende poorten staan open, dan ontstaat er (onnodige) mogelijkheden om de machine aan te vallen. Dus heeft het mijns inziens wel degelijk met security by design te maken.
Dat ze voor jou niet van belang zijn, betekend automatisch "is niet van belang voor de gebruiker".

En veiligheid begint niet, en houdt niet op bij je gebruiktOS/kernel.

Wil je dat Windows geen poorten opengooit, selecteer "dit is een openbaar netwerk".
Dat is tegenwoordig. Die optie was er voor Windows Vista niet.
Die was er voor vista ook.
Kun je daar een referentie van geven? Ik kan het niet vinden.
Dat is in windows Vista, ik bedoel van voor Windows Vista.
Windows XP:
https://www.microsoft.com...c_interface.mspx?mfr=true

Ook XP had de mogelijkheid onderscheid te maken, alleen manier waarop was wat anders. (direct aan het internet i.p.v. achter een modem). Publieke wifi access points waren toen ook nog niet echt een ding.
ICS onder XP moest je zelf configureren. Gewone gebruikers wisten er meestal niet eens van af. M.a.w. niet echt security by design.

Het feit dat je iets kunt beveiligen wil niet zeggen dat het security by design is.
Wifi access points waren toen niet zo'n ding. Ik snap je hele punt niet. Waarom maak je zo'n probleem over iets wat pas sinds Vista gemeengoed werd. Wifi gebruikte men niet, en lang niet iedereen had internet of een computer thuis.

Blabla niet veilig voor zaken die toen niet van belang waren.

Sowieso kwam die hele security focus pas rond XP, daarvoor werd security echt door niemand echy serieus genomen. Niet alleen MS. Heel de wereld kon security niet boeien.

Maar goed, zeik een heel OS af voor iets uit 2001. Goed bezig kerel, je bent echt een sterk argument aan het maken.
Daarbij komt ook nog eens dat de opdrachtgever vaak meer interesse heeft in de stabiliteit en functionaliteit van de programmatuur dan in de veiligheid. Het enige wat ik professioneel ben tegengekomen op het gebied van veiligheid testen, is het testen van Internet sites door onafhankelijke derde partijen.

En elke test werd er wel iets gevonden, is je code eindelijk helemaal in orde, dan is er wel een veiligheids probleem met SSL of je Internet server of het framework / libraries die je gebruikt etcetera. Gevolg is dat je elk jaar opnieuw kan testen om uberhaupt de boel een beetje veilig te houden. En die kosten lopen dan zo hard op, veel bedrijven nemen dan liever maar wat meer risico.
Dit dus. Software testing is tegenwoordig waarschijnlijk een lastiger vakgebied dan software bouwen (zo, die stelling is even gedeponeerd :o ).
Ik stel dan dat software bouwen per definitie lastiger is, want de software moet alle testen doorstaan. Er moet dus gebouwd worden + rekening houden met alle tesen die er op afgevuurd gaan worden ;)
Het is al heel lang niet meer zo dat 'alles getest kan worden' (dat is nooit zo geweest, maar goed, dan wordt het wel een erg theoretische discussie).

Binnen test driven developement worden er eerst testen bedacht en geïmplementeerd, dan volgt de software die door de testen heen moet komen. Ik zou zeggen dat het bouwen van een oplossing binnen een bekend en concreet kader makkelijker is dan het kader bedenken; dat kader moet er immers voor zorgen dat de oplossing 'aan alle eisen voldoen' waarbij die eisen vaak impliciet zijn en overal en nergens vandaan komen.

Als er geen test driven development toegepast wordt (wat doorgaans het geval is, vaak met hele goede redenen) dan zal het altijd heen en weer gaan; de testen zullen afhankelijk zijn van de oplossing / implementatie. De implementatie kan dus nooit rekening houden met alle testen, want de testen zullen altijd de gekozen oplossing in beschouwing nemen. We zitten dan in de hoek van de Amerikaanse school van testen, Exploratory testing etc. Wat in die situatie wat mij betreft testen het lastigere vakgebied maakt, is het verschil in scope; een ontwikkelaar krijg een vraag / opdracht voor een bepaald stuk functionaliteit binnen de scope van een stuk software. Van test wordt vervolgens verwacht dat dat specifieke stukje 'goed getest' wordt (en wat is daar precies de definitie van?) maar ook dat er geen onvoorziene gevolgenen zijn, waar dan ook in het geheel. En door dat laatste blijf ik bij mijn stelling O-)
Het blijft telkens verbazen dat de ruim 100.000 medewerkers van microsoft telkens door derden op gaten in hun software moet worden gewezen.
Er zijn een hoop bedrijven die dit doen. Voor zover ik weet controleert Microsoft ook gewoon de software van Google. Zo houden we het allemaal gewoon veilig, beter dat het op deze manier gebeurt dan niet, toch?
Is het dan gek dat ik andersom geen verhaal ken?

Ik zou de tussenstand wel willen zien (een kruistabel van alle bedrijven met het aantal bugs dat ze bij anderen vonden) :D

[edit]
Ik denk dat wat jij denkt, voor ons beide onmogelijk is om te denken, zonder zo'n kruistabel :+ (of andere vorm van stelling-validatie)

[Reactie gewijzigd door Flipull op 26 juni 2017 11:07]

Niet alle bedrijven gaan public met beveiligingslekken die ze vinden in software van andere instanties. Ik denk dat Microsoft een stuk "netter" omgaat met dit soort dingen.
Een adere discussie is natuurlijk is het "netjes" om beveiligingslekken openbaar te communiceren of moet je het stil houden?
Wat heeft Google meer dan Chromebooks waar Microsoft geen software voor uitbrengt en Android "another week, another exploit" waar Google eigenlijk al wel genoeg door derden op gaten gewezen wordt. 90 dagen en anders documenteren we de exploit? Alsof het gros van de Android gebruikers überhaupt de update krijgt als ze binnen die tijd een patch uitbrengen.

Heb hier een Android 5 toestel liggen: "Uw systeem is up to date". Sure :/
Vergis je niet. Google ontwikkelt vrij veel software, die je nu ook in mainstream OSS terecht komt. Brotli compressie is bijvoorbeeld deze week toegevoegd aan Apache (2.4.26). Ontwikkelaar: Google. Als daar een lek in zit, is Apache met mod_brotli ook lek. Ik heb geen idee of brotli compressie ook al beschikbaar is voor IIS, maar dat kan nooit lang duren. Google stond ook al aan de basis van het Spdy protocol, waar nghttp2 op voortbouwt.

Ook bij PHP-extensies zie ik steeds vaker Google software opduiken. V8/V8JS is maar 1 van de voorbeelden.

[Reactie gewijzigd door Jan-E op 27 juni 2017 04:52]

Ik ben niet op de hoogte van de huidige stand van zaken bij Microsoft qua open source en of ze Apache ook gebruiken intern, maar normaliter ga je alleen kijken naar gaten in software die je daadwerkelijk gebruikt. Het verhaal is dat Chrome op Windows draait en voor de veiligheid van Chrome gebruikers dus de onderlaag ook goed moet zijn en daarom onderzocht wordt door Google.

Zomaar een beetje gaan lopen zoeken bij een concurrent is natuurlijk een beetje vreemd als je het dan ook nog constant aan de grote klok gaat lopen hangen. Alsof Audi ineens een remmentest van BMW's gaat doen. Wat dat betreft heeft Microsoft dus alleen "wat te zoeken" bij Android, de rest van Google producten wordt niet gebruikt bij Microsoft.

[Reactie gewijzigd door BikkelZ op 26 juni 2017 21:18]

Andersom heeft ook op Tweakers gestaan, dus ja, gek?
Externen zien vaak eerder dingen die je als ontwikkelaar zelf over het hoofd ziet of als 'aangenomen kennis' beschouwt. Niet alleen in softwaredevelopment trouwens, maar met praktisch álles is dat zo.
Externen zien vaak eerder dingen die je als ontwikkelaar zelf over het hoofd ziet...
Dan is de oplossing toch simpel? Geef externen opdracht om de boel te onderzoeken. Bijv. de CCC inhuren.
Eh ja.. maar dat is toch ook wat Google nu doet? :) Tenminste, Google is in dit geval die derde partij..

Ik reageerde ook alleen maar op de stelling dat "100.000 mensen bij Microsoft telkens derden hebben die ze op gaten in de software wijzen". Ja; dat klopt - omdat natuurlijk lang niet al die 100.000 man (m/v) zich met Defender bezig houden, en de programmeurs die dat wél doen, soms zaken over het hoofd zien die voor anderen logisch zijn.
Eh ja.. maar dat is toch ook wat Google nu doet? :)
Maar blijkbaar heeft Microsoft het teveel laten liggen... Als je 1000 programmeurs hebt, heb je misschien wel 10.000 externen nodig om het een beetje door te spitten.
Hoe bepaal je dat ze teveel hebben laten liggen? Misschien hebben ze zelf wel meer dan 1000 bugs eruit gevist. Daarnaast is geen een stukje software bug vrij dus dat er bugs door andere worden gevonden is helemaal niet zo raar.
Ik vind het wel degelijk zeer raar als er security-bugs gevonden worden in security-software! Microsoft maakt gigantisch veel winst; geld genoeg om hogere eisen aan de software te stellen. En een betere software-policy invoeren: pas invoeren als het door externen zoals CCC en anderen als 'Zit uitstekend in elkaar' is beoordeeld. Bijvoorbeeld.
Wie zegt dat ze dat niet door externen hebben laten doen? Het is ten allen tijde mensen werk en elk complex stukje software heeft gewoon bugs. Je kunt nog zoveel eraan doen maar je krijgt nooit 100% garantie dat je bug vrij bent.
Windows en verreweg de meeste componenten zijn Closed Source, dus derden zoals de CCC kunnen de code helemaal niet controleren op security.
Wil Microsoft een betere naam krijgen op het gebied van security, dan moet het intern veel strenger worden inzake het toelaten van nieuwe code, moet de oude code goed doorgelicht worden, en bij voorkeur moet alles Open Source worden zodat honderdduizenden willekeurige programmeurs (als ze daar zin in hebben) mee kunnen kijken.

Dat Open Source gaat natuurlijk niet gebeuren. Van meer kwaliteit(scontrole) verwacht ik voorlopig ook niet veel; Microsoft is groot geworden door 'meer functionaliteit' ('gooi de extra code, software en opties er maar in; we zien wel waar het spaak loopt') en niet door 'meer security', en heeft dat beleid nog steeds. Dit zie je bijv. al door simpelweg te kijken naar verkeerde defaults die Microsoft nog steeds gebruikt, zoals het verbergen van extensies in explorer.
Dat het Closed Source is betekent niet dat derden er niet naar hebben gekeken. Door middel van contracten en NDAs krijgen derden dan inzicht in de closed source, dit is normaal in de software ontwikkeling wereld. Het Open Source argument houd in veel situaties niet stand want van die honderdduizend willekeurige programmeurs hebben misschien maar een handje vol echte kennis om zulke checks te doen en ze doen dat echt niet voor hun plezier. Goed voorbeeld is Linux, ookal was daar alles Open Source nog steeds worden daar grote security leaks gevonden die er al jaren in zitten.

Al je conclusies die je trekt zijn gebaseerd op aannames. In tegenstelling tot jou heb ik wel bronnen bij en heb ik samengewerkt met)Microsoft en daar is de mentaliteit echt niet van "gooi er maar extra code in en we zien wel". De QA afdeling is echt super groot bij Microsoft maar het is gewoon een feit dat je niet kunt voorkomen dat er bugs in zitten. Dat is gewoon een mythe.
Door middel van contracten en NDAs krijgen derden dan inzicht in de closed source, dit is normaal in de software ontwikkeling wereld.
Hackerclubs zoals de CCC krijgen geen toegang. Juist de kennis van dat soort groepen heb je nodig om mede te laten oordelen over de kwaliteit van je code (Windows) waar honderden miljoenen mensen gebruik van zullen maken.
De QA afdeling is echt super groot bij Microsoft
Tja, gezien de steeds weer opduikende virusgolven, waarbij 't toch echt bijna altijd om Windows-only PC's gaat, is die blijkbaar nog lang niet groot genoeg. QA lijkt me in dezen ook teveel symptoonbestrijding? Met een goed programmeerbeleid zou je eigenlijk al geen securty-gaten moeten hebben. Bug-loos programmeren is inderdaad erg moeilijk. Maar daar waar 't gaat om security, moet MS gewoon veel beter zijn best doen. (Dat er een foutje in de code zit waardoor calc.exe een verkeerd lettertype heeft, allah... Als het maar geen effect heeft op de security, dan hoeft daar ook niet zo'n diepgaande kwaliteit plaats te hebben). En zoals ik al zei: ook veel defaults zijn bij Microsoft niet gestoeld op security (zoals het standaard niet-tonen van extensies, wat een soort bewust 'dom houden' van het publiek in de hand werkt).

[Reactie gewijzigd door kimborntobewild op 3 juli 2017 11:10]

Hackerclubs zoals de CCC krijgen geen toegang. Juist de kennis van dat soort groepen heb je nodig om mede te laten oordelen over de kwaliteit van je code (Windows) waar honderden miljoenen mensen gebruik van zullen maken.
Zoals ze ook de bugs hebben gevonden in OpenSSL die er al 10 jaar ofzo in zit? (Dit is sarcasme btw).
Met een goed programmeerbeleid zou je eigenlijk al geen securty-gaten moeten hebben. Bug-loos programmeren is inderdaad erg moeilijk. Maar daar waar 't gaat om security, moet MS gewoon veel beter zijn best doen. (Dat er een foutje in de code zit waardoor calc.exe een verkeerd lettertype heeft, allah... Als het maar geen effect heeft op de security, dan hoeft daar ook niet zo'n diepgaande kwaliteit plaats te hebben).
Ik krijg het idee dat je geen programmeur bent en daarom wel heel makkelijk deze dingen zegt. Ik heb wel een beetje inzicht in de QA van Microsoft en die is echt indrukwekkend en ze werken ook continue aan het verbeteren van het process. Je kunt echter niet alles voorkomen hoe hard en hoeveel je ook test.
Een van de eerste zaken die ik in software testing leerde was de regel "Man shall not test his own code."

Wanneer jij zelf een architectuur verzint en deze implementeert met bepaalde code, heb je vaak al over bepaalde risico's heen gekeken. Je denkt er dus ook niet meer aan deze te testen. Een buitenstaander heeft een frisse blik op jouw ontwerp en verzint zo mogelijke risico's die je zelf nooit aan zag komen.
Ja, je bent blind voor je eigen fouten. Dat was één van de eerste regels die ik leerde in software ontwikkeling :D
Het blijft telkens verbazen dat de ruim 100.000 medewerkers van microsoft telkens door derden op gaten in hun software moet worden gewezen.
Zo vreemd is dat niet. Google wordt namelijk ook door derden gewezen op beveiligingsproblemen in hun software. Uiteindelijk is software mensenwerk en je kan niet alles zien. Soms kan zoiets ontstaan door een onverwachte interactie. Het is goed dat men elkaars werk controleert, uiteindelijk hebben we allemaal profijt daarvan dat onze computers veiliger worden.

Het enige, in het algemeen, waar ik het niet mee eens ben is het beleid van Google om als een bug niet snel genoeg gerepareerd wordt deze te publiceren met alle details. Dat is ronduit onverantwoord naar alle gebruikers toe.
Dat het een derde is, is niet zo verbazend, maar dat een concullega het doet is volgens mij uniek voor de software wereld.

Mercedes controleert niet of auto's van Fiat veilig zijn, Boeing niet of vliegtuigen van Airbus dat zijn. Als ze dat trouwens wel zouden doen, zouden auto's en vliegtuigen nog veiliger worden. Volkswagen controleert volgens mij nu wel concullega's op uitstoot, maar het is uitzonderlijk. Kennelijk is de consumenten-software van vandaag zo (over?)complex dat makers niet meer over de juistheid van hun eigen code kunnen redeneren, anders was er geen fuzzer nodig.
Dat het een derde is, is niet zo verbazend, maar dat een concullega het doet is volgens mij uniek voor de software wereld.
Eigenlijk is het bij software niet zo gek. Microsoft en Google hebben beiden bug bounty programma's. Iedereen is vrij om te kijken of er een lek zit in hun software en mag het dan aanmelden. Google is hier gewoon een deelnemer aan het bug bounty programma van Microsoft, net als dat jij en ik dat kunnen zijn.
Mercedes controleert niet of auto's van Fiat veilig zijn, Boeing niet of vliegtuigen van Airbus dat zijn.
Dit is anders. Er zijn namelijk objectieve tests om de veiligheid van een auto of vliegtuig te bepalen. Nieuwe autotypes moeten eerst goedkeuring krijgen om in de EU een kenteken te mogen krijgen. De leverancier moet dan testresultaten overhandigen om de veiligheid aan te tonen.

Vliegtuigen moeten aan hele strenge (wettelijke) eisen voldoen.

Dit alles bestaat niet bij software. Daar heb je alleen het woord van de maker dat alles goed is en geen instanties die controles doen.
Daarnaast, op lekken wordt vaak programmatisch getest. Ik kan me best voorstellen dat zowel Google als Microsoft daarvoor hun eigen tools in huis hebben, en deze absoluut niet willen delen (zulk soort tools zijn ook populair onder hackers, onafhankelijk van de kleur van hun hoedje).

Daarom kan het best wel eens gebeuren dat Googles tool er een lek uitvist die Microsofts tool niet ziet, en omgekeerd. Het is wel zo netjes om het beiden breed toe te passen.

Daarnaast is het vaak zo dat buitenstaanders bugs melden, daarvoor heb je bug bounty programma's en evenementen zoals Pwn2Own.
Omdat die 100.000 medewerkers ook hun eigen baan hebben? De receptioniste, software dev van Office en de datacenter engineer zitten echt niet de code van Defender uit te pluizen.
Van die 100k zijn er maar ongeveer 1000 die coderen, en die zijn onderverdeeld in windows OS, edge, Office windows, Office 365, Office for Mac, XBOX, games, IOS, Android, .net, C++ MS SQL, Onenote, Sharepoint etc., dus ze zitten niet alle 1000 windows na te pluizen op fouten. Daarbij zou het overigens ook kunnen dat ze hun tijd moeten verdelen onder meerdere paketten natuurlijk, en ik verwacht dat 25 jaar code best wel lastig is door te spitten of via black box benadering is te hacken. En daarbij dichten ze waarschijnlijk ook zaken die ze zelf ontdekt hebben.
Dat zie je echt verkeerd, de meeste problemen worden door Microsoft zelf opgespoort en verholpen in hun maandelijks patch rondes. Echter over die problemen lees je niets, ze worden gewoon opgelost zonder dat jij er iets van merkt.
Ehh, die 100.000 medewerkers waar jij het over hebt zijn niet allemaal beveiligingsonderzoekers. Je kan niet van iemand van de sales-afdeling verwachten dat hij een lek in Defender vind 8)7.
Dit is gewoon onzin, alle security researchers die ik ken hebben een IT achtergrond. Die skills zijn ook gewoon cruciaal. Ga jij even een programma decompilen met je rechten opleiding om te vinden in welke instructie die overflow nu zat?
Ik weet niet of jij een operationele siem engineer als security researcher beschouwd.


Kijk eens via linkedin naar de echte namen die zerodays publiceren.
Wat ik eigenlijk gek vind klinken, want voor mij is security meer een wiskundig ding (informatie-theorie). De ICTer en de natuurkundigen komen kwa kennis het dichtst in de buurt van deze stof (denk ik)
Op zich zijn advocaten ook 'fuzzers'. Ze proberen vaak de input van algoritmen (wetten) zo te definiëren dat er met hun input volgens de regels van het algoritme volgens de processor (recchter) een uitkomst is waar de maker van het algoritme niet eens aan gedacht heeft. Ze blijven net zolang op vele algoritmes (wetten) verschillende input proberen (fuzzen) totdat ze een bug (maas in de wet) hebben gevonden.

En om fuzzen te voorkomen moeten beleidsmakets weer kogelvrije regels bedenken waarbij aan iedere uitzondering en randgeval gedacht is.

Het gereedschap is verschillend (taal en mensen vs. wiskundige formules in de vorm van code en computers), de vaardigheden vertonen overeenkomsten.
Intressante theorie ik dacht zelf altijd alleen maar aan het het feit dat ze boeken wormen zijn, veel lezen, veel onthouden, veel geduld en doorzettingsvermogen om uren op iets te bestuderen en met logica tot een eindresultaat te komen.

Logica lijkt het middel te zijn.
Dat is toch ook precies wat ik zeg/bedoel??
Domme opmerking van mij. Sloeg nergens op. Terecht gemint.

[Reactie gewijzigd door GingerLionXx op 26 juni 2017 10:29]

In een tijd waar technologie, online veiligheid en privacy op nummer 1 staan vind ik het kwalijk dat men zich hier niet vaker over informeren. Met name hoe het werkt achter de schermen. Het gevoel dat de titel en de reacties mij vaak geven is neerkijkend. "Oh, oh, oh, Microsoft... Alweer een lek, hè?" Wat nou "alweer"? Software is zowat onmogelijk om in één keer muurvast en dicht te krijgen. Dat mensen lekken vinden is geen nieuw nieuws. En het zegt al helemaal weinig over hoe onveilig iets is. Dat er een lek gevonden wordt en is gerepareerd zegt alleen maar wat over de support en hoe "snel" ze dit kunnen repareren.

Laat ik het anders zeggen: Er zijn hedendaags gevangenissen en banken waar men vrijwel niet uit kan ontsnappen. En toch gebeurd het. Hoe? Omdat ze dingen proberen waar niemand aan gedacht heeft, omdat ze zich voordoen als iemand anders, omdat ze gewoon een lek hebben gevonden. Ik ben van mening dat men zich vandaag de dag echt nog wel wat meer in de wetenschappen achter wat ze gebruiken mogen verdiepen. Ik vind het schandalig dat men zonder enige kennis van hoe het werkt en wat er achter de schermen gebeurd zo'n grote stem (kunnen) krijgen. Ik ga niet iedere gevangenis uitsluiten omdat er ooit iemand van ontsnapt is. Of omdat er ooit iemand verongelukt is. Verzin wat.

[Reactie gewijzigd door sxbrentxs op 26 juni 2017 15:39]

Mooi dat iedereen elkaar controleert maar waarom gooit Google dit telkens zo in het nieuws? Ik snap dat het best een bug kan zijn maar al die andere bedrijven die continue bugs vinden gaan dat ook lang niet altijd aan de pers melden tenzij het misschien een heel erge is. En dan is het vaak met zoveel vertraging dat ze de bug bekend maken. Dan heeft het bedrijf de tijd om het te fixen.

Als voorbeeld de auto die een paar jaar geleden 'gehacked' was en die ze van op afstand konden beheren. Ze werkten samen om het op te lossen en pas toen dat in orde was kwamen ze naar buiten met het verhaal.
Google heeft een mentaliteit dat het onaanvaardbaar is dat bugs langer dan 90 dagen in software zitten (ondanks dat ze die "regel" zelf meermaals aan de laars lappen) en natuurlijk is het voor hun ook PR. Maar ik kan je verzekeren dat de bedrijven bij wie ze dat doen daar niet zo tevreden over zijn.
Volgens mij is dit een persoonlijke actie van die Travis :p Dat hij bij Google werkt hoeft hier niet zoveel mee te maken hebben

Veel mensen doen dit soort dingen naast hun normale werk (net zoals bij opensource projecten) en krijg je bij Google zelfs de vrijheid voor persoonlijke projecten (geen idee of dat nog steeds zo is btw)

[Reactie gewijzigd door Mellow Jack op 26 juni 2017 19:43]

Een bug is wat anders als een veiligheidsissue. 90 dagen is ook onaanvaardbaar lang.
Opnieuw, een periode die Google ook met plezier aan zijn laarzen lapt.
Ze werkten samen om het op te lossen en pas toen dat in orde was kwamen ze naar buiten met het verhaal.
Dat is hier toch ook gebeurd? Tweede regel van het artikel:
"Microsoft heeft het lek volgens de onderzoeker gedicht."
Dat is toch logisch, de meeste mensen maken gebruik van een computer met Windows en Windows Defender en de Windows Update functionaliteit zijn cruciaal onderdelen in het beveiligen van Windows. Iedereen, ook Google, heeft er belang bij dat die onderdelen veilig zijn.
Het is natuurlijk interessant dat de bug door de concurrent wordt gevonden, maar is dit eigenlijk nog wel nieuwswaardig? Er zullen ongetwijfeld ook door andere partijen bugs gevonden worden, maar daar zien wij niet iedere keer een nieuwsbericht van. Google heeft natuurlijk ook een groot belang bij een veilig OS.

Admin-edit:Spelfouten en/of ander commentaar m.b.t. nieuwsposts horen thuis in
Geachte Redactie.

[Reactie gewijzigd door Bor op 26 juni 2017 13:01]

Het is natuurlijk interessant dat de bug door de concurrent wordt gevonden, maar is dit eigenlijk nog wel nieuwswaardig?
De reden dat het nieuwswaardig is, is dat Defender's engine op kernel-niveau draait en als daar een remote code execution exploit bij mogelijk is, de rapen een flink stuk meer gaar zijn dan wanneer er een exploit in een browser runtime gevonden wordt die binnen een sandbox draait op user-niveau, onder een gebruikersaccount met veel en veel minder permissies.

[Reactie gewijzigd door R4gnax op 26 juni 2017 10:49]

Verder is dit geval sowieso erg nieuwswaardig: dat juist een programma wat bedoeld is om je systeem veiliger te maken, allerlei extra onveiligheden aan je systeem toevoegt.
Zou je wat meer kunnen vertellen over het feit dat Microsoft defender op kernel niveau laat draaien en niet binnen een sandbox?
Zou je wat meer kunnen vertellen over het feit dat Microsoft defender op kernel niveau laat draaien en niet binnen een sandbox?
Het probleem zit hem hier in een exploit via de X86 emulator die Defender aan boord heeft.

Microsoft gebruikt die emulator om genepte dry runs van stukjes code te kunnen doen enzo te analyseren of ze schadelijk gedrag vertonen. Van die emulator is bekend dat deze niet via enige vorm van sandboxing afgeschermd is. En dat levert een probleem op als je door bepaalde code patronen aan die emulator te voeren, een remote code execution voor elkaar kunt krijgen. Dus niet ge-emuleerd in de emulator, maar de emulator zelf subverten en bijv. gedeelten van het procesgeheugen op zo'n manier manipuleren dat jouw code er direct in geinjecteerd wordt.

En uiteraard draait Defender op kernel-niveau; een betrouwbare real-time scan engine moet wel. Als die in user-land zou draaien zou het een te makkelijke prooi worden voor malware om de engine buiten spel te zetten of omwegen te vinden het inhaakpunt van de engine te bypassen. Door zo laag in de OS stack te gaan zitten geef je de engine extra bescherming tegen indringers en de mogelijkheid om tussen praktisch alle I/O operaties in te gaan zitten.

(Uiteraard draait alleen de engine op kernel-niveau. User interface applicaties draaien allemaal wel gewoon in user-land.)

[Reactie gewijzigd door R4gnax op 27 juni 2017 00:24]

Ik zou zeggen: In dit geval wel. Het systeem is veel aanwezig (alle moderne Windows PC's), en de impact van een exploit kan zeer ernstig zijn (er wordt immers een x86 zonder sandbox geëmuleerd).

Als er een soortgelijke exploit zou worden gevonden in bijv. GIMP of, weet-ik-veel, Windows Movie Maker, dan het waarschijnlijk al minder relevant zijn gezien niet iedereen dit heeft geinstalleerd.
Als jij als kwaliteitsmanager werkt bij je bedrijf, dan zie je waarschijnlijk na een aantal jaar ook dingen over het hoofd. Als jij dan veranderd van bedrijf en mensen leggen je uit hoe processen werken, dan vallen je waarschijnlijk ook fouten op. Denk dat het zo ook werkt met codes inspecteren.
Dit geeft je dan echter wel een vals gevoel van zekerheid.

a) In Kaspersky software zijn ook regelmatig dit soort vulnerabilities gevonden
b) Windows defender draait nog steeds op je systeem. Mogelijk heb je remote exploitation afgevangen met andere AV software, maar dat betekend nog niet dat niemand het bestaande lek kan misbruiken d.m.v., bijvoorbeeld, een lokale exploit.
Het geeft je een beter gevoel om de veiligheid van je computer uit handen te geven aan een Russisch bedrijf?
Ik weet dat Kaspersky een goed reputatie heeft. Maar het is in Rusland als groot bedrijf heel lastig om succesvol te zijn en te blijven zonder dubieuze vriendjes in de politiek en/ of maffia.

Op dit item kan niet meer gereageerd worden.


Nintendo Switch Google Pixel XL 2 LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*