[nsp-sec] FYI - Cisco IOS XR Software DVMRP Memory Exhaustion Vulnerability

[Dario Ciccarone (dciccaro)]

Thanks for the feedback, RuthAnne !

And folks - you know where to find me. If you ever have any feedback on any of our advisories . . . don't be shy to share :^)

On 8/31/20, 1:25 AM, "RuthAnne Bevier" <ruthanne at caltech.edu> wrote:

    For what it's worth, for situations where you can't cram all of the salient info into the subject line, I'd personally prefer the more alarming subject line, and then get the additional information ("when multicast routing is enabled") as close to the top of the message as possible.  I'd rather read it and learn (quickly) that my environment isn't affected than wrongly think it's a low priority and look at it later when I really should be looking at it now.

         --RuthAnne

    On Sun, Aug 30, 2020 at 04:33:12AM +0000, Dario Ciccarone (dciccaro) wrote:
    > ----------- nsp-security Confidential --------
    > 
    > John, yes, correct - the issue is on the processing of DVMRP traffic over IGMP - even if DVMRP is not in used, if IGMP us being processed, then you'll run into this issue.
    > 
    > You have also raised a good point on the title - while the root cause is on the code processing DVMRP, I wonder now if we shouldn't have called it "Cisco IOS XR Software IGMP Memory Exhaustion Vulnerability". We always struggle on this area - because if we say "IGMP memory exhaustion" or even more generically, "packet processing exhaustion", then A LOT more people will have a bit of a heart attack - until they read the whole advisory, and then they'll go "Geez, Cisco, you almost killed me - it is only for those w/ multicast routing enabled !"
    > 
    > Always a fine line. Do you have any ideas you would like to share on the above ? What would you prefer - (a) a "more generic title which makes me read the SA, but may also worry me needlessly" or (b) a "more specific title, but which may make me skip reading the SA - and I might be affected" ?
    > 
    > As said, we struggle - and we can't write the whole SA on the title, so some balance is neeed.
    > 
    > 
    > On 8/29/20, 3:32 PM, "nsp-security on behalf of John Kristoff" <nsp-security-bounces at puck.nether.net on behalf of jtk at depaul.edu> wrote:
    > 
    >     ----------- nsp-security Confidential --------
    > 
    >     On Sat, 29 Aug 2020 03:36:32 +0000
    >     "Dario Ciccarone (dciccaro)" <dciccaro at cisco.com> wrote:
    > 
    >     > New advisory just published minutes ago -
    >     > https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxr-dvmrp-memexh-dSmpdvfz
    > 
    >     Hi Dario,
    > 
    >     I think some people will see DVMRP and skim past this.  To clarify,
    >     this problem does not require one run DVMRP per se, this is really an
    >     issuing stemming from the underlying IGMP protocol within which DVMRP
    >     is encapsulated.  Probably most routers will support some level of IGMP
    >     functionality, so nets with vulnerable gear shouldn't skim past this so
    >     quickly.  Fair assessment?
    > 
    >     John
    > 
    > 
    >     _______________________________________________
    >     nsp-security mailing list
    >     nsp-security at puck.nether.net
    >     https://puck.nether.net/mailman/listinfo/nsp-security
    > 
    >     Please do not Forward, CC, or BCC this E-mail outside of the nsp-security
    >     community. Confidentiality is essential for effective Internet security counter-measures.
    >     _______________________________________________
    > 
    > 
    > 
    > _______________________________________________
    > nsp-security mailing list
    > nsp-security at puck.nether.net
    > https://puck.nether.net/mailman/listinfo/nsp-security
    > 
    > Please do not Forward, CC, or BCC this E-mail outside of the nsp-security
    > community. Confidentiality is essential for effective Internet security counter-measures.
    > _______________________________________________

    -- 
    RuthAnne Bevier
    Chief Information Security Officer
    California Institute of Technology
    626 395 2671