Yet another JScript vulnerability

Topic

New Reply

Internet Explorer, the gift that keeps on giving. Looks like we have a brand new JScript bug. According to ADV200001: A remote code execution vulnerab
[See the full post at: Yet another JScript vulnerability]

5 users thanked author for this post.

Lori, jburk07, Fred, Nibbled To Death By Ducks, SueW

Reply | Quote

Replies

Yes, let’s hope they don’t repeat September debacle 🙂

2 users thanked author for this post.

Nibbled To Death By Ducks, woody

Reply | Quote

[fernlady]

I’m a home user with one windows7 computer and have Firefox 72.0.1 as my default browser, should I disable JScript in IE11?

Under Scripting there are 3 areas that are enabled, Active scripting, Enable XSS filter & Scripting of Java applets. Allow Programmatic clipboard access which is set to Prompt. Disable all???

Windows 11 Pro
Version 23H2
OS build 22631.5335

• This reply was modified 5 years, 5 months ago by fernlady.

Reply | Quote

I would open Control Panel and go to Programs and Features. Then on the top left click on “Turn Windows Features on or off”.

Next find Internet Explorer 11 and uncheck the box.

I did this a couple of years ago and it hasn’t affected other programs or websites for me.

Consider using NoScript with Firefox and although there is a bit of a learning curve  any inconvenience will give you a more secure system as payback. Also HTTPS Everywhere is another secure option.

1 user thanked author for this post.

fernlady

Reply | Quote

That was easy. Thank you, so far no problems.

Windows 11 Pro
Version 23H2
OS build 22631.5335

Reply | Quote

If you do ever need to re-enable Internet Explorer, It may not recreate the desktop icon when you do.

Just something to watch out for.

 

Reply | Quote

Looks like MSFT has issued a temporary workaround for the IE vulnerability with instructions how to implement and undo for when a hot-fix-patch is released.

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV200001

MSFT catalog patch for Windows 7 only? dunno, time will tell..

Windows - commercial by definition and now function...

1 user thanked author for this post.

jburk07

Reply | Quote

Yep, that’s the “Turn off JScript” fix I mentioned.

Nice of them to announce this on a Friday evening before a three-day (US) weekend…

1 user thanked author for this post.

jburk07

Reply | Quote

As usual MS forgot to mention in the FAQ,  this temporary workaround also break Windows Media Player on Win 10. You’ll get a “Server execution failed error” when trying to play an MP4.

3 users thanked author for this post.

jburk07, Microfix, woody

Reply | Quote

It also causes “sfc” on Win7 to emit a cryptic error message, something about files it tried to restore but couldn’t, presumably because “sfc” also can no longer read the jscript.dll files after the workaround is implemented. Since the logfile generated by “sfc” is effectively unparsable by mere mortals, it is difficult to determine exactly what “sfc” is complaining about. Therefore, you may not want to implement this workaround if you rely on “sfc” to validate the health of your Win7 system.

3 users thanked author for this post.

jburk07, Microfix, woody

Reply | Quote

If your not directly using Internet Explorer to access the internet, should this be worried about?

I have IE’s outbound connection blocked with Windows Firewall, should I also block the inbound connection as well?

Reply | Quote

Not using IE is kind of a baseline security precaution.

I don’t know if you’re vulnerable outside of IE, but I would guess that if the exposure were really all that significant, we would have a patch by now.

4 users thanked author for this post.

jburk07, OscarCP, Moonbear, Fred

Reply | Quote

In that case I’m leaving it alone, especially considering the issues being reported from using the workaround

Reply | Quote

Interesting.  I disabled jscript per the advisory, and Internet Explorer still worked fine (not that I use it much anymore,) but Firefox crashed at startup until I enabled it again.  Waterfox, Pale Moon, and IceDragon, however, did not seem to be affected.

Disabling jscript may also have broken Panda Dome, though I’m not sure about that, as this as a possible cause of the issues it was having did not occur to me until after I’d already given up in frustration and replaced it with Avast.

i7-10700k - ASROCK Z590 Pro4 - 1TB 970 EVO Plus M.2 - DDR4 3200 x 32GB - GeForce RTX 3060 Ti FTW - Windows 10 Pro

4 users thanked author for this post.

jburk07, woody, Fred, samak

Reply | Quote

We @0patch are planning to issue a micropatch for this next week which will prevent Internet Explorer from loading jscript.dll. This will not affect the permissions on jscript.dll and will likely keep the sfc command unaffected. It would be nice to learn from other users implementing Microsoft’s workaround what else that workaround breaks.

5 users thanked author for this post.

jburk07, Geo, Microfix, AmbularD, woody

Reply | Quote

So far, the reports on side effects that have been reported on this site, as far as I know, are in the above posts.

1 user thanked author for this post.

woody

Reply | Quote

Our micropatches for CVE-2020-0674 are out, and an accompanying blog post: https://blog.0patch.com/2020/01/micropatching-workaround-for-cve-2020.html

4 users thanked author for this post.

jburk07, Geo, Alex5723, Microfix

Reply | Quote

The workaround breaks printing to “Microsoft Print to PDF”. I had to revert it.

1 user thanked author for this post.

jburk07

Reply | Quote

I use Win7 PC’s and never use IE..Use Firefox, Firefox variant Pale moon & Chrome. Would I be affected by this Jscript issue?

Reply | Quote

Probably not, but it’s worth checking the browser web sites to see what they say about it.

cheers, Paul

Reply | Quote

@Mitja-Kolsek

There are some other consequenses of the JavaScript bug posted here.

Reply | Quote