Practicality of memory-based intrusion prevention

A thought:
- A binary program's text segment generally should not change after it has been executed
- If it does change, you can be fairly certain that the program in question is misbehaving
- If it changes in memory for e.g. Firefox, that almost certainly indicates a compromise*

Would it be possible for a driver to maintain running checksums of text segments, and SIGKILL (or equivalent) anything that changed while it was watching?

Would it be practical? Could it be done effectively, without incurring an absurd number of context switches?

Would it be worthwhile, now that 64-bit operating systems with ASLR and hardened compilers are ubiquitous? Could it perhaps catch logic flaws that other exploit mitigation measures wouldn't?

Do I have any idea at all what I'm talking about?

* I believe the text segments for each library are combined with that of the executable, making one big text segment in memory for the application. But I am not sure how universally applicable that is.

 

It really depends on the program in question. Once the program reaches the original entry point, I'd say about 90% of them don't go through further changes. There are however exceptions such as compressed or encrypted code that is later expanded/decrypted. Sometimes just before it is used and only if certain conditions are met. Self-modifying code does exist and is widely used in many software protections these days both commercial and unique.

 

Most programs I have used on Windows do not have compressed or encrypted runtime images... That said, I haven't used Windows seriously in a long time, so I don't have a good picture of what the proprietary software situation is.

FOSS programs on Linux barely ever use runtime packing though, at least AFAIK. Maybe a strategy like this would be more applicable to servers?

 

Based on what I've heard from you in the past, my personal opinion on that is a resounding YES.

 

This time around the answer is "no"

- Text segments do not have to be modified for an attack to work if you can execute stuff from elsewhere. (Thus NX and and mprotect() restrictions on modern OSes.)

- This would kill anything with a JIT compiler in it. (Firefox, Chrome, etc.)

So, not a useful idea. The reason nobody uses it is that it doesn't work.