You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The program is composed of several binaries as of 3.7.4 build 5725:
UninstallTool.exe, the GUI.
UninstallToolHelper.exe, going by its name, some helper.
CisUtMonitor.sys, filter driver involved in tracing.
UTShellExt.dll, shell extension.
UninstallTool.cpl, Control Panel applet?
Only the filter driver is built with permanent DEP, high entropy ASLR and Control Flow Guard. The main GUI, which runs elevated, only has DEP enabled, the helper binary not even. Because it is only a matter of using appropriate code generation and linker options I'd like to ask for them to be enabled, I feel uneasy running elevated processes like this in this day and age.
DEP: This one should be on by default, had to be switched off manually, makes use of the NX bit.
Configuration Properties → Linker → Advanced → Randomized Base Address.
Or adding the linker argument /DYNAMICBASE.
There is an extra linker argument for 64-bit (high entropy) ASLR that doesn't have equivalent Visual Studio GUI toggle and must be added at Configuration Properties → Linker → Command Line: /HIGHENTROPYVA. It seems that option was set for the GUI binary, but because ASLR itself wasn't turned on, it makes no difference.
Or adding the compiler argument /guard:cf, the compiler also passes that option to the linker, but if you are building manually and linking at a different stage, add it to the linker argument list as well.
There are a couple of extras for this, EH continuation metadata (also in the Code Generation section, /guard:ehcont) and CET Shadow Stack (at Linker → Advanced, /CETCOMPAT is the linker argument). The latter just marks the image as supporting CET for processors that can do it, doesn't add anything else and because it is just a flag in the header makes no difference on processors that can't.
Please consider enabling those options, they don't require code changes and makes the binaries more resilient.
The program is composed of several binaries as of 3.7.4 build 5725:
Only the filter driver is built with permanent DEP, high entropy ASLR and Control Flow Guard. The main GUI, which runs elevated, only has DEP enabled, the helper binary not even. Because it is only a matter of using appropriate code generation and linker options I'd like to ask for them to be enabled, I feel uneasy running elevated processes like this in this day and age.
DEP: This one should be on by default, had to be switched off manually, makes use of the NX bit.
/NXCOMPAT
ASLR:
/DYNAMICBASE
.There is an extra linker argument for 64-bit (high entropy) ASLR that doesn't have equivalent Visual Studio GUI toggle and must be added at Configuration Properties → Linker → Command Line:
/HIGHENTROPYVA
. It seems that option was set for the GUI binary, but because ASLR itself wasn't turned on, it makes no difference.Control Flow Guard:
/guard:cf
, the compiler also passes that option to the linker, but if you are building manually and linking at a different stage, add it to the linker argument list as well.There are a couple of extras for this, EH continuation metadata (also in the Code Generation section,
/guard:ehcont
) and CET Shadow Stack (at Linker → Advanced,/CETCOMPAT
is the linker argument). The latter just marks the image as supporting CET for processors that can do it, doesn't add anything else and because it is just a flag in the header makes no difference on processors that can't.Please consider enabling those options, they don't require code changes and makes the binaries more resilient.
More details on each of them:
PS. Older than CFG, but should also be present is what's named "Security Check" at Code Generation (
/GS
), uses canaries.The text was updated successfully, but these errors were encountered: