Chrome 69.0.3497.81 released

Status
Not open for further replies.

DeepWeb

Level 25
Verified
Top Poster
Well-known
Jul 1, 2017
1,396
Chrome 69 is so buggy.... I can't deal with this nonsense. The first time I really want to downgrade.
 
  • Like
Reactions: JB007

uninfected1

Level 11
Verified
Top Poster
Well-known
Jan 28, 2016
525
Fairly minor point but looks like you still can't hide the bookmarks bar in new tabs without having to install an extension. Firefox seems to have improved recently so may use that more.
 

Windows_Security

Level 24
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Mar 13, 2016
1,298
btw, isn't this version that was supposed to block every 3rd party code injection?

MemProtect Free is driver based security: MemProtect - Products | Excubits

Just change example MemProtect.ini file and copy it to your Windows folder (don't include lines ___ )
______________________________________________________________________
[#LETHAL]
[LOGGING]

[#INSTALLMODE]
[DEFAULTALLOW]
[#MODULEFILTER]

[WHITELIST]
# Allow Chrome to access memory of executables in own folders
!*\Chrome\*>*\Chrome\*

[BLACKLIST]
# Block Chrome to manipulate memory of all other programs
*\Chrome\*>*

[MODULEWHITELIST]
[MODULEBLACKLIST]
[EOF]
______________________________________________________________________

How MemProtect works
MemProtect uses a build in Windows mechanism which is used to protect essential (Windows or AntiVirus) processes from tampering. Most security solutions use this to protect their own processes from being changed or closed. When an executable tries to access memory for update or tries to inject code which is protected by MemProtect, that process will be suspended. You won't be able to close these suspended processes with Process Explorer for example.

MemProtect driver intercepts inter-process calls and checks whether the parent or child process originates from a path which is specified in the INI-file. When a path is blacklisted it strips process access rights from the (in this case originating) path. Process access rights it strips are:
- PROCESS_CREATE_PROCESS
- PROCESS_TERMINATE
- PROCESS_VM_OPERATION
- PROCESS_VM_READ
- PROCESS_CREATE_THREAD
- PROCESS_VM_WRITE
- PROCESS_SUSPEND_RESUME
- PROCESS_QUERY_INFORMATION
- PROCESS_ALL_ACCESS
- DELETE
- READ_CONTROL
- WRITE_DAC
- WRITE_OWNER
- SYNCHRONIZE
- PROCESS_DUP_HANDLE
- PROCESS_SET_QUOTA

In the INI-file included there is a priority whitelist rule (starting with !). A priority whitelist (!*\Google\*>*\Google\*) overules the blacklist (*\Google\*>*), this allows chrome to call chrome update (in programs files) and its build-in malware scanner (in USER\AppData\Local). Rules are in A>B format where A is parent and B is child. E.g. blacklist rule *\Google\*>* This rule blocks parents from *\Google\* messing (>) with childs in * (everything, asterix is wild card).

Because it is using windows mechanims to protect processes from being manipulated (removing acess rights), it won't provide compatibility problems (as with HitmanProAlert for example) and because it does not inject DLL's (like MBAE for example), Chrome won't ask you to remove it either. Best of all it is free (with the only drawback that you need to update driver manually every year).

IMPORTANT: post install check
The INI file above starts MemProtec in logging mode. After checking MemProtect.log file you can enable protection (remove hash tag # before LETHAL) and disable LOGGING (add #) . When Chrome is blocked accessing other programs that is normal (e.g. access Explorer), but when other programs are blocked you should not enable LETHAL mode protection. Remember it uses Windows internals, so the only restore option in case you mess up is boot into safe mode and use ServiceControl command to delete it or use an image restore to revert to pre-install. It is the most powerful exploit protection available, but when configured wrong it certainly will explode in your face.

This freebie is for experienced members only. There are two reasons MemProtect does not has a user interface. First to prevent inexperienced people to use it. Second a user interface lives in user land, so its interface with the driver in kernel mode (to pass settings and user changes), theoretical introduces a weak (exploitable) link to the kernel.

First two lines of your MemProtect.ini file should look like this to enable protection (and yes it is lethal when configured wrong :) )
______________________________________________________________________
[LETHAL]
[#LOGGING]
 
Last edited:
D

Deleted member 178

Are the blocks purely meant to be against code injection for things like anti-exploit or is it also going to be against how AVs scan encrypted traffic and such?
no ideas, the announcement was quite vague but i bet it will be any kind of injections.
 
  • Like
Reactions: oldschool and JB007

Gandalf_The_Grey

Level 76
Thread author
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Apr 24, 2016
6,564
It "solved" the Kaspersky ERR_SSL_VERSION_INTERFERENCE error, but I still see Kasperkys root certificate, the geen safe indicators on a Google search and malware sites are still blocked by Kaspersky. So it blocked some injections, but not all?
 

Windows_Security

Level 24
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Mar 13, 2016
1,298
It "solved" the Kaspersky ERR_SSL_VERSION_INTERFERENCE error, but I still see Kasperkys root certificate, the geen safe indicators on a Google search and malware sites are still blocked by Kaspersky. So it blocked some injections, but not all?
Probably only user land dll injections, because that is the oldest and most common way to get a grip on medium IL processes in general. Also chrome broker process runs at Medium IL, so it is the maximum they can achieve with their current architecture.

MBAE selectively injects code in protected processes (remember old critique that MBAE is partly based on userland techniques) . HPMA uses the AppInit DLL technique to inject its DLL in every process. This technique (AppInit DLL) iis used by malware mostly, that is why SysHardener has an option to disable this. AppInit Dll is set in regsitry (HKLM) so should bypass Chrome's userland injecttion protection,
 
Last edited:

Gandalf_The_Grey

Level 76
Thread author
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Apr 24, 2016
6,564

Venustus

Level 59
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Dec 30, 2012
4,809
Adding the parameter
Code:
/high-dpi-support=1 /force-device-scale-factor=1
works.
Chrome is as default 100% and then I use Chrome's zooming at 125%.
That way Chrome's interface stays small (100%) but the text on web pages is with 125% readable for me and not blurry.
It's a temporary fix.
Great!!:)
 
  • Like
Reactions: Gandalf_The_Grey

Windows_Security

Level 24
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Mar 13, 2016
1,298
@Windows_Security i wondered if v69 implemnted the blocks.

I read that Chrome is not actually checking whether injected DLL's cause problems (source - Pedro Bustamante of MBAE). So maybe Chrome is not blocking DLL injection at all. Just monitoring third-party DLL's would also overome the limitation of what the medium IL chrome broker can block.

Knowing Chrome it probably is just using marketing tactics to scare away users from targetted security products. Vendors probably won't risk the reputation damage it would generate and cut their losses (losses would probably be real when you consider the customer support hours waisted by worried users contacting the helpdesk).
 
E

Eddie Morra

AppInit Dll is set in regsitry (HKLM) so should bypass Chrome's userland injecttion protection
AppInit_DLLs injection is user-mode based - and it only applies to processes which use User32.dll.

When User32.dll is loaded into the context of a process, its main entry-point routine named UserClientDllInitialize is invoked and eventually a routine named ClientThreadSetup will be invoked; depending on a number of checks internally performed, a routine named LoadAppInitDlls which is exported by Kernel32.dll will be called.


ClientThreadInitialize.png

The above figure shows some of the disassembly for the ClientThreadSetup routine from a 64-bit User32.dll (Windows 10 64-bit, latest version).


The LoadAppInitDlls routine will use the RegOpenKeyExW (Win32 API) routine to get a handle to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows key, and if successful, will pass this key handle to another routine - which we'll call "LoadAppInitDllsInternal" for now but remember that I've just made up that name for the sake of this post.

The "LoadAppInitDllsInternal" routine will do the following in order:
1. Check the key value for RequireSignedAppInit_DLLs
2.
Check the key value for AppInit_DLLs
3.
Call LoadLibraryExW to load the applicable modules listed under AppInit_DLLs

The RegGetValueW (Win32 API) routine is used to query the data of key values (for RequireSignedAppInit_DLLs and AppInit_DLLs) - which internally relies on the NtQueryValueKey (Native API) routine. If the return value from RegGetValueW is zero (ERROR_SUCCESS) (as well as the queried data being >= 1) when it is being used for the RequireSignedAppInit_DLLs check, then the undocumented flag IMAGE_DLLCHARACTERTISTICS_FORCE_INTEGRITY (0x80) will be passed for the Flags argument on all of the LoadLibraryExW calls for the AppInit_DLLs operation.


RequireSignedAppInit_DLLs.png

The above figure shows some pseudo-code from IDA-64 on a routine from a 64-bit User32.dll (Windows 10 64-bit, latest version).


It goes without saying that AppInit_DLLs injection will not work on Secure Boot enabled environments and is apparently preventable through process mitigation policies.

This research was conducted on an up-to-date version of Windows 10 (64-bit environment) with User32.dll and Kernel32.dll (64-bit versions of the modules only) - the information provided within this post is subject to change in the future and the AppInit_DLLs integration is likely going to have implementation detail differences on older major versions of Windows (e.g. Windows Vista and 7).
 
L

Local Host

AppInit_DLLs injection is user-mode based - and it only applies to processes which use User32.dll.

When User32.dll is loaded into the context of a process, its main entry-point routine named UserClientDllInitialize is invoked and eventually a routine named ClientThreadSetup will be invoked; depending on a number of checks internally performed, a routine named LoadAppInitDlls which is exported by Kernel32.dll will be called.


View attachment 197269
The above figure shows some of the disassembly for the ClientThreadSetup routine from a 64-bit User32.dll (Windows 10 64-bit, latest version).


The LoadAppInitDlls routine will use the RegOpenKeyExW (Win32 API) routine to get a handle to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows key, and if successful, will pass this key handle to another routine - which we'll call "LoadAppInitDllsInternal" for now but remember that I've just made up that name for the sake of this post.

The "LoadAppInitDllsInternal" routine will do the following in order:
1. Check the key value for RequireSignedAppInit_DLLs
2.
Check the key value for AppInit_DLLs
3.
Call LoadLibraryExW to load the applicable modules listed under AppInit_DLLs

The RegGetValueW (Win32 API) routine is used to query the data of key values (for RequireSignedAppInit_DLLs and AppInit_DLLs) - which internally relies on the NtQueryValueKey (Native API) routine. If the return value from RegGetValueW is zero (ERROR_SUCCESS) (as well as the queried data being >= 1) when it is being used for the RequireSignedAppInit_DLLs check, then the undocumented flag IMAGE_DLLCHARACTERTISTICS_FORCE_INTEGRITY (0x80) will be passed for the Flags argument on all of the LoadLibraryExW calls for the AppInit_DLLs operation.


View attachment 197271
The above figure shows some pseudo-code from IDA-64 on a routine from a 64-bit User32.dll (Windows 10 64-bit, latest version).


It goes without saying that AppInit_DLLs injection will not work on Secure Boot enabled environments and is apparently preventable through process mitigation policies.

This research was conducted on an up-to-date version of Windows 10 (64-bit environment) with User32.dll and Kernel32.dll (64-bit versions of the modules only) - the information provided within this post is subject to change in the future and the AppInit_DLLs integration is likely going to have implementation detail differences on older major versions of Windows (e.g. Windows Vista and 7).
You can easily make a driver to hook to any process through the kernel... There's actually drivers like that available (as open source).

You'll find you'll have success hooking and tampering with Chrome by using Cheat Engine (which uses such driver).
 
Status
Not open for further replies.

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top