[casr-san][casr-gdb] Ambiguous severity estimation

[hkctkuy]

In casr-san in signal case we call GdbCommand, but do not look on its result and estimate execution_class regardless of this.

Thus, we can get a situation with an unjustified decrease in severity. For example:

We can run casr-csharp, which calls casr-san with GdbCommand like this:

LD_LIBRARY_PATH="casr/tests/tmp_tests_casr/test_casr_csharp_native" casr-csharp --stdout -- $(which dotnet) casr/tests/tmp_tests_casr/test_casr_csharp_native/bin/Debug/net8.0/test_casr_csharp_native.dll

And get NOT_EXPLOITABLE severity:

"CrashSeverity": {
    "Type": "NOT_EXPLOITABLE",
    "ShortDescription": "AccessViolation",
    "Description": "Access violation",
    "Explanation": "The target crashed due to an access violation but there is not enough additional information available to determine exploitability. Manual analysis is needed."
  }

But also we can run casr-gdb directly with the same options:

LD_LIBRARY_PATH="casr/tests/tmp_tests_casr/test_casr_csharp_native" casr-gdb --stdout -- $(which dotnet) casr/tests/tmp_tests_casr/test_casr_csharp_native/bin/Debug/net8.0/test_casr_csharp_native.dll

And now we have EXPLOITABLE severity:

"CrashSeverity": {
    "Type": "EXPLOITABLE",
    "ShortDescription": "DestAv",
    "Description": "Access violation on destination operand",
    "Explanation": "The target crashed on an access violation at an address matching the destination operand of the instruction. This likely indicates a write access violation, which means the attacker may control the write address and/or value."
  },

The full casreps:
csharp.txt
gdb.txt