I'm looking for ways to verify that the currently running software on our Cisco/Juniper boxes is the one that is also in the flash/hd/storage/etc.
Something that will somehow compare the running software in ram with the software on flash/hd/storage/etc, so that i can verify that nobody has actually messed with the running software (by whatever means that's possible).
Besides the "install verify" command on IOS-XR (which i'm not 100% sure if it suits my needs), i haven't managed to find anything else. And the vendors say that indeed there is nothing more.
All other options are about verifying the software file integrity before it gets loaded into ram.
Have you ever done such an exercise? Are there maybe any external tools (or services) that offer this capability?
IOS: verify /md5 flash:file
JunOS: filechecksum md5|sha-256|sha1 file
But if your system is owned, maybe the verification reads filename and outputs
expected hash instead of correct hash.
mea culpa, you were looking to check running to image, I don't think this is
practical.
In IOS its compressed and decompressed upon boot, so no practical way to map
the two together.
Same is true in JunOS, even without compression it wouldn't be possible to
reasonably map the *.tgz to RAM.
I think vendors could take page from XBOX360 etc, and embed public keys inside
their NPU in modern lithography then sign images, it would be impractical
attack vector.
But changing memory runtime is probably going to very complicated to verify,
easier to create infrastructure/HW where program memory cannot be changed
runtime.
That verifies the software that is stored somewhere, not the currently running one.
Someone "insider" could load a "hacked" software into flash, boot the router with that file (supposing that he has found a way to do so) and then replace the file on the flash with the real one.
How can you verify that the running software is actually the original one?
I'm looking for ways to verify that the currently running software on our Cisco/Juniper boxes is the one that is also in the flash/hd/storage/etc.
IOS: verify /md5 flash:file
JunOS: filechecksum md5|sha-256|sha1 file
But if your system is owned, maybe the verification reads filename and outputs
expected hash instead of correct hash.
mea culpa, you were looking to check running to image, I don't think this is
practical.
In IOS its compressed and decompressed upon boot, so no practical way to map
the two together.
Same is true in JunOS, even without compression it wouldn't be possible to
reasonably map the *.tgz to RAM.
I think vendors could take page from XBOX360 etc, and embed public keys inside
their NPU in modern lithography then sign images, it would be impractical
attack vector.
I was assuming the vendors could take a snapshot of the memory and somehow "compare" it to a snapshot of the original software.
Or (i don't know how easy it is) do an auditing of the memory snapshot on specific pointers...well, i don't know...just thinking loudly...
But changing memory runtime is probably going to very complicated to verify,
easier to create infrastructure/HW where program memory cannot be changed
runtime.
I agree, and we already do that, but a regulatory authority has brought into surface something trickier.
dd kmem and see if it's what you'd expect (size of ram+swap). If so you
should be able to look at it
Also see Volatility
Doh, tired and not reading - the util should help after you get a dump
though.
In general, asking the operating system if it's pwned is an insoluble
problem, because the pwner will of course arrange that the answer to such
a query be "No, I'm not pwned".
You really need assistance from one layer further down - if you're in a
VM, you need to ask the hypervisor. If you're on bare metal, you need to
ask the SMM or equivalent. If you're in the SMM, you need to ask the
hardware. And of course, at each level, you have to ask yourself how you
know that *that* level isn't lying to you....
(Yes, this is the corner of system security where, if you're not already
a paranoid schizophrenic, you will be soon.. 
If you have not already read the Ken Thompson paper:
http://cm.bell-labs.com/who/ken/trust.html
And for a bit more on whether it was ever actually implemented, from Ken
himself:
https://groups.google.com/d/msg/comp.security.unix/ivjYjNSduFc/0Er2cynPKjsJ
Cheers,
-- jra