North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Fred Reimer
  • Date: Thu May 29 10:21:15 2008

This is not a crypto form, so we shouldn't get deep into the MD5 collision
debate, but I didn't say HOW there has been limited success.  Sorry if the
wording of my message was not clear and implied that all you would need were
the plaintext and the hash.

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


> -----Original Message-----
> From: Steven M. Bellovin [mailto:[email protected]]
> Sent: Thursday, May 29, 2008 9:43 AM
> To: Fred Reimer
> Cc: Gadi Evron; [email protected]
> Subject: Re: IOS Rookit: the sky isn't falling (yet)
> 
> On Thu, 29 May 2008 09:18:07 -0400
> "Fred Reimer" <[email protected]> wrote:
> 
> > So the only easy way to attack this is the MD5 hash.  We have a know
> > 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.
> 
> No there has not.  There has been considerable success at creating
> *collisions*; if you don't have a collaborator inside Cisco's build
> team, that does you no good in this case.  There has been *no* success
> at preimage attacks, which is what we're talking about here.  (Aside:
> I'm on record as saying I wouldn't be surprised if preimage attacks
> were developed soon by the cryptanalytic community, since people are
> paying so much more attention to hash functions now, but that hasn't
> happened yet.)
> 
> If you do have a collaborator, there is a conceivable attack.  Use the
> collision attack -- that is, the ability to simultaneously produce two
> files with the same hash -- to generate a genuine IOS image that is
> nevertheless susceptible to being replaced by a corrupted one.  It's a
> delicate process, though, since even a 1-bit change will completely
> change the hash output and ruin the collision.  You're much better off
> having your collaborator simply install a back door for you -- and it
> almost certainly won't be found.  See
> http://www.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-136.html or
> Chapter 8 of http://zesty.ca/pubs/yee-phd.pdf
> 
> 
> 		--Steve Bellovin, http://www.cs.columbia.edu/~smb

Attachment: smime.p7s
Description: S/MIME cryptographic signature