From: Everhart, Glenn (Card Services) Sent: Wednesday, October 29, 2003 11:31 AM To: full-disclosure@lists.netsys.com Subject: System monitor scheme - anyone know anything like this? Categories: NoHTML All - In working up a scheme to authenticate one program to another, it occurred to me that it might be useful to be able to be assured a piece of code has not been altered during its running, on the basis of occasional probes. If something bashed a program in memory only (as with a buffer overflow) this might stand a chance of noticing that this had been done. To do such a check, one would have to have some piece of code that lives in a system and is able to peek at the memory used as code storage by some process, checking that this memory has not been altered since program load (which can't in general be done till load occurs since addressing fixups at least are likely to have taken place). I suppose that instead some code that checked the program counter of a target program and made sure that if it were not in a shareable library or the kernel, that it was executing out of the range of addresses that had been set up as in bounds for code segments of the program, could provide a similar service. It would be most convenient if it were not necessary to have the link maps and thus not necessary to feed address bounds in by hand, by figuring out where the code ought to be loaded based on the executable. Clearly it makes no sense to try to checksum (by whatever decent algorithm) data areas. If however I had a daemon that could checksum code areas when it noticed a new program was running (running some file I was interested in) and that checksummed the code areas now and then later, it might notice memory attacks of some types. If it checked the PC also, it could notice that execution might be going on off the stack, heap, etc. This probably will not cover all possible bases of attack, but could cover enough to be worth using. Has anyone seen such programs in their travels, or is this another build-it-myself project? Thanks in advance for any who have suggestions. Glenn C. Everhart (everhart@gce.com home)