verify currently running software on ram
ag4ve.us at gmail.com
Mon Jan 13 12:32:47 UTC 2014
Doh, tired and not reading - the util should help after you get a dump
On Jan 13, 2014 7:29 AM, "shawn wilson" <ag4ve.us at gmail.com> wrote:
> 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
> On Jan 13, 2014 7:21 AM, "Tassos Chatzithomaoglou" <achatz at forthnet.gr>
>> Saku Ytti wrote on 13/1/2014 12:51:
>> > On (2014-01-13 12:46 +0200), Saku Ytti wrote:
>> >> On (2014-01-13 12:26 +0200), Tassos Chatzithomaoglou wrote:
>> >>> 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
>> >> 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
>> > reasonably map the *.tgz to RAM.
>> > I think vendors could take page from XBOX360 etc, and embed public keys
>> > their NPU in modern lithography then sign images, it would be
>> > 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
>> > easier to create infrastructure/HW where program memory cannot be
>> > runtime.
>> I agree, and we already do that, but a regulatory authority has brought
>> into surface something trickier.
More information about the NANOG