Vroeër het ons
Vreemd genoeg was Kolsek aanvanklik nie in staat om die aanval wat deur John beskryf en gedemonstreer is, te reproduseer nie, waar hy Internet Explorer op Windows 7 gebruik het om 'n kwaadwillige MHT-lêer af te laai en dan oop te maak. Alhoewel sy prosesbestuurder gewys het dat system.ini, wat beplan was om van homself gesteel te word, gelees is deur 'n skrip wat in die MHT-lêer versteek is, maar nie na die afgeleë bediener gestuur is nie.
"Dit het gelyk soos 'n klassieke merk-van-die-web situasie," skryf Kolsek. “Wanneer 'n lêer vanaf die internet ontvang word, voeg behoorlik lopende Windows-toepassings soos webblaaiers en e-poskliënte 'n etiket by so lêer in die vorm
Die navorser het geverifieer dat IE werklik so 'n etiket vir die afgelaaide MHT-lêer gestel het. Kolsek het toe probeer om dieselfde lêer met Edge af te laai en dit in IE oop te maak, wat die verstektoepassing vir MHT-lêers bly. Onverwags het die uitbuiting gewerk.
Eerstens het die navorser “mark-of-the-Web” nagegaan, dit het geblyk dat Edge ook die bron van die lêer se oorsprong in 'n alternatiewe datastroom stoor bykomend tot die sekuriteitidentifiseerder, wat vrae kan laat ontstaan oor die privaatheid van hierdie metode. Kolsek het bespiegel dat die ekstra reëls IE kon verwar en verhoed het om die SID te lees, maar soos dit blyk, was die probleem elders. Na 'n lang ontleding het die sekuriteitspesialis die oorsaak gevind in twee inskrywings in die toegangsbeheerlys wat die reg gevoeg het om die MHT-lêer te lees by 'n sekere stelseldiens, wat Edge daar bygevoeg het nadat dit gelaai is.
James Foreshaw van die toegewyde nul-dag kwesbaarheidspan - Google Project Zero -
Vervolgens wou die navorser beter verstaan wat veroorsaak dat IE se sekuriteitstelsel misluk. 'n In-diepte ontleding met behulp van die Prosesmonitor-nutsding en die IDA-disassembler het uiteindelik aan die lig gebring dat die Edge se vasgestelde resolusie die Win Api-funksie GetZoneFromAlternateDataStreamEx verhoed het om die Zone.Identifier-lêerstroom te lees en 'n fout teruggestuur het. Vir Internet Explorer was so 'n fout by die versoek van 'n lêer se sekuriteitetiket heeltemal onverwags, en blykbaar het die blaaier van mening dat die fout gelykstaande was aan die feit dat die lêer nie 'n "merk-van-die-web"-merk gehad het nie, wat dit outomaties vertrou maak, waarna IE toegelaat het dat die skrip wat in die MHT-lêer versteek is, uitgevoer en die teiken plaaslike lêer na die afgeleë bediener gestuur het.
“Sien jy die ironie hier?” vra Kolsek. "'n Ongedokumenteerde sekuriteitskenmerk wat deur Edge gebruik is, het 'n bestaande, ongetwyfeld baie belangriker (merk-van-die-web) kenmerk in Internet Explorer geneutraliseer."
Ten spyte van die groter belangrikheid van die kwesbaarheid, wat dit moontlik maak om 'n kwaadwillige skrif as 'n betroubare skrif te laat loop, is daar geen aanduiding dat Microsoft van plan is om die fout binnekort reg te stel, as dit ooit reggestel word nie. Daarom beveel ons steeds aan dat u, soos in die vorige artikel, die verstekprogram vir die opening van MHT-lêers na enige moderne blaaier verander.
Natuurlik het Kolsek se navorsing nie sonder 'n bietjie self-PR verloop nie. Aan die einde van die artikel het hy 'n klein pleister gedemonstreer wat in samestellende taal geskryf is wat die 0patch-diens kan gebruik wat deur sy maatskappy ontwikkel is. 0patch bespeur outomaties kwesbare sagteware op die gebruiker se rekenaar en pas klein pleisters letterlik op die vlieg toe. Byvoorbeeld, in die geval wat ons beskryf het, sal 0patch die foutboodskap in die GetZoneFromAlternateDataStreamEx-funksie vervang met 'n waarde wat ooreenstem met 'n onvertroude lêer wat van die netwerk ontvang is, sodat IE nie sal toelaat dat enige verborge skrifte uitgevoer word in ooreenstemming met die gebou- in veiligheidsbeleid.
Bron: 3dnews.ru