Windows 0-day exploit used in Operation WizardOpium | Hacker News Reader

Windows 0-day exploit used in Operation WizardOpium

securelist.com

It's from 10 December, and more information, like what the .. is that "Operation" is here:

https://www.bleepingcomputer.com/news/security/windows-chrom...

"Last month, Kaspersky revealed that they discovered a zero-day Google Chrome vulnerability that was actively being used in online attacks called Operation WizardOpium.

The attackers had hacked a Korean-language news site and injected a JavaScript tag into the site that would execute malicious scripts in the visitor's browser."

Related discussion for a different exploit a couple months ago: https://news.ycombinator.com/item?id=21425804

> At the same time, it tries to leak a few kernel pointers using well-known techniques to leak kernel memory addresses (gSharedInfo, PEB’s GdiSharedHandleTable).

Wait, Windows exports kernel address to userspace?!

> Wait, Windows exports kernel address to userspace?!

Dont know about these particular calls. But info leaks where a kernel address is leaked are apparently quite common. They're usually fixed when found. But this is the reason OpenBSD relinks the kernel every boot in a random order. [0]

Its's too easy to leak a pointer and invalidate KASLR, because now you can calculate the KASLR offset.

The 'well known' part does seem a bit weird though.

[0] https://security.stackexchange.com/questions/163565/openbsd-...

Edit: https://github.com/sam-b/windows_kernel_address_leaks/blob/m...

Seems windows patches them too, sometimes. Checking the rest of the repo they don't seem to care much though.

Windows doesn't have a monolithic kernel like *nix so it's not an apples to apples comparison iirc

If you are talking about mapping kernel address space into userland Linux does that too (or at least did until Spectre). It's a performance win because you don't need to flush the TLB on every syscall. You can't normally access the data because only ring0 may actually read from it.

GDI objects make these even more complicated because they were originally designed to be fully userspace, but were moved to kernel for performance reasons back in the NT 4 days. "Security" meant something quite different back in the early 90s when this was done.

> You can't normally access the data because only ring0 may actually read from it.

It seems like it's the case here where normal, unprivileged code can just read out kernel pointers. I don't know of any other well-used platform that makes it this easy.

Yup but that is a bug not the intended design. The intended design is kernel memory is mapped but not accessible. GDI just makes this much more difficult because of its history.

FWIW most data in GDI objects is non critical. It doesn’t really matter if a process corrupts a brush to be red instead of green. So some GDI data is allowed to be user space accessible.

The mixed ownership is indeed a design "flaw" but it comes from the fact that GDI was initially 100% userspace (in win NT). FWIW GDI has been superseded by D2D which has a better design.

GDI dates back to the very first version of Windows, which was capable of running on the 8088 CPU in real mode. The concept of "userspace" was pretty weak, since the CPU didn't support protected mode. GDI obviously ran with full CPU privileges and was built-in to Windows, so "initially 100% userspace" doesn't make very much sense unless you only count MS-DOS as being non-userspace.

This is very much specific to NT's implementation. Originally they did the right thing and put it in userspace. Performance made them rethink that in NT 4. The NT story is most relevant since the vulnerable version in this story is a descendent of NT not of the DOS/Win 9X lineage. Windows NT is a from scratch rewrite.

You are correct GDI as an interface predates NT and protected mode in general, but the codebase used in NT is a different implementation.

Couldn't figure out what "operation wizardopium" is. Google simply points back to this article or other reflections of it. Can anyone clue me in please?

https://securelist.com/chrome-0-day-exploit-cve-2019-13720-u...

First link in the article. It's a codename Kaspersky is using for this attack campaign.

To me it feels like Windows Task Scheduler is often exploited by malware. It seems it's too easy to add something here once you manage to get remote execution.

> Operation WizardOpium

Life is no longer distinct from a William Gibson novel.

The title is a bit misleading, it's a Chrome on Windows exploit. I realize many people use Chrome but the 0-day is mis-attributed.

It's not. The first paragraph mentions an earlier discovered exploit for Chrome, and the rest is about a Windows 0-day that was also used in the same attack.

"Successfully detected" is an awkward phrase. Can you unsuccessfully detect something?

Yes, by detecting the damage it has caused after the fact. It's the difference between "we have that missile on radar" and "we know we were hit by a missile because we are dead."

C'mon - a super interesting technical article on how an exploit gets an arbitrary kernel read/write primitive... and you have to take it down because of an "awkward phrase" in the first paragraph? What's the point of such a comment?

It was a legitimate question about the use of language. You are correct it was an interesting article; someone clearly spent a lot of time and effort writing it. Which is why I thought it was strange that it started put so awkwardly and was curious if there was more to the phrase than I realized.

Successful detection would follow a probing routine. The opposite, or rather other outcome of the probing routing would be No Detection Was Made. It is a reflection of the outcome of the probing routine I"d say.

It's how computer programs talk! :)

Damnit. They're going to make me patch during Xmas.

Bah.

https://portal.msrc.microsoft.com/en-US/security-guidance/ad...

Published 13 days ago. You can subscribe for securuty bulletin.

If by 'they', you mean the blackhats for discovering and abusing the exploits then yes.

I imagine MS/Chrome will treat this as an emergency out-of-cycle patch which I don't think many people would disagree with :)

Reply on news.ycombinator.com