Microsoft: Sorry not sorry, Google Crome is malware now || Microsoft Defender error causes a false positive flagging Google crome updates

[Mark Kaine]

34 minutes ago, leadeater said:

What I don't know is if this applies to only user installed per account Google Chrome installs or All Users system installed, that difference could well matter.

 

What program is this? Virustotal? 

 

35 minutes ago, leadeater said:

dll

... so about dlls, i know its a tricky thing, but generally,  can AV like defender see if a dll is malicious (sometimes) or is it just always something they ignore?

 

I gotta say i havent really paid attention to the file extensions, but the only thing that defender usually finds are things that can "inject" other things... and its seemingly very random, i mean one file may not be detected,  but another doing basically the same is... and typically both would be "false positives"... and in 99% MWB says its good lol, anyways, unclear how dlls actually work? 

[leadeater]

9 minutes ago, Mark Kaine said:

What program is this? Virustotal? 

It's not a program, it's the Microsoft Defender for Endpoint admin portal, security.microsoft.com

 

9 minutes ago, Mark Kaine said:

... so about dlls, i know its a tricky thing, but generally,  can AV like defender see if a dll is malicious (sometimes) or is it just always something they ignore?

dll can be inspected yes, but you don't need to when a dll is trying to replace another dll and the one being replaced is signed and the one replacing it isn't, along with the updater application not being signed too.

 

But this has nothing to do with file content/code inspection, it's just behavior monitoring and pulling in a dll with the same name as an existing one and it's not signed like the current one is security wise is a huge red flag. Makes no difference if the dll/file is malicious or not, you don't allow that kind of activity.

 

[Mark Kaine]

7 minutes ago, leadeater said:

It's not a program, it's the Microsoft Defender for Endpoint admin portal, security.microsoft.com

Ah ok, i see.

 

7 minutes ago, leadeater said:

dll can be inspected yes, but you don't need to when a dll is trying to replace another dll and the one being replaced is signed and the one replacing it isn't, along with the updater application not being signed too.

 

But this has nothing to do with file content/code inspection, it's just behavior monitoring and pulling in a dll with the same name as an existing one and it's not signed like the current one is security wise is a huge red flag. Makes no difference if the dll/file is malicious or not, you don't allow that kind of activity.

i see, yeah i understand in this case its the replacing part (and being unsigned) thats problematic. I think most of my dlls dont replace anything,  they just get added...

 

I was just wondering because usually people advice not to download random dlls because its "dangerous" (and i dont, i always try finding more info/check with AVs...) but in the end i have hundreds if not thousands of dlls (and most wont be signed, signing files isnt something most modders are into xD)

 

Oh and also sometimes, but not always they seem to be interchangeable... kinda confusing. 

 

 

^but basically,  to my understanding,  these are always used to make a program think "yeah, this is totallly legit..." when it really isnt lol .

Guess I'll do some digging (but i already know its complicated...)

[LAwLz]

57 minutes ago, leadeater said:

I'd read my above post, Google isn't so "not to blame here" heh. Also not a good idea security wise to just flag these known files as trusted and then ignore them, that's why signing exists and that's why the files not being signed through all stages of the update process is a problem.

Interesting.

The source I read did not specify that unsigned code from Google were trying to replace signed code. That makes it seem less like a Microsoft issue and more of a Google issue. Thanks for the info.

The source I read basically just said Microsoft updated something and then it started flagging Chrome's update as malware. But if the issue is how Chrome updates itself, I wonder how they fixed it. Like you said, you generally don't want to just flag files as trusted so that it bypasses checks.

[leadeater]

28 minutes ago, LAwLz said:

Interesting.

The source I read did not specify that unsigned code from Google were trying to replace signed code. That makes it seem less like a Microsoft issue and more of a Google issue. Thanks for the info.

The source I read basically just said Microsoft updated something and then it started flagging Chrome's update as malware. But if the issue is how Chrome updates itself, I wonder how they fixed it. Like you said, you generally don't want to just flag files as trusted so that it bypasses checks.

Well considering Microsoft were the ones to fix it, and not Google, and the whole issues of the files not being signed then the same files being signed later it doesn't actually rule out a bug or some brokenness in the MDE process of evaluating files as they get changed etc. I don't know, I haven't gone through the effort of tracing and profiling the Google Chrome Updater process to watch each step and break point it so the files can be inspected at each step.

 

Note this is most likely how it's always been for Chrome updates so it would have been a Microsoft MDE/EDR logic update/change, I just don't know whos to blame other than MS/MDE saying at some stage the files are not signed according to it. The truth could well be more complicated.

 

29 minutes ago, Mark Kaine said:

i see, yeah i understand in this case its the replacing part (and being unsigned) thats problematic. I think most of my dlls dont replace anything,  they just get added...

 

I was just wondering because usually people advice not to download random dlls because its "dangerous" (and i dont, i always try finding more info/check with AVs...) but in the end i have hundreds if not thousands of dlls (and most wont be signed, signing files isnt something most modders are into xD)

The actual dll files need replacing with the newer ones, that's just part of application updates. dll are just files until you actually do something with them.

 

The flow, looking at MDE portal is quite interesting (based on the Chrome install I am looking at).

1. Google Chrome Update service initiates an application update process, 'Google Update Service (gupdate)'. This is the first 3 lines in the picture.
2. GoogleUpdate.exe (the actual service executable) starts a child process GoogleUpdateSetup.exe
3. GoogleUpdateSetup.exe downloads the latest Chrome files to user profile Temp directory
4. GoogleUpdate.exe tried to pick these new files up and replace the existing/old files with the new ones
5. MDE freaks out because the files in the user profile Temp directory don't have the Google signing on them where as the existing ones do

 

GoogleUpdate.exe would normally load the gooupdate.dll dll during a version update check so MDE knows this process would normally be loading and interacting with a signed dll of this name. So MDE suspects that GoogleUpdate.exe is loading a nontrusted and abnormal dll compared to the one it would normally be using based upon this difference, hence could be a malicious dll side-load.