Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Internet Explorer security bug under active attack

8 views
Skip to first unread message

Arlen Holder

unread,
Jan 18, 2020, 1:44:22 PM1/18/20
to
Internet Explorer security bug under active attack
<https://techcrunch.com/2020/01/18/internet-explorer-security-flaw/>
"Microsoft said all supported versions of Windows are affected by the
flaw, including Windows 7"

"Microsoft has confirmed a security flaw affecting Internet Explorer is
currently being used by hackers, but that it has no immediate plans to
fix."

o U.S. Government Confirms Critical Browser Zero-Day Security Warning For Windows Users
<https://www.forbes.com/sites/daveywinder/2020/01/18/us-government-confirms-critical-zero-day-security-warning-for-windows-users/>

"Microsoft said that a remote code execution (RCE) vulnerability had been
found in the scripting engine of the Internet Explorer (IE) web browser.
It's a critical vulnerability, assigned as CVE-2020-0674, that impacts IE
across all versions of Windows and can corrupt memory so that an attacker
can execute arbitrary code. "

pjp

unread,
Jan 18, 2020, 4:17:30 PM1/18/20
to
In article <qvvjm2$823$1...@news.mixmin.net>,
arlen.geo...@is.invalid says...
And only days after Win7 EOL

Jeff Barnett

unread,
Jan 18, 2020, 4:28:23 PM1/18/20
to
I find it interesting that the article headline says
"Microsoft says it will fix an Internet Explorer security bug under
active attack";

The first paragraph says
"Microsoft has confirmed a security flaw affecting Internet Explorer
is currently being used by hackers, but that it has no immediate
plans to fix";

And the last line of the article says
"Microsoft has confirmed a security flaw affecting Internet Explorer is
currently being used by hackers, but that it has no immediate plans to
fix".

Taken all together, I'm quite confused. I think the writer of the
article is headed to Washington, DC where he/she will have a very
successful career in the current political situation.
--
Jeff Barnett

Shadow

unread,
Jan 18, 2020, 6:01:26 PM1/18/20
to
I announced it 4 days ago. With an OT up, because M$ products
are OT in a.c.f.
Maybe not the same vulnerability, but just as serious.

Message-ID: <0nnr1ftuudptg21hs...@4ax.com>

Looks like Win 7 didn't get the patch ...
[]'s


--
Don't be evil - Google 2004
We have a new policy - Google 2012

Jeff Barnett

unread,
Jan 18, 2020, 6:43:49 PM1/18/20
to
THIS
>  "Microsoft has confirmed a security flaw affecting Internet Explorer is
>   currently being used by hackers, but that it has no immediate plans to
>   fix".
SHOULD READ AS
"When reached, a Microsoft spokesperson did not comment."

Mayayana

unread,
Jan 18, 2020, 7:51:53 PM1/18/20
to
"Shadow" <S...@dow.br> wrote

|
| I announced it 4 days ago. With an OT up, because M$ products
| are OT in a.c.f.
| Maybe not the same vulnerability, but just as serious.
|

The one from a few days ago doesn't affect Win7. That's
a crypt32.dll bug in Win10. The new bug is in the javascript
parsing. One article said it's almost the same thing FF fixed
a couple of weeks ago. I imagine Win7 will get the patch, if
there is one.


Shadow

unread,
Jan 18, 2020, 8:26:01 PM1/18/20
to
I thought it affected crypt32.dll from Vista to Win 10, IOW
all software using crypt32.dll, not just Internet Explorer or whatever
they call it now.
I did read a few articles before posting, maybe one of them
got it wrong.

Mayayana

unread,
Jan 18, 2020, 11:03:11 PM1/18/20
to
"Shadow" <S...@dow.br> wrote

| I thought it affected crypt32.dll from Vista to Win 10

https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF

It's specifically concerning new-ish encryption methods.
But I find it's easy to miss these things. They love to
yak when unsupported windows has bugs but when it's
only Win10 they'll typically avoid saying which version
is affected.


JJ

unread,
Jan 19, 2020, 1:57:42 AM1/19/20
to
On Sat, 18 Jan 2020 14:28:17 -0700, Jeff Barnett wrote:
>
> I find it interesting that the article headline says
> "Microsoft says it will fix an Internet Explorer security bug under
> active attack";
>
> The first paragraph says
> "Microsoft has confirmed a security flaw affecting Internet Explorer
> is currently being used by hackers, but that it has no immediate
> plans to fix";
>
> And the last line of the article says
> "Microsoft has confirmed a security flaw affecting Internet Explorer is
> currently being used by hackers, but that it has no immediate plans to
> fix".
>
> Taken all together, I'm quite confused. I think the writer of the
> article is headed to Washington, DC where he/she will have a very
> successful career in the current political situation.

Either way, the fact that the scripting engine is also used by Windows
Scripting Host which are still quite widely used to administer systems -
especially servers, and not just used by MSIE, I think Microsoft will
provide a patch for it.

Mayayana

unread,
Jan 19, 2020, 8:51:23 AM1/19/20
to
"JJ" <jj4p...@vfemail.net> wrote

| Either way, the fact that the scripting engine is also used by Windows
| Scripting Host which are still quite widely used to administer systems -
| especially servers, and not just used by MSIE, I think Microsoft will
| provide a patch for it.

I doubt that's true, though I'm not certain. My
understanding is that wscript.exe is the interpreter
for Windows scripting. IE probably has its own.

According to the articles I find, the bug is as yet
undescribed but is said to be similar to a recent Firefox
bug. That bug is related to their WebAssembly "JIT
compiler" monkey business, which has already had
problems in the past. But that won't stop them because
the browser makers are in a race to be the fastest at
handling several MB of javascript linked into a webpage.

I'm guessing those kinds
of bugs are only going to get worse as they try to
get webpage scripting as close as possible to compiled
software.

On the bright side, it seems to be possible to bypass
the JIT compiler in FF by setting all prefs with
"baselinejit" or "ion" to false.

The question, then, is how long has IE had JIT
compiling. Probably it can't be disabled in IE. But
does it date back a ways or is it only in IE 11? I
don't know and they may not tell us. (That's another
reason not to suspect a wscript tie-in. WScript hasn't
changed for years. Trying to pull off scam compiling
with browser javascript is a relatively new idea.)

But what kind of nut is going online with IE? People
using Win10 can now use Edg[Chrome] if they have IE
rendering issues with particular sites. People using
older systems can never have a fully up-to-date
version of IE. That was demonstrated with last week's
crypt32 bug. It's not a problem pre-Win10 because
IE doesn't update crypt32. The halfway tie-in with
the system has been a fatal flaw with IE ever since
IE4 with Active Desktop. No one should ever have been
using it for online browsing.

(Interestingly, the vulnerability last week was with elliptical
curve cryptography, exactly the thing that obiwan was
saying in the VB group would be one of the advancements
leaving behind XP eventually, in terms of security. :)


JJ

unread,
Jan 19, 2020, 3:11:35 PM1/19/20
to
On Sun, 19 Jan 2020 08:50:19 -0500, Mayayana wrote:
>
> I doubt that's true, though I'm not certain. My
> understanding is that wscript.exe is the interpreter
> for Windows scripting. IE probably has its own.

MSIE and WSH actually use the same JScript & VBScript engines. Both engines
are in VBSCRIPT.DLL and JSCRIPT.DLL. If they're renamed/deleted, none of
MSIE or WSH can run any VBScript/JScript code. It'll basically disable
VBScript and JScript in Windows.

Windows use this kind of architecture (i.e. modular scripting engine), so
that other languages such as Pascal, can be added. AFAIK, only one software
provides an additional scripting language: Rexx. It's usable in both MSIE
and WSH.

> According to the articles I find, the bug is as yet
> undescribed but is said to be similar to a recent Firefox
> bug. That bug is related to their WebAssembly "JIT
> compiler" monkey business, which has already had
> problems in the past.

The article pointed by OP doesn't mention anything about WebAssembly.
Moreover, it doesn't make sense. WebAssembly is not even supported by MSIE.
Not even in the Edge mode. Are you sure you're not reading a similar but
unrelated article?

The vurnerabily was described by below page, which is pointed by a Tweeter
post link mentioned in the page pointed by OP (first link of the article).

https://kb.cert.org/vuls/id/338824/

> I'm guessing those kinds
> of bugs are only going to get worse as they try to
> get webpage scripting as close as possible to compiled
> software.

The idea of giving web pages capability to execute compiled (binary) codes
is bad in the first place, because it's highly misusable. With or without
security flaw.

J. P. Gilliver (John)

unread,
Jan 19, 2020, 4:53:40 PM1/19/20
to
In message <poue376rnbw8.1x...@40tude.net>, JJ
<jj4p...@vfemail.net> writes:
[]
>The idea of giving web pages capability to execute compiled (binary) codes
>is bad in the first place, because it's highly misusable. With or without
>security flaw.

Even without malicious intent, isn't it a bad idea anyway, as compiled
code surely will only work on a specific processor? Or does "compiled"
not any longer mean what it did when I was using a compiler?
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

he was eventually struck off by the BMA in 1968 for not knowing his gluteus
maximus from his humerus.

Mayayana

unread,
Jan 19, 2020, 5:50:47 PM1/19/20
to
"JJ" <jj4p...@vfemail.net> wrote

| The article pointed by OP doesn't mention anything about WebAssembly.
| Moreover, it doesn't make sense. WebAssembly is not even supported by
MSIE.
| Not even in the Edge mode. Are you sure you're not reading a similar but
| unrelated article?
|

It said the bug is similar to the FF bug, which involves
JIT compiling, so I was guessing they meant the bug was
connected to JIT compiling. In that article they said MS
hadn't yet released details.

But from your link it sounds like it's actually an attack
on a very old vulnerability in jscript.dll. Interesting. There's
probably no reason to not just disable or rename that, unless
one uses jscript in WSH. Your link says it's been replaced by
jscript9.dll in later IE versions.

| > I'm guessing those kinds
| > of bugs are only going to get worse as they try to
| > get webpage scripting as close as possible to compiled
| > software.
|
| The idea of giving web pages capability to execute compiled (binary) codes
| is bad in the first place, because it's highly misusable. With or without
| security flaw.

Yes, but so is script. Anything executable is asking for
trouble. But what they're doing now with JIT compiling
is to try to optimize code during runtime. The examples
I've seen explained have been things like compiling the
operation for a code loop during operation if it repeats
numerous times.
It sounds very clever and apparently helps with speed,
but also introduces new risks.


Mayayana

unread,
Jan 19, 2020, 5:53:53 PM1/19/20
to
"J. P. Gilliver (John)" <G6...@255soft.uk>

| Even without malicious intent, isn't it a bad idea anyway, as compiled
| code surely will only work on a specific processor? Or does "compiled"
| not any longer mean what it did when I was using a compiler?

See my description above. It's not actually compiled
binaries, like ActiveX or Flash. It's selective compiling
within the process of interpreted code. The engine
assesses the script as it's running and looks for aspects
like repetitive operations that could be compiled on the
spot to a native code snippet. It's hard to believe that
could be efficient, but apparently it is. I imagine it's
mostly useful for things like online games.


Paul

unread,
Jan 19, 2020, 6:31:19 PM1/19/20
to
J. P. Gilliver (John) wrote:
> In message <poue376rnbw8.1x...@40tude.net>, JJ
> <jj4p...@vfemail.net> writes:
> []
>> The idea of giving web pages capability to execute compiled (binary)
>> codes
>> is bad in the first place, because it's highly misusable. With or without
>> security flaw.
>
> Even without malicious intent, isn't it a bad idea anyway, as compiled
> code surely will only work on a specific processor? Or does "compiled"
> not any longer mean what it did when I was using a compiler?

There is a webassembly website, which explains stuff at the four foot
level, when you want the 60,000 foot overview.

https://webassembly.org/docs/nondeterminism/

"WebAssembly is a portable sandboxed platform with..."

Portable means it has to run everywhere.

Sandboxed means (presumably), that when the code
executes, it can't write to your entire C: drive :-)

Whatever conversion they're doing at runtime (JIT),
it's going to be fast... and throw-away.

You can tell it's going to be fast, because the
article here shows they're throwing away the baby
with the bathwater.

"A library can freely choose to offer greater degrees
of undefined behavior, implementation-defined behavior,
unspecified behavior, and so on. This means it can perform
much more aggressive optimizations, including many that
are extremely common in optimizing compilers and might
otherwise seem missing in the WebAssembly spec itself:

Constant folding, strength reduction, and code motion
of math functions such as sin, cos, exp, log, pow, and atan2.

Performing aggressive expression simplifications that depend on
assuming that integer arithmetic doesn’t overflow. <=== are we having fun yet???

Performing GVN with redundant load elimination, and other
optimizations based on aliasing rules that incur
undefined behavior if they are violated. Vectorization
that utilizes both floating point reassociation and awareness
of the underlying platform through feature testing. <=== newer processor ? wildly
better code... will run
like shit on your P4.
"

Paul
0 new messages