Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome 0-day exploit used in Operation WizardOpium

securelist.com

Post reply on HN
Print view View original

41–50 of 159 posts

Re: Chrome 0-day exploit used in Operation WizardOpium

#42

Post by haecceity »

lovelearning wrote: post #26

As I understand these RCEs (in general; perhaps not this particular one), a frequent root cause seems to be saving instruction pointer on the stack adjacent to untrustworthy data which may have propagated down the call chain. Are there no initiatives being attempted to change this convention? Like not save the IP on the stack? Perhaps at the CPU architecture level or at the compiler level?

Control flow integrity is the group of techniques meant to deal with this problem. There are settings for Microsoft’s cpp compiler to enable them but the best way to accomplish this is with a hardware shadow stack. Intel cet does this but I’m not sure when the hardware will be available.

Re: Chrome 0-day exploit used in Operation WizardOpium

#44

Post by willtim »

> "The exploit used a race condition bug between two threads due to missing proper synchronization between them. It gives an attacker a Use-After-Free (UaF) condition that is very dangerous because it can lead to code execution scenarios"

This is why C++ needs to be retired; and why we need to use safer languages. Not even Google can write safe C++. Thankfully Mozilla have already realised this.

Re: Chrome 0-day exploit used in Operation WizardOpium

#46

Post by cjbprime »

lovelearning wrote: post #26

As I understand these RCEs (in general; perhaps not this particular one), a frequent root cause seems to be saving instruction pointer on the stack adjacent to untrustworthy data which may have propagated down the call chain. Are there no initiatives being attempted to change this convention? Like not save the IP on the stack? Perhaps at the CPU architecture level or at the compiler level?

There are already many modern mitigations present to defeat the kind of stack overflow control of the instruction pointer that you're imagining -- stack canaries, DEP, ASLR, NX, and others.

Simply gaining control of the instruction pointer through a stack overflow as you describe stopped working a decade or so ago due to these mitigations.

Re: Chrome 0-day exploit used in Operation WizardOpium

#47

Post by pjmlp »

willtim wrote: post #44

> "The exploit used a race condition bug between two threads due to missing proper synchronization between them. It gives an attacker a Use-After-Free (UaF) condition that is very dangerous because it can lead to code execution scenarios" This is why C++ needs to be retired; and why we need to use safer languages. Not even Google can write safe C++. Thankfully Mozilla have already realised this.

We should start by retiring C.

It doesn't matter if userspace is fully safe, when the basement looks like a Swiss cheese of security.

Re: Chrome 0-day exploit used in Operation WizardOpium

#48

Post by BLKNSLVR »

anovikov wrote: post #9

Tragedy of our generation is that people who are so smart and determined to find and exploit these vulnerabilities, can't find better uses for their talents.

It's not limited to "our generation", these lyrics are from 1966: https://www.azlyrics.com/lyrics/frankzappa/hungryfreaksdaddy...

Re: Chrome 0-day exploit used in Operation WizardOpium

#49

Post by tekni5 »

Is there anyway to test this on other chrome based browsers?

For example current version of Iridium is 2019.04.73.0(based on Chromium 73.0.3683.103), it doesn't get updated that often but a useful and stable browser.

Anyway to mitigate this exploit via any setting or extension?

Post reply on HN