How can I know if I was infected and what can I do about it?
You should follow the same procedure as you do for any other, disclosed or undisclosed, infections and vulnerabilities.
Please let us know what your procedure is?
Chrome 0-day exploit used in Operation WizardOpium
51–60 of 159 posts
Re: Chrome 0-day exploit used in Operation WizardOpium
#52Re: Chrome 0-day exploit used in Operation WizardOpium
#53> "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.
> This is why C++ needs to be retired; and why we need to use safer languages.
These problems can easily happen in a language like Go, unfortunately. Go is memory safe for sequential code, but that guarantee does not extend to in-process concurrency - Goroutines can access shared state without synchronization, and create memory unsafety.
Re: Chrome 0-day exploit used in Operation WizardOpium
#54> "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.
Maybe. I'm happy to run any formally verified C as my basement, for example the seL4 kernel, or for C to be used as an intermediate language. Especially as there should be less code at the bottom of the stack. But C++ seems worse, it's a far more complex language, designed and built to try and scale C to building applications. This creates a far larger attack surface.
Re: Chrome 0-day exploit used in Operation WizardOpium
#55> "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.
> This is why C++ needs to be retired; and why we need to use safer languages. These problems can easily happen in a language like Go, unfortunately. Go is memory safe for sequential code, but that guarantee does not extend to in-process concurrency - Goroutines can access shared state without synchronization, and create memory unsafety.
What do you mean by memory unsafety? A stale read would be bad, but wouldn't lead to arbitrary code execution.
Re: Chrome 0-day exploit used in Operation WizardOpium
#56Is 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?
I'll also ask is Chromium affected? And does that mean Chrome-based browsers on Android are affected too?
Re: Chrome 0-day exploit used in Operation WizardOpium
#57Earlier quoted context omitted.
You should follow the same procedure as you do for any other, disclosed or undisclosed, infections and vulnerabilities.
Please let us know what your procedure is?
It’s checking for chrome versions below the current, 78, so update to that. You also have to be on Windows. On windows, make sure you have your antivirus setup to block random executables from download and execution. I’d also block those hosts at the firewall and dns. It gets more complicated from there if you’re infected. But you probably aren’t.
Edit-just realized you actually asked for how to tell if you were infected. Check the windows task scheduler for unknown tasks. It installs items there for persistence. Edit-search your history and hard drive for “behindcorona” domains. That’s where it loads things from. There are more specifics in the page.
Re: Chrome 0-day exploit used in Operation WizardOpium
#58> "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.
> This is why C++ needs to be retired; and why we need to use safer languages. These problems can easily happen in a language like Go, unfortunately. Go is memory safe for sequential code, but that guarantee does not extend to in-process concurrency - Goroutines can access shared state without synchronization, and create memory unsafety.
Go isn’t really a C++ replacement. I‘m not sure if that solves this particular issue, Rust is provably free of data races (excluding unsafe).
Re: Chrome 0-day exploit used in Operation WizardOpium
#59This is why I started disabling js by default using ublock origin. I whitelist the websites that I'm interested in but at least I avoid a lots of exploits that requires js. This is in case if I'm unlucky and I land in one of those websites with malicious js. I discovered duckduckgo doesn't block websites as eagerly as Google and landed in a few tricky places.
Re: Chrome 0-day exploit used in Operation WizardOpium
#60Earlier quoted context omitted.
> This is why C++ needs to be retired; and why we need to use safer languages. These problems can easily happen in a language like Go, unfortunately. Go is memory safe for sequential code, but that guarantee does not extend to in-process concurrency - Goroutines can access shared state without synchronization, and create memory unsafety.
What do you mean by memory unsafety? A stale read would be bad, but wouldn't lead to arbitrary code execution.
A 'stale' read of atomic data may be fine (it wouldn't really be "unsynchronized" in that sense), but as soon as you're dealing with stuff that's not completely atomic in-hardware and need actual synchronization, there's a potential of breaking expected invariants and creating further unsafety as a consequence of that.