[81691] in North American Network Operators' Group
Re: md5 for bgp tcp sessions
daemon@ATHENA.MIT.EDU (Jared Mauch)
Thu Jun 23 11:28:08 2005
Date: Thu, 23 Jun 2005 11:27:38 -0400
From: Jared Mauch <jared@puck.nether.net>
To: Todd Underwood <todd@renesys.com>
Cc: Richard A Steenbergen <ras@e-gerbil.net>, nanog@merit.edu
In-Reply-To: <20050623095705.GP24076@renesys.com>
Errors-To: owner-nanog@merit.edu
On Thu, Jun 23, 2005 at 05:57:05AM -0400, Todd Underwood wrote:
>
> ras, all,
>
> On Thu, Jun 23, 2005 at 12:14:12AM -0400, Richard A Steenbergen wrote:
> > On Wed, Jun 22, 2005 at 10:04:09PM -0400, Todd Underwood wrote:
>
> > > a) many (all?) implementations of md5 protection of tcp expose
> > > new, easy-to-exploit vulnerabilities in host OSes. md5 verification
> > > is slow and done on a main processor of most routers. md5
> > > verification typically takes places *before* the sequence number,
> > > ports, and ip are checked to see whether they apply to a valid
> > > session. as a result, you've exposed a trivial processor DOS to your
> > > box.
> >
> > Well, I think they've finally fixed this one by now, at least everyone
> > that I'm aware of has done so. Immediately following the whining to start
> > deploying MD5 is was certainly the case that many implementations did
> > stupid stuff like process MD5 before running other validity checks like
> > sequence numbers which are far less computationally intensive, and there
> > were a few MSS bugs that popped up, but they should have all been worked
> > out by now. I don't think that anyone running modern code is suffering any
> > more attack potential because of this.
>
> my understanding is that md5 is still checked before the ttl-hack
> check takes place on cisco (and perhaps most router platforms). new
> attack vector for less security than you had before. oh well. ras:
> can you confirm that it is possible to implement ttl-hack and have it
> check *before* md5 signature checks?
Last I knew there was still a bug open on this that has gotten
little/no action for at least half a year on this issue, I would
think that in 6mos someone at Cisco could take the time to research
the bug and fix it. (I'll leave out the part about releasing TAC supported
code with a fix).
I believe the bugid is CSCee73956
- Jared
--
Jared Mauch | pgp key available via finger from jared@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.
