Hacker News new | past | comments | ask | show | jobs | submit login

How is this going to be achieved? As far as I know, programs have no say on whether a DLL can be injected into their module list / address space by an elevated process.

We've had a blocklist in Firefox for specific DLLs that cause major issues (usually crashes) for ages: https://dxr.mozilla.org/mozilla-central/rev/574f4f58fe09dd59...

I assume Chrome is just planning to make that block everything that's not Google or Microsoft code, probably with a short whitelist of things that are necessary.

Hmm. I guess trashing your local LoadLibrary copy will stop 90% of software not specifically targeting Chrome... but that's still trivial to circumvent. I thought perhaps there is some Windows feature that could be taken advantage of, something like Internet Explorer's protected mode.

There is also "Protected Processes".


The AV vendors need to ship the Chrome injection code to their customers, which includes the Chrome development team. And the Chrome announcement says explicitly that Google is willing to stop Chrome, so the AV vendors have to carry out the injection in such a way that it cannot even be detected after the fact.

A real challenge.

And DLL injection is just the userspace solution. How will they deal with kernel-based code injection ?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact