RE: IOS Rookit: the sky isn't falling (yet)

["Fred Reimer" <freimer () ctiusa com>]

The code would presumably be run upon boot from a non-flashable source,
which would run the boot ROM code through a check on the crypto chip and
only execute it if it passed.  You would not put the code that checks the
boot ROM on the boot ROM.  The new crypto chip would presumably have the
initial boot code, which would only be designed to check the boot ROM
signature and nothing else so presumably would never need to be replaced and
hence would be designed to be non-flashable.

Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS
Senior Network Engineer
Coleman Technologies, Inc.
954-298-1697


> -----Original Message-----
> From: Jared Mauch [mailto:jared () puck nether net]
> Sent: Thursday, May 29, 2008 9:48 AM
> To: Jim Wise
> Cc: Fred Reimer; nanog () nanog org
> Subject: Re: IOS Rookit: the sky isn't falling (yet)
>
>
> On May 29, 2008, at 9:37 AM, Jim Wise wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Thu, 29 May 2008, Fred Reimer wrote:
> >
> > > plaintext (the IOS code) and the hash.  It is not trivial to be
> > > able to
> > > make changes in the code and maintain the same hash value, but
> > > there has
> > > been at least limited success in doing so.
> >
> > Has there?  My understanding is that constructing a new image to
> match
> > an existing MD5 checksum (vs. constructing two new images with
> > matching
> > MD5 checksums) was still not feasible.  Did I miss something?
>
>       I think the point here is that most (read: average) consumers
> don't
> verify the md5/sha1/gpg/pgp signatures of the binaries they run.  If
> that was the case, we wouldn't have problems quite as bad as we do
> today.
>
> > > It may not be possible to replace the boot ROM, because presumably
> > > the new
> > > hardware would check the ROM code hash before loading it and also
> > > presumably the ROM code does not have quite as much text messages
> > > that can
> > > be changed to generate the same hash value, thereby bypassing the
> > > security
> > > checks.
> >
> > This may be an obvious question, but given that the code which
> > verifies an
> > IOS image would (presumably) be part of the boot ROM, where would
> > you put
> > the code which verifies the boot ROM?  What does it mean to say `the
> > hardware' should check the boot ROM?
>
> I agree with you here.  Cisco even ships methods to do a field-upgrade
> of the rommon on a variety of platforms and linecards.  There are
> numerous challenges when talking about how to prevent these types of
> updates.  I could imagine a case where you leverage the current
> 'phlashing' stuff to "brick" your router rommon so it won't boot.
> Once again it gets to the how do you obtain an exploit path to perform
> these actions on the device?  I always have said physical access =
> "root".  Perhaps the path is that oob modem?  You need to think about
> these things, but unless you have a mission dealing with state secrets
> or your corporate IP (not the protocol) guys treat everything like it
> is (eg: pharmaceutical companies), you're likely to not notice the
> router in the closet has a 2 year old bogon filter list installed.
>
>       - Jared

Attachment: smime.p7s
Description: