[j-nsp] CVE-2023-4481

[Jeff Haas]

On 8/31/23, 4:28 AM, "juniper-nsp on behalf of Tobias Heister via juniper-nsp" <juniper-nsp-bounces at puck.nether.net <mailto:juniper-nsp-bounces at puck.nether.net> on behalf of juniper-nsp at puck.nether.net <mailto:juniper-nsp at puck.nether.net>> wrote:
> Am 30.08.2023 um 18:09 schrieb heasley via juniper-nsp:
> > Tue, Aug 29, 2023 at 03:42:41PM -0700, David Sinn via juniper-nsp:
> >> A network I operate is going with:
> >>
> >> bgp-error-tolerance {
> >> malformed-route-limit 0;
> >> }
> >>
> >> The thoughts being that there is no real reason to retain the malformed route and the default of 1000 is arbitrary. We haven't really seen a rash of them, so adjusting the logging hasn't proven needed yet.
> >
> > It does seem arbitrary. retaining all seems like a better choice,
> > operationally. allowing the operator diagnose why a route is missing;
> > show route .... hidden.

That's the exact use case.  Otherwise it's yet another completely arbitrary
case of, "where did this route go and do we have zombies to worry about?"

> Which in theory opens a new attack vector for the future.
>
> As the update is malformed it could do $something to the handling in
> e.g. RPD or other daemons by processing them somehow wrong. By not
> holding or further process any of them that could (maybe, hopefully?) be
> minimized.

You're encouraged to engage in whatever level of paranoia here that makes you
happy operationally.  The internal behavior is we throw out the portion of the
path attribute that was decided to be bad.  We spent a fair amount of time
doing audit over various bits of code that interact with such stripped path
attribute sets, like logging and tracing.  That said, we've had bugs over the
years in logging, trace, etc. that may be fixed in current versions but perhaps
not past ones.  I can't identify any bug of concern in running releases from
memory.

Thus, if you're more comfortable with just throwing the things out and not
worrying about tracking down routes that are bad, go for it.  It's a supported
scenario.

> Of course proper code and handling of malformed things would be even
> better, but you know ...

For the moment, this depends on configuration of the error-tolerance "feature".
Making the behavior default is working its way through management for a
targeted release.

-- Jeff


Juniper Business Use Only