lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <3FA06FF2.1030201@gce.com>
From: Everhart at gce.com (Glenn and Mary Everhart)
Subject: Re: System monitor scheme

Folks -
Hate to reply to my own post, but a clarification seems needed. My notion here
is not to monitor EVERY single process in a machine, just one or a very few
such processes, which would be offering network services and thus are at the
"front line" and directly subject to attacks. The checksumming would moreover
be rarely needed if the OS sets code to be write protected from user mode. A
check every hour (or less often) would show up rare skulduggery there. The PC
check on the other hand could be made fast and cheap from kernel mode, and
could be done more often, possibly several times/second. Even with code memory
writeable, I would do checksums infrequently owing to their cpu cost.

A search in Freshmeat turned up one system that looked at the location of
the PC and stack at every system call, but nothing quite as suggested here.
The memory peeking is doable much as I did in DDT22 (c. 1980) but details
need to be different.

So, anyone heard of anything closer?

Thanks much

Glenn Everhart



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@....com  home)



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ