When an NTP client or server is enabled within the [edit system ntp] hierarchy level of the Junos configuration, REQ_MON_GETLIST and REQ_MON_GETLIST_1 control messages supported by the monlist feature within NTP may allow remote attackers to cause a denial of service. NTP is not enabled in Junos by default. Once NTP is enabled, an attacker can exploit these control messages in two different ways:

• as part of a denial of service attack against a remote victim
• as the target of an attack against the device itself

Response to monlist control messages has been disabled by default.

The following software releases have been updated to resolve this specific issue: Junos OS 11.4R12, 12.1R10, 12.1X44-D35, 12.1X45-D25, 12.1X46-D15, 12.1X47-D10, 12.2R8, 12.3R7, 13.1R4-S2, 13.2R4, 13.3R2, 14.1R1, and all subsequent releases (i.e. all releases built after 14.1R1).

This issue is being tracked as PR 931184 and is visible on the Customer Support website.

KB16765 [juniper.net] - "In which releases are vulnerabilities fixed?" describes which release vulnerabilities are fixed as per our End of Engineering and End of Life support policies.

If a possible attack has been identified, or if the NTP process is occupying a large amount of CPU or memory resources, the most effective mitigation is to apply a firewall filter to allow only trusted addresses and networks, plus the router's loopback address, access to the NTP service on the device, rejecting all other requests.  For example:
 

term allow-ntp {
    from {
        source-address {
            <trusted-addresses>;
            <router-loopback-address>;
        }
        protocol udp;
        port ntp;
    }
    then accept;
}

term block-ntp {
    from {
        protocol udp;
        port ntp;
    }
    then {
        discard;
    }
}

User@Router> show ntp status
localhost: timed out, nothing received
***Request timed out

term block-ntp {
    from {
        protocol udp;
        port ntp;
    }
    then {
        log;
        discard;
    }
}

term allow-ntp {
    from {
        source-address {
            <trusted-addresses>;
            <router-loopback-address>;
        }
        protocol udp;
        port ntp;
    }
    then {
        log;
        accept;
    }
}

term allow_ntp_1 {
    from {
        source-address {
            <trusted-addresses>;
            <router-loopback-address>;
        }
        protocol udp;
        source-port ntp;
    }
    then accept;
}
term allow_ntp_2 {
    from {
        source-address {
            <trusted-addresses>;
            <router-loopback-address>;
        }
        protocol udp;
        destination-port ntp;
    }
    then accept;
}
term block_ntp_1 {
    from {
        protocol udp;
        destination-port ntp;
    }
    then {
        discard;
    }
}
term block_ntp_2 {
    from {
        protocol udp;
        source-port ntp;
    }
    then {
        discard;
    }
}
term default {
    then accept;
}

• If me0/vme is configured for the system, apply the filter to both lo0 and me0/vme.
• If me0/vme is not configured in the system, apply the filter only to lo0.

2014-07-09: Initial publication
2021-04-09: Corrected EX Series example

• KB16613: Overview of the Juniper Networks SIRT Monthly Security Bulletin Publication Process [juniper.net]
• KB16765: In which releases are vulnerabilities fixed? [juniper.net]
• KB16446: Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories [juniper.net]
• Report a Vulnerability - How to Contact the Juniper Networks Security Incident Response Team
• CVE-2013-5211: monlist feature in ntpd allows remote attackers to cause a denial of service (traffic amplification)
• RFC 6192: Protecting the Router Control Plane