1

If I have an app that's frequently and randomly crashing, will it impose a bigger security threat (e.g: possible attack vector) than apps that are stable? Or are both apps equally protected from such attacks by the kernel and firmware?

Of course by "crashing" I mean memory-related crashing e.g: segmentation fault, etc.

Example: Zathura crashes randomly while viewing PDFs. Should I switch to more stable PDF reader apps like Okular?

2
  • 1
    Crashing points to the existence of severe bugs, and some such bugs (especially memory-related ones like segfaults) may be exploitable. However, observing a segfault implies that this last memory access was not part of a successful exploit. Seeing no segfaults could mean that the app is safer, or that the exploits succeed silently. Commented Jun 18, 2023 at 6:42
  • 1
    Not at all, letting the program segfault after running the payload is common. Process continuation can be tricky, especially if you have limited space for your payload Commented Jun 20, 2023 at 23:47

1 Answer 1

1

The quality of an app in terms of "frequently crashing" is not a reliable indicator of its security. Either state could have false positives or false negatives.

For instance (as pointed out in comments), an app with insecure memory use patterns could be exploited silently without a crash. Alternately, apps could contain memory access faults and crashes that that are not exploitable, or even intentional.

For instance, a common programming pattern is to initialize pointers to 0 at creation so that accidentally uninitialized pointers cause a null pointer dereference (segfault) rather than accessing some random memory which is less likely to crash (and less predictable and harder to debug). Zeroing the pointers at creation could make a program segfault frequently, where if those pointers were left with old values from a previous stack frame, it might be exploitable rather than crashy.

So if a program crashes frequently, I would be wary it may contain exploitable bugs, but this is not a reliable judgement on its own. In general, I don't think it is safe to say that a non-crashing program is safer either. This metric alone is not enough in either direction... Other metrics of code quality and corporate attitude towards clean code, code audits, and bug fixes are also important.

1
  • For example, in Swift arithmetic overflow, invalid array indexes, accessing a nil optional value m, woo crash your app deliberately in a safe way. Commented Jun 27, 2023 at 15:58

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.