Google Says No to Third-Party Code Injection in Chrome

[DooKey]

Over the next 14 months Google will begin blocking third-party software from injecting code in Chrome. They plan on doing this in three phases with the final phase to take effect in January of 2019. The only vendors that will be allowed to do so after that time are Mircosoft, accessibility software and Input Method Editor type-assist software. Lots of antivirus companies use code injection to scan for malware and they are going to have to update their software if they want it to keep working with Chrome.

The search giant recommends that software vendors update their coding methods and use modern Chrome features such as browser extensions or the Native Messaging API, instead of the antiquated practice of code injection.

 

[dgingeri]

This is bothersome. I used addons that do this to get the best pricing on parts. I may have to stop using Chrome.

 

[ChadD]

Not sure how anyone could defend code injection as a good software practice. It doesn't just cause instability its a major security issue. I can't think of any good reasons to build your software in such a way.

I mean developers options are to use the framework of hooks Google (and other browser developers provide) which are supported, stable, more secure and some google patch down the road won't change.

Or do your own thing inject the code and have to be constantly tracking bugs and changing code as the core browser code evolves. The only advantage to such development I can think of is nefarious.

Really I'm sort of surrpsied to hear their are legit accesibility tools ect using code injection with chrome.

I mean isn't code injection issues one of the main reasons none of us want to be running flash ect.... good on Google for doing more to discourage lazy poor development aimed at breaking their software, or worse injecting malicious software on their users machines.

 

[LogicEarht]

This is bothersome. I used addons that do this to get the best pricing on parts. I may have to stop using Chrome.

This only would affect you if your price checking is external software. Is it external software from Chrome? Or is it a Chrome extension? This does not affect extensions.

 

[dgingeri]

This only would affect you if your price checking is external software. Is it external software from Chrome? Or is it a Chrome extension? This does not affect extensions.

I guess I misunderstood what it was saying. I thought it was over extensions like Hoverhound.

 

[risc]

It's so bad, only Microsoft can do it!

 

[kllrnohj]

I guess I misunderstood what it was saying. I thought it was over extensions like Hoverhound.

No, it's things like antivirus software that inject themselves into Chrome via DLL injection, memory patching, or similar. Think how cheats inject themselves into games. Rootkits for your browser, delivered by your antivirus software. Sounds like a great idea, right?

 

[dgz]

back to duopoly I suppose

 

[elation]

Hyper-v in win 10 1709 does this. Ended up crashing due to stopping all non-MS dll loads. If you use personalization software like Ivanti/AppSense, this will be a problem. Say bye bye to bookmarks and hello pissed off users.

 

[socK]

Not sure how anyone could defend code injection as a good software practice. It doesn't just cause instability its a major security issue. I can't think of any good reasons to build your software in such a way.

I mean developers e injecting malicious software on their users machines.

You wouldn't have things like steam overlay or software to record your gameplay otherwise.

 

[ChadD]

You wouldn't have things like steam overlay or software to record your gameplay otherwise.

Actually not true in most cases. I would suggest the ones using actual code injection are ones to stay well clear of.

Steam overlay hooks properly into direct3d / opengl and vulcan. It however does not work with mac games running metal. It does not use code injection like a virus. If Steam used code injection games would be crashing all over the place. For more advanced features like purchases through steams wallet companies need to code to hook into steams overlay api. Although in their FAQ they state steam overlay "injects" itself I don't believe this is exactly the same type of method Google is talking about with chrome injection. Hooking into a 3D API that has hooks to do that isn't quite the same... at least as I understand it.

As for game recording / screen shot software... almost all I have seen likewise use proper DX/OpenGL hooks. I imagine all the majors now support vulcan as well but that support had to be added.

 

[socK]

How do you think they hook the renderer?



Injection is perfectly valid and MS provides you all the tools to do it - including an Win32 API call that handles it for you, and even a registry key to request the OS inject something for you, though it's been tightened down a bit in more recent Windows releases and I think requires signed dll's if you go that route.

There's also literally an "inject-helper.exe" within OBS's folder, and I regret to inform you, but that "gameoverlayrenderer64.dll" in Steam's directory is getting jammed straight up your game's ass.

 

[ChadD]

How do you think they hook the renderer?


Injection is perfectly valid and MS provides you all the tools to do it - including an Win32 API call that handles it for you, and even a registry key to request the OS inject something for you - though it's been tightened down a bit in more recent Windows releases and I think requires signed dll's if you go that route.

There's also literally an "inject-helper.exe" within OBS's folder.

Fair enough.... more reasons I hate MS then.

Really though if they are providing API calls I would still say its not the type of "injection" google is talking about. Google likewise provides a proper way to "inject" code into their browser via extensions.

No matter how MS implements it... in general windows would be more stable if software developers refrained from using pure injection methods as a rule.

 

[socK]

I hate to tell you, but similar things are possible on other OS (and often used)

See LD_PRELOAD on Linux, which looks to be what Steam uses to provide the overlay.

 

[ChadD]

I hate to tell you, but similar things are possible on other OS (and often used)

See LD_PRELOAD on Linux, which looks to be what Steam uses to provide the overlay.

Well they aren't really on the same level. lol But sure LD_Preload does allow for injection on new processes. The user must also own the file that will be preloading your libraries... so its not really very useful in any real nefarious way. As a debug tool it works well... and as for steam ldpreload is a useful way to ensure games are loading libraries a game developer supports instead of newer libraries on users machines.
As an example
env LD_PRELOAD='/usr/lib64/libstdc++.so.6' steam
is a common work around you will see for people using newer open source drivers that give some older games issues. I believe in some cases yes when you download specific Linux games steam adds the proper launch variables for games that don't play nice with some newer libraries.

The ld_preload env variable is simply not on the same level as DLL injection under windows where you can do much more fun things like inject things into running processes. My comment about MS was aimed more at the way they seemingly help with injection far beyond simple DLL preloading.

 

[socK]

I hate to further inform you but it's also possible to write to another processes' memory in Linux

 

[ChadD]

I hate to further inform you but it's also possible to write to another processes' memory in Linux

The point isn't that its possible. The point is MS does nothing to actively discourage developers using it for "legit" software... and seem to go out of their way to encourage it. That coupled with windows lax rights management = lots of fairly easy to exploit attack vectors, and lots of software that isn't nefarious but none the less tends to F with windows systems. Which is the main reason I would have expected MS to lock things down better then they have... in general programs using injection methods for legit purposes tend to make things unstable... as google is saying. Things like LD_preload are useful tools... but I building an entire software package aimed at regular users around doing things that way isn't a great development path.

 

[socK]

I'm not sure why you think it's some mystical, special thing.

A common method (using Windows as an example) ultimately coaxes the process into calling LoadLibrary() on an arbitrary DLL, same as if you were doing it yourself. Naturally, the OS obliges and if you look using a tool like Process Monitor, you'll even find it in the loaded modules list. If you have MSI Afterburner or FRAPS running, go check out programs. You'll find their hooks everywhere.

Functions are subsequently intercepted - and that's how software draws its own stuff like overlays, etc.

Extremely common and well used software all do this. Some of these have multiple millions upon millions of active users.
FRAPS
MSI Afterburner
Steam
Origin
Uplay
Shadowplay
OBS
Mumble
Discord

Also the same thing works on Linux.

in general programs using injection methods for legit purposes tend to make things unstable... as google is saying. Things like LD_preload are useful tools... but I building an entire software package aimed at regular users around doing things that way isn't a great development path.

Citation needed

Although yes, I do agree that if there's a native API available and they can do the same thing, then it's a good idea to go that route.