Kun je mij uitleggen waarom een HP printer niet meer werkt als je een update voor IE 11 installeert? Dat zijn twee compleet aparte dingen als je het mij vraagt.

N.B. Een update is niet hetzelfde als een mitigation. Mitigation betekent dat je problemen vermindert en de update is daar een middel voor.

Er is nog een update voor het probleem. Er is alleen een mitigation, en die heeft wat side effects.


Het is een bekend probleem, als je de mittigatie doorvoert. Heeft te maken jscript.dll die gebruikt wordt door de HP printers.
Zo zijn er nog meer mogelijke issues, die kunnen voorkomen.


https://www.bleepingcomputer.com/news/security/microsofts-ie-zero-day-fix-is-breaking-windows-printing/

Volgens mij ondersteund IE11 geen PDF standaard, dus of dit effect heeft, durf ik niet zeker te zeggen.
Maar IE kan helaas via meerdere methodes misbruikt worden volgens de onderstaande site. Of dit ook werkelijk zo is, durf en kan ik niet zeggen.


If you're a 0patch user, you already have this micropatch downloaded to all your online computers with 0patch Agent, and - depending on your settings - already automatically applied to all processes using the Internet Explorer 11 engine for rendering content. This includes Internet Explorer (obviously), Microsoft Word, Microsoft Outlook, and a variety of other applications.
https://blog.0patch.com/2020/01/micropatching-workaround-for-cve-2020.html

Dat is niet fijn als je Outlook of Office gebruikt (Outlook zit natuurlijk in Office). Zelf gebruik ik Thunderbird en Notepad ;-)

TS

Ik heb er weinig over kunnen vinden. Maar het lek had wel een speciale website nodig om te de exploit te misbruiken. Of dit mogelijk is vanuit een andere applicatie, durf ik niet te zeggen.

En ik heb vrij weinig echt nuttige informatie hierover kunnen vinden.

Omdat het een indirecte kwetsbaarheid onder IE11 betreft in de crypto DLL en die wordt dus ook door HP printerdrivers gebruikt!

Volgens mij heb je het over iets anders. Dit IE11 probleem betreft een probleem met jscript.dll. En de mitigation is momenteel on de rechten van de jscript.dll te ontnemen. Maar dit betref ook daarna mogelijke andere applicaties die jscript.dll nodig hebben.

De crypto dll issues zijn al gepatched en volgens mij zonder al te veel problemen.

Ik denk dat het meevalt. Windows koppelt bestanden aan applicaties via de extensie in de bestandsnaam. Firefox gebruikt MIME-types om te bepalen wat er moet gebeuren met een bestand, dat is een gegeven dat een webserver in de HTTP-headers meestuurt. Volgens mij betekent dat dat de koppelingen die Windows hanteert helemaal niet gebruikt worden door Firefox.

Als je in de voorkeuren van Firefox kijkt zie je in het onderdeel "Algemeen" onder het kopje "Toepassingen" welk "inhoudstype", dat is de MIME-type, aan welke applicatie is gekoppeld. Als IE daar niet bij staat is er in Firefox niets aan IE gekoppeld, en IE wordt dan ook niet door Firefox opgestart.

ja dat kan

Verzeker jezelf er in ieder geval van dat Firefox je default browser is.
https://support.mozilla.org/en-US/kb/make-firefox-your-default-browser

Het enige is dat FF default dacht ik geen Active-X -code verwerkt, maar daar is wel een mouw aan te passen.
https://www.techwalla.com/articles/how-to-turn-on-activex-controls-in-firefox

Het probleem betreft niet alleen MSIE11, maar elke software die van jscript.dll gebruik maakt (de JavaScript engine waar o.a. MSIE11, maar kennelijk ook HP printersoftware), indien je daar bestanden mee opent die een jscript exploit zouden kunnen bevatten (zo'n bestand zul je dus moeten downloaden of op andere wijze op je PC krijgen).

Het zou mij niet verbazen als bijvoorbeeld mshta.exe, gebruikt voor het uitvoeren van .hta files (HTA = HTML Application), ook van jscript.dll gebruik maakt. Maar aangezien je een .hta file sowieso als een uitvoerbaar programma moet beschouwen, is een exploit daarin (voor de kwetsbaarheid in jscript.dll) niet erg zinvol.

Zo lang je geen bestanden downloadt en start, verwacht ik niet dat je door de kwetsbaarheid in jscript.dll risico's loopt met Firefox, aangezien deze een eigen JavaScript-interpreter heeft (waar een -naar verluidt- zeer vergelijkbaar lek in zat, dat al wel is gepatched). Geen risico voor deze kwetsbaarheid onder voorwaarde dat je de laatste versie van Firefox draait natuurlijk.

Goede tip, maar elke andere (wel up-to-date) browser dan MSIE beschermt je tegen de jscript.dll kwetsbaarheid.

Dat zou ik niet doen (proberen aan te zetten, by default doet Firefox niets met ActiveX). ActiveX was onveilig by design en had daarom nooit moeten bestaan. Nu die oude koe eindelijk dood is, zou ik haar niet uit de sloot willen halen.

Dat klinkt wel logisch. Maar ik wilde het zeker weten. Een video op youtube liep vast bij mij in Firefox (draaiende witte cirkel). Dat doet die anders nooit. Ook zat er reclame op de video dus dan ga je toch denken, kan het iets slechts zijn? Ik denk nu van niet.

Mijn internet is bekabeld en mijn mail deed het toen nog wel.

Bedankt!
TS

Ik verbaasde mij ook een beetje over die reactie. ActiveX is gewoon een windows programma dat in je browser gestart wordt.

Er was een hacker die een ActiveX control had gemaakt dat je computer afsloot als je erop klikte. En de CCC uit Duitsland had een campagne 'RadioActiveX'. Maar die kan ik nu niet meer op hun site vinden.

Maar nou ja, Microsoft heeft wel meer stomme dingen gedaan in het verleden. Zoals bestandsextensies verbergen zodat je niet meer ziet waar je eigenlijk op klikt. Of UAC zo verzwakken dat je niet altijd een scherm krijgt als je een programma gaat uitvoeren.

TS

Heeft een fout in een Volkswagen gevolgen voor mensen die Honda rijden ? Indien Samsung TV's een mankement hebben, stuur je dan een Panasonic TV daarvoor terug naar de fabriek ? Installeer je Windows patches voor beveiligingsproblemen, op Linux of MacOSX ?

Nee, een kwetsbaarheid in IE heeft geen impact op FF.

Een leuke redenatie, maar deze gaat niet helemaal op. Voor de auto's en TV's geldt, dat in het product van de ene fabrikant een component van een toeleverancier kan zitten, die de ander ook heeft en waar het probleem mee is. Dan kunnen beiden hetzelfde probleem hebben. Bij Firefox kan gebruik worden gemaakt van een systeembestand, dat ook in IE zit, is dit het lekke bestand, zijn beiden lek. Het ligt er altijd aan hoe iets is opgebouwd, gekoppeld en aangestuurd. Dus de vraag laat zien, dat er wordt nagedacht.

In dat geval is het geen specifiek IE lek. Natuurlijk kunnen in een browser, een auto, of een tv onderdelen zitten van dezelfde leveranciers.

In dit geval zit het probleem in de scripting engine die IE gebruikt. Die kan door andere programma's gebruikt worden. Niet door Firefox, die heeft zijn eigen scripting engine, maar Firefox kan wel geconfigureerd worden om aan een MIME type een applicatie te koppelen die ook de defecte scripting engine gebruikt.

Maar Microsoft presenteert het wel degelijk als een IE-specifiek probleem:
Terwijl de scripting host in Windows heel algemeen ingezet kan worden in allerlei programma's leest dit alsof er iets specifieks voor IE is in de afhandeling van objecten in geheugen waar het misgaat. En het is een scripting engine waar ze het over hebben, een script-implementatie die via de scripting host wordt gebruikt. Is er een scripting engine die (tegenwoordig) exclusief door IE wordt gebruikt waar het probleem in zit, misschien?

Mijn kennis van Windows is ontoereikend om het antwoord daarop te weten, maar de nadruk op IE en niet op bijvoorbeeld JavaScript of VBscript in het algemeen suggereert dat het iets is dat specifiek in IE misgaat. Als dat zo is dan moet IE zelf uitgevoerd worden om de kwetsbaarheid te activeren.