Az.ApplicationMonitor

Problem

Security Development Lifecycle (SDL) is a group of enhanced compile-time checks that report common coding mistakes as errors, preventing them from reaching production. These checks minimize the number of security issues by enforcing strict memory access checks. They also prevent the use of hard-to-secure string and memory manipulation functions. To prove the binary has been compiled with these checks enabled, the compiler emits a special debug object. Removing the debug table eliminates this proof. Therefore, this check only applies to binaries that still have their debug tables.

Problem

Software components contain executable code that performs actions implemented during its development. These actions are called behaviors. In the analysis report, behaviors are presented as human-readable descriptions that best match the underlying code intent. While most behaviors are benign, some are commonly abused by malicious software with the intent to cause harm. When a software package shares behavior traits with malicious software, it may become flagged by security solutions. Any detection from security solutions can cause friction for the end-users during software deployment. While the behavior is likely intended by the developer, there is a small chance this detection is true positive, and an early indication of a software supply chain attack.

Problem

Control Flow Guard (CFG/CFI) protects the code flow integrity by ensuring that indirect calls are made only to vetted functions. This mitigation is detected as enabled, but its effectiveness is impacted by the use of outdated precompiled code. It was determined that the application had been linked against static libraries produced by multiple toolchain versions. Because some of them predate the general availability of the control flow guard vulnerability mitigation, it is likely that protection coverage gaps exist.

Problem

Control Flow Guard (CFG/CFI) protects the code flow integrity by ensuring that dynamic calls are made only to vetted functions. Trusted execution paths rely on the ability of the operating system to build a list of valid function targets. Certain functions can intentionally be disallowed to prevent malicious code from deactivating vulnerability mitigation features. A list of such invalid function targets can include publicly exported symbols. Applications that enhance control flow integrity through export suppression rely on libraries to mark their publicly visible symbols as suppressed. This is done for all symbols that are considered to be sensitive functions, and to which access should be restricted. It is considered dangerous to mix applications that perform export suppression with libraries that do not.

Problem

Control Flow Guard (CFG/CFI) protects the code flow integrity by ensuring that indirect calls are made only to vetted functions. This mitigation protects dynamically resolved function targets by instrumenting the code responsible for transferring execution control. Higher-level programming languages implement structured exception handling by managing their own code flow execution paths. As such, they are subject to code flow hijacking during runtime. Language-specific exception handling mitigation enforces execution integrity by instrumenting calls to manage execution context switching. Any deviation from the known and trusted code flow paths will cause the application to terminate. This makes malicious code less likely to execute.