Re: [j-nsp] CVE-2023-4481

[Gert Doering via juniper-nsp]

Hi,

On Sun, Sep 17, 2023 at 03:07:26PM +0200, Tobias Heister via juniper-nsp wrote:
> So, like with all features and knobs, you might want to consider whether it
> brings you any benefit to keep the prefixes in hidden state or "minimize"
> processing of things you will maybe never look at.

From an operational perspective, knowing that a given prefix *did* arrive
at the local router, and was then dropped (= hidden) for a specific reason
is very valuable.  Without that information, you can only guess "did my
peer send it at all?" and troubleshooting *this* means "talk to people
outside your organization" which is way more time consuming than just
looking at hidden prefixes.

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] CVE-2023-4481

[Tobias Heister via juniper-nsp]

Hi,

On 11.09.2023 19:55, Tom Beecher wrote:

Which in theory opens a new attack vector for the future.


What is the attack vector you foresee for a route sitting as hidden with 
the potentially offending attributes stripped off?


It is theoretical, but if you do $something with a prefix and maybe even 
the "malformed" attribute and do not throw the prefix away completely 
$something in parsing and keeping the prefix further down the line could 
stumble over $whatever else makes the prefix special.


This implies "problems"/bugs in the code parsing the prefix and its 
attributes, which can be assumed to not exist, but doing $something is 
more likely to hit a problem than not doing $something.


By keeping the prefix and doing $something with it you do more than 
before and might hit a code path that was not hit before when the 
session was reseted or when the prefixes are just discarded.


In an ideal world where all code and parsing is perfect all is fine.
Do i think this is likely or a real world problem we will hit soon? 
Probably not. Do i think that it is a theoretic vector to hit problems 
not yet seen in the wild at some point? Yes I do.


So, like with all features and knobs, you might want to consider whether 
it brings you any benefit to keep the prefixes in hidden state or 
"minimize" processing of things you will maybe never look at.


regards
Tobias
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] CVE-2023-4481

[Tom Beecher via juniper-nsp]

>
> Which in theory opens a new attack vector for the future.
>

What is the attack vector you foresee for a route sitting as hidden with
the potentially offending attributes stripped off?

On Thu, Aug 31, 2023 at 4:27 AM Tobias Heister via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> Hi,
>
> 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.
>
> 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.
>
> Of course proper code and handling of malformed things would be even
> better, but you know ...
>
> regards
> Tobias
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] CVE-2023-4481

[Jeff Haas via juniper-nsp]

On 8/31/23, 4:28 AM, "juniper-nsp on behalf of Tobias Heister via juniper-nsp" 
mailto:juniper-nsp-boun...@puck.nether.net> on behalf of 
juniper-nsp@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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] CVE-2023-4481

[Tobias Heister via juniper-nsp]

Hi,

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.


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.


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


regards
Tobias
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] CVE-2023-4481

[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.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] CVE-2023-4481

[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.

I don't have anything running 14.x to test, but per the documentation the above 
should be supported from 13.2. 

David

> On Aug 29, 2023, at 2:06 PM, Randy Bush via juniper-nsp 
>  wrote:
> 
> do we have a recommended `bgp-error-tolerance {}` config to deal with
> CVE-2023-4481?
> 
> and what does one do on antique hardwhere with. e.g., junos 14?
> 
> randy
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] CVE-2023-4481

[Randy Bush via juniper-nsp]

do we have a recommended `bgp-error-tolerance {}` config to deal with
CVE-2023-4481?

and what does one do on antique hardwhere with. e.g., junos 14?

randy
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp