CVE-2020-0674 and I.E.8

[Guest]

Now that I have some free time I have done a test to check the CVE-2020-0674 vulnerability in my I.E.8.
I found the test file thanks to 0Patch:

 

https://blog.0patch.com/2020/01/micropatching-workaround-for-cve-2020.html

To make the test after the creation of the HTLM file I had to make 2 changes:

but the result is unexceptionable:

I.E.8 is vulnerable.

I urge users to consider disabling scripts on I.E.8:

F12 - Disable script

and the block of executables via trick 1803:
 

Quote

 

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
"1803"=dword:00000003

 

I don't use I.E.8, so I've also enabled a rule in OSArmor for total browser blocking.

Edited February 17, 2020 by Sampei.Nihira

[Mcinwwl]

And 0patch's patch is for free... but no XP edition   I mailed them if that's feasible.

Looks like that we have first real vuln for XP after POSReady patch went away. Well, I can discard IE8 on my machine, but WMP will be a bit of a chore...

[Guest]

Attention also:

 

Quote

..... in Windows XP it is also used for the User Accounts Control Panel, which is an HTML Application ......

https://en.wikipedia.org/wiki/Trident_(software)

 

Control.exe nusrmgr.cpl

Edited February 18, 2020 by Sampei.Nihira

[Guest]

On 2/17/2020 at 7:53 PM, Mcinwwl said:

And 0patch's patch is for free... but no XP edition   I mailed them if that's feasible.

Looks like that we have first real vuln for XP after POSReady patch went away. Well, I can discard IE8 on my machine, but WMP will be a bit of a chore...

 

https://0patch.zendesk.com/hc/en-us/articles/360018881053-Which-operating-systems-are-currently-supported-by-0patch-
 

Quote

 

0patch Agent currently works on the following platforms:

Windows Vista, 32 and 64 bit

Windows XP SP3, 32 and 64 bit (fully updated)

 

https://0patch.com/pricing.html

https://0patch.com/patches.html

Quote

CVE-2020-0674 Internet Explorer is free.

0Patch Agent should work on Windows XP:

 

Quote

 

Memory Consumption

mitja.kolsek - November 18, 2019 15:19

0patch Agent is designed to inject a dynamic load library (DLL) into each running process so that it can then apply and un-apply micropatches in that process. While there are some processes that don't let themselves get injected this way, most processes will spend an additional 600-700 KB of memory each for hosting that DLL. On a typical Windows 10 system with ~100 running processes this means a memory consumption of 60-70 MB.

(Note that we're planning to redesign 0patch Agent such that it will not require injection into processes, which will eliminate this cost.)

In addition, 0patch Service and 0patch Tray, which are running in the background, consume around 10 MB of memory each.

 

Quote

 

Network Bandwidth Consumption

mitja.kolsek - November 18, 2019 15:19

0patch is really, really light on your bandwidth. In a default setting, each 0patch agent contacts ("syncs with") the server once every hour when connected to the Internet, and a typical sync consumes less than 4.5 kilobytes in each direction on the Ethernet level. (This includes Ethernet, IP, TCP and TLS layers). When a new micropatch is downloaded from the server, the download link is burdened with an additional 1-2 kilobytes per micropatch. (Note that the actual micropatch code is much smaller, typically under 30 bytes; the rest is for metadata and additional bytes on lower network layers.)

For most enterprises this means that even a large fleet of computers can communicate with our cloud-based server without a noticeable network disruption. However, if needed the frequency of syncing can be adjusted to the available bandwidth.

 

 

Edited February 23, 2020 by Sampei.Nihira

[Dibya]

I will try to make a patch . Opatch has documented everything . I have already ported some patches for server 2008 but I didn't share anywhere .

[Mcinwwl]

Agent works, but to XP version for this patch.

[Tripredacus]

If it were me, the 0patch solution is no solution at all, as long as it requires communicating with an external web server that may some day disappear from the internet.

[Vistapocalypse]

18 minutes ago, Tripredacus said:

If it were me, the 0patch solution is no solution at all...

IE 11 on Windows 7 is also affected by CVE-2020-0674. as is IE 9 on Vista. I have tried the Microsoft workaround, and 0patch Blog did not exaggerate its negative side effects. I used System Restore to undo all the changes to jscript.dll.

[luweitest]

I have many .js files to use, so disable jscript.dll seems no solution for me (not sure wscript.exe and cscript.exe need it or not). Is there any web page that demonstrates the attack?

[Guest]

3 hours ago, luweitest said:

I have many .js files to use, so disable jscript.dll seems no solution for me (not sure wscript.exe and cscript.exe need it or not). Is there any web page that demonstrates the attack?

Several malwares have abused legitimate OS executables for their attack.
Some more info in the article below:

 

https://blog.talosintelligence.com/2019/11/hunting-for-lolbins.html

These executables between which wscript.exe and cscript.exe should also be brought under control.
I have no problem running I.E. even with these exe under control of NVT OSA:

OSA also has a rule for blocking 2 exes.
And as you see I.E.8 it works:

 

What do you need the web page for?
Isn't my demonstration enough, what Vistapocalypse, Microsoft, 0-Patch ..... etc wrote about it?

Edited February 26, 2020 by Sampei.Nihira

[Guest]

19 hours ago, Vistapocalypse said:

IE 11 on Windows 7 is also affected by CVE-2020-0674. as is IE 9 on Vista. I have tried the Microsoft workaround, and 0patch Blog did not exaggerate its negative side effects. I used System Restore to undo all the changes to jscript.dll.

Have you tried the alternative solution provided by Microsoft?

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0674

Quote

.......By default, IE11, IE10, and IE9 uses Jscript9.dll which is not impacted by this vulnerability...............

For 32-bit systems, enter the following command at an administrative command prompt:
 

Quote

 

takeown /f %windir%\system32\jscript.dll

cacls %windir%\system32\jscript.dll /E /P everyone:N

 

For 64-bit systems, enter the following command at an administrative command prompt:
 

Quote

 

takeown /f %windir%\syswow64\jscript.dll

cacls %windir%\syswow64\jscript.dll /E /P everyone:N

takeown /f %windir%\system32\jscript.dll

cacls %windir%\system32\jscript.dll /E /P everyone:N

 

 

It could probably be an elegant solution with Windows Vista.

Edited February 26, 2020 by Sampei.Nihira

[luweitest]

The Microsoft notice page says something like "arbitrary code execution", so I expect a demonstration page could open my notepad.exe and write some text like "you've been stoned!". :P)   Could the loading of jscript.dll be exploited to do this?

I tried running the 0patch test html code. IE8 shows the "restricted" yellow warning bar upon opening and explicit allowance is needed. My security zones setting are default.

I modified the test html to this (from js sample code):

<html>
<head>
 <meta http-equiv="X-UA-Compatible" content="IE=8"></meta>
</head>
<body>
<script language="Jscript">
	var WshShell = new ActiveXObject("WScript.Shell");
	var oExec = WshShell.Exec("notepad");
	WScript.Echo("You have been stoned!");
	 
</script>
</body>
</html>

After explicit allowance twice, IE8 does open notepad, but Wscript.Echo is not executed. Maybe IE8 do not support all Wscript methods. I write js scripts for file and data processing, and not familiar with html.

I do not use IE8 and WMP, but maybe some other program module use them. I think a real threat should get executed without explicit allowance, in the default setting. Could that be demonstrated?

[Vistapocalypse]

3 hours ago, Sampei.Nihira said:

Have you tried the alternative solution provided by Microsoft?

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0674

[quotations omitted]

It could probably be an elegant solution with Windows Vista.

Yes, "I have tried the Microsoft workaround" actually meant that I "tried the alternative solution provided by Microsoft," and there is nothing "elegant" about it.

If anyone else wants to try that, I would suggest that you first read about "negative side effects" at 0patch Blog and create a restore point.

3 hours ago, Sampei.Nihira said:

.......By default, IE11, IE10, and IE9 uses Jscript9.dll which is not impacted by this vulnerability...............

By quoting that, are you implying that Windows XP has no jscript9.dll, or that IE8 does not use it by default? I'm not sure what you mean.

[Guest]

Nothing jscript9.dll in I.E.8 with Windows XP.

[Vistapocalypse]

5 minutes ago, Sampei.Nihira said:

Nothing jscript9.dll in I.E.8 with Windows XP.

Thanks for clarifying that. Microsoft nevertheless rates the vulnerability's severity as Critical for IE 11 on Windows 7, but only Moderate for IE 9 on Server 2008 SP2.

I'm not familiar with OSArmor, but you've got me wondering if it could offer a better solution for Vista, i.e. block any process from jscript but not jscript9 (sorry if OT).