15.6 C
London
Thursday, August 17, 2017

JSA10749 – IPv6 Neighbor Discovery Crafted Packet Denial of Service Vulnerability...

This issue may affect any product or platform running Junos OS.A vulnerability in IPv6 processing has been discovered that may allow a specially crafted IPv6 Neighbor Discovery (ND) packet to be accepted by the router rather than discarded.  The crafted packet, destined to the router, will then be processed by the routing engine (RE).  A malicious network-based packet flood, sourced from beyond the local broadcast domain, can cause the RE CPU to spike, or cause the DDoS protection ARP protocol group policer to engage. When this happens, the DDoS policer may start dropping legitimate IPv6 neighbors as legitimate ND times out.Note that this is similar to the router's response to any purposeful malicious IPv6 ND flood destined to the router.

The difference is that the crafted packet identified in the vulnerability is such that the forwarding controllers/ASICs should disallow this traffic from reaching the RE for further processing.

Additionally, due to the routable nature of the crafted IPv6 ND packet, the attack may be launched from beyond the local broadcast domain.This issue has been assigned CVE-2016-1409.Internal investigation has uncovered three separate issues with IPv6 Neighbor Discovery processing in Junos:  QFX5100 exceptions transit IPv6 ND traffic to RE ​PR 1183115 logged to resolve this issue in a future release. Junos routers forward IPv6 ND traffic in violation of RFC4861 PRs 1183124 (QFX), 1188939 (MX), 1188949 (PTX) logged to investigate this issue. Junos routers fail to discard non-RFC4861-compliant IPv6 ND traffic destined to the router (CVE-2016-1409) PRs 1183124 (QFX), 1188939 (MX), 1188949 (PTX) Note that only MX, PTX, and QFX have been confirmed to experience this behavior.  Other platforms are still under investigation.Juniper Networks will update this advisory once fixes are available.Refer to KB16613 for additional information about the Juniper Networks SIRT Quarterly Security Bulletin Publication Process."While no complete workaround currently exists for this issue, especially for adjacent network attacks from the local broadcast domain, security best current practices (BCPs) of filtering all ND traffic at the edge, destined to network infrastructure equipment, should be employed to limit the malicious attack surface of the vulnerability.  Examples include:Interface and/or control plane firewall filters may be used to stop propagation of NDP traffic beyond connected devices.

Devices that support the hop-limit option can utilize the following interface filter design: user@junos# show firewall family inet6 NDP filter NDP { term PERMIT_LOCAL_ICMP { from { next-header icmp6; hop-limit 255; } then { count PERMIT_LOCAL_ICMP; accept; } } term REJECT_NETWORK_ICMP { from { next-header icmpv6; icmp-type [ neighbor-advertisement neighbor-solicit router-solicit router-advertisement redirect ]; } then { count REJECT_NETWORK_ICMP; discard; } } term PERMIT_ALL { then accept; } } Sample Protect_RE filter: user@junos# show firewall family inet6 IPV6_PROTECT_RE filter IPV6_PROTECT_RE { term ICMPV6_TRUSTED { from { source-prefix-list { IPV6_REMOTE_ACCESS; } next-header icmpv6; } then accept; } term IPV6_ND_LOCAL { from { next-header icmpv6; hop-limit 255; } then accept; } term ICMPV6 { from { next-header icmpv6; icmp-type [ echo-request echo-reply time-exceeded destination-unreachable packet-too-big parameter-problem ]; } then accept; } }​ Devices that do not support the 'hop-limit' option will require a slightly more complicated interface filter design: user@junos# show firewall family inet6 NDP filter NDP { term PERMIT_VALID_ICMP { from { destination-address { fe80::/10; ff02::/123; ff02:0:0:0:0:1:ff00::/104; } } then { count PERMIT_VALID_ICMP; accept; } } term PERMIT_VALID_ICMP_LOCAL { from { source-address { x:x:x:x::/64; } destination-address { x:x:x:x::/64; } next-header icmp6; } then { count PERMIT_VALID_ICMP_LOCAL; accept; } } term REJECT_INVALID_ICMP { from { next-header icmpv6; icmp-type [ neighbor-advertisement neighbor-solicit router-solicit router-advertisement redirect ]; } then { count REJECT_INVALID_ICMP; discard; } } } and Protect_RE filter design:​ user@junos# show firewall family inet6 IPV6_PROTECT_RE filter IPV6_PROTECT_RE { term ICMPV6_TRUSTED { from { source-prefix-list { IPV6_REMOTE_ACCESS; } next-header icmpv6; } then accept; } term IPV6_ND { from { destination-address { fe80::/10; ff02::/123; ff02:0:0:0:0:1:ff00::/104; } } then accept; } term IPV6_ND_LOCAL { from { source-address { x:x:x:x::/64; } destination-address { x:x:x:x::/64; } next-header icmp6; } then accept; } term ICMPV6 { from { next-header icmpv6; icmp-type [ echo-request echo-reply time-exceeded destination-unreachable packet-too-big parameter-problem ]; } then accept; } term OTHER { then { count DROP; discard; } } } Information for how Juniper Networks uses CVSS can be found at KB 16446 "Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories."

JSA10621 – 2014-04 Security Bulletin: Junos: Crafted IP packet can trigger...

This issue can affect all MX Series and T4000 routers using either Trio or Cassis-based PFEs. 2014-04-10 Update: Added T4000 and Type 5 FPCs (T4000-FPC5-3D) to advisory.A crafted IP packet destined to an MX Series or T4000 router utilizing Trio or Cassis-based PFE (Packet Forwarding Engine) modules can cause the PFE to reboot. Affected modules include MPC1, MPC2, MPC3, and MPC4, integrated MPCs (CHAS-MX*), as well as Type 5 FPCs on the T4000. For a complete list of Trio and Cassis-based PFE modules, refer to KB25385.Customers can display the various components in use via the 'show chassis hardware' command.Juniper SIRT is not aware of any malicious exploitation of this vulnerability.No other Juniper Networks products or platforms are affected by this issue.This issue has been assigned CVE-2014-2713. The following software releases have been updated to resolve this specific issue:All Junos OS software releases built on or after 2014-03-20, orJunos OS 11.4R11, 12.1R9, 12.2R7, 12.3R4-S3, 12.3R5, 13.1R4, 13.2R2, and 13.3R1, and all subsequent releases (i.e. all releases built after 13.3R1).Customers can confirm the build date of any Junos OS release by issuing the command 'show version detail'.This issue is being tracked as PR 904887 and is visible on the Customer Support website.KB16765 - "In which releases are vulnerabilities fixed?" describes which release vulnerabilities are fixed as per our End of Engineering and End of Life support policies. No known workaround exists for this issue. How to obtain fixed software:Security vulnerabilities in Junos are fixed in the next available Maintenance Release of each supported Junos version. In some cases, a Maintenance Release is not planned to be available in an appropriate time-frame. For these cases, Service Releases are made available in order to be more timely. Security Advisory and Security Notices will indicate which Maintenance and Service Releases contain fixes for the issues described. Upon request to JTAC, customers will be provided download instructions for a Service Release. Although Juniper does not provide formal Release Note documentation for a Service Release, a list of "PRs fixed" can be provided on request. Information for how Juniper Networks uses CVSS can be found at KB 16446 "Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories."

JSA10764 – 2016-10 Security Bulletin: Junos J-Web: Cross Site Scripting Vulnerability...

2016-10 Security Bulletin: Junos J-Web: Cross Site Scripting Vulnerability (CVE-2016-4923)Product Affected:This issue can affect any product or platform running Junos OS with J-Web enabled. Problem:Insufficient cross site scripting protection in J-Web ...

JSA10615 – 2014-03 Security Bulletin: IDP (Stand-Alone) Series: Username enumeration issue...

This issue can affect all NetScreen IDP stand-alone platforms running IDP OS 5.1. A username enumeration issue has been found in the Juniper Networks IDP stand alone product. The problem is a result of incorrect configuration of the Apache webserver daemon. This misconfiguration allows the Apache web server to confirm if a given username is valid on the system. Juniper SIRT is not aware of any malicious exploitation of this vulnerability.No other Juniper Networks products or platforms are affected by this issue.This issue has been assigned CVE-2001-1013.The fix for this issue requires a configuration change. The following steps must be followed in order to fix the issue:1) Log on as root (if via ssh, use admin, and then su - to root)2) Use a text editor to edit /etc/httpd/conf/httpd.conf3) Locate the following lines:SuexecUserGroup root root    UserDir public_html</IfModule>4) Change the config to reflect the following:SuexecUserGroup root root   UserDir Disabled</IfModule>5) Finally, you need to restart the services on the device:[root@defaulthost ~]# sh /etc/rc.d/init.d/httpd restartStopping httpd:[OK]Starting httpd:[OK][root@defaulthost ~]#KB16765 - "In which releases are vulnerabilities fixed?" describes which release vulnerabilities are fixed as per our End of Engineering and End of Life support policies.The steps outlined in the solution are the only fix for this issue. There are no other workarounds.

JSA10763 – 2016-10 Security Bulletin: Junos: Multiple privilege escalation vulnerabilities in...

2016-10 Security Bulletin: Junos: Multiple privilege escalation vulnerabilities in Junos CLI (CVE-2016-4922)Product Affected:These issues can affect any product or platform running Junos OS. Problem:Certain combinations of Junos OS CLI commands and arg...

JSA10766 – 2016-10 Security Bulletin: vMX: Information leak vulnerability (CVE-2016-4924)

Product Affected:vMX (Virtual MX Series router)Problem: An incorrect permissions vulnerability in vMX may allow local unprivileged users on a host system read access to vMX or vPFE images and obtain sensitive information contained in them such as private cryptographic keys. This issue was found during internal product security testing. Juniper SIRT is not aware of any malicious exploitation of this vulnerability. No other Juniper Networks products or platforms are affected by this issue. This issue has been assigned CVE-2016-4924. Solution:This issue has been resolved in vMX 14.1R8, 15.1F6, 16.1 and all subsequent releases.This issue is being tracked as PR 1129051 and is visible on the Customer Support website. Workaround:Limit access to only trusted users on the host machine where vMX is deployed. Implementation:How to obtain fixed software:Security vulnerabilities in Junos are fixed in the next available Maintenance Release of each supported Junos version.
In some cases, a Maintenance Release is not planned to be available in an appropriate time-frame.

For these cases, Service Releases are made available in order to be more timely.
Security Advisory and Security Notices will indicate which Maintenance and Service Releases contain fixes for the issues described. Upon request to JTAC, customers will be provided download instructions for a Service Release.

Although Juniper does not provide formal Release Note documentation for a Service Release, a list of "PRs fixed" can be provided on request.Modification History: 2016-10-12: Initial publication Related Links:CVSS Score:8.4 (CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N) Risk Level:High Acknowledgements:

JSA10762 – 2016-10 Security Bulletin: Junos: IPv6 denial of service vulnerability...

2016-10 Security Bulletin: Junos: IPv6 denial of service vulnerability due to resource exhaustion (CVE-2016-4921)Product Affected:This issue can affect any product or platform running Junos OS with IPv6 enabled. Problem:By flooding a router with specially crafted IPv6 traffic, all available resources can be consumed, leading to the inability to store next hop information for legitimate traffic.  In extreme cases, the crafted IPv6 traffic may result in a total resource exhaustion and kernel panic.  The issue is triggered by traffic destined to the router.  Transit traffic does not trigger the vulnerability.This issue only affects devices with IPv6 enabled and configured.

Devices not configured to process IPv6 traffic are unaffected by this vulnerability.This issue was found during internal product security testing.Juniper SIRT is not aware of any malicious exploitation of this vulnerability.This issue has been assigned CVE-2016-4921. Solution:The kernel panic (PR 1017099) has been addressed in Junos OS 11.4R13, 12.1X44-D45, 12.1X46-D30, 12.1X47-D20, 12.3R9, 13.3R5, and all software releases listed below.  However, a more complete IPv6 resource management improvement (PR 1037225) has addressed these resource exhaustion issues in the following software releases: 12.3X48-D30, 13.3R10*, 14.1R8, 14.1X53-D40, 14.2R6, 15.1F2-S5, 15.1F5-S2, 15.1F6, 15.1R3, 15.1X49-D40, 15.1X53-D70, 16.1R1, and all subsequent releases.The two fixes for this issue are being tracked as PRs 1037225 and 1017099 which are visible on the Customer Support website.KB16765 - "In which releases are vulnerabilities fixed?" describes which release vulnerabilities are fixed as per our End of Engineering and End of Life support policies.*Available end of Q4/2016. Workaround:Limit the exploitable attack surface of critical infrastructure networking equipment. Use access lists or firewall filters to limit access to the router via IPv6 only from trusted, administrative networks or hosts. Implementation:How to obtain fixed software:Security vulnerabilities in Junos are fixed in the next available Maintenance Release of each supported Junos version.
In some cases, a Maintenance Release is not planned to be available in an appropriate time-frame.

For these cases, Service Releases are made available in order to be more timely.
Security Advisory and Security Notices will indicate which Maintenance and Service Releases contain fixes for the issues described. Upon request to JTAC, customers will be provided download instructions for a Service Release.

Although Juniper does not provide formal Release Note documentation for a Service Release, a list of "PRs fixed" can be provided on request.Modification History: 2016-10-12: Initial publication Related Links:CVSS Score:7.5 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) Risk Level:High Risk Assessment:Information for how Juniper Networks uses CVSS can be found at KB 16446 "Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories." Acknowledgements:

JSA10613 – 2014-07 Security Bulletin: Junos: NTP server amplification denial of...

This issue can affect any product or platform running Junos OS with NTP client or server enabled. 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 victimas the target of an attack against the device itselfIf unwanted NTP requests come into a Junos device, the NTP process will occupy resources such as memory and CPU, slowing down other processes and affecting overall system functionality. In extreme cases, the situation could result in traffic loss or protocol flaps.On the SRX Series platform, NTP requests coming in from security zones to the firewall self-traffic are dropped by default unless the 'host-inbound-traffic' for 'protocol ntp' is explicitly enabled.Neither ScreenOS nor JUNOSe are vulnerable to this issue. These systems do not support the "monlist" feature of NTP.This issue has been assigned CVE-2013-5211. 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 - "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; } } This term may be added  to the existing loopback interface filter as part of an overall control plane protection strategy.  In general, security best practices recommend having such a filter term, even during normal operation.Also, note that the router loopback address must be included under the NTP allow term. If the loopback is not allowed, ‘show ntp’ commands will time out. User@Router> show ntp status localhost: timed out, nothing received ***Request timed out Using the above filter allows only trusted sources to request the NTP service, but if you are interested in identifying the sources of unwanted NTP requests, add the 'log' action to the term block-ntp along with the 'discard' action.  For example: term block-ntp { from { protocol udp; port ntp; } then { log; discard; } } If your trusted IPs are spoofed, then you will have to apply the 'log' action to the allow-ntp accept action as well. This will help in identifying misbehaving trusted sources as well. term allow-ntp { from { source-address { <trusted-addresses>; <router-loopback-address>; } protocol udp; port ntp; } then { log; accept; } } Once you identify the source of unwanted NTP requests, take appropriate action to block them at the network perimete, and delete the 'log' action from the filter term.Note: The 'port' matching criterion is not supported on EX Series platforms other than the EX9200. When applying NTP control plane protection on EX Series, split the filter into two terms using 'source-port' and 'destination-port'. For example: term 1 { from { source-address { <trusted-addresses>; } protocol udp; source-port ntp; } then accept; } term 2 { from { protocol udp; destination-port ntp; } then { discard; } } term default { then accept; } The 'log' action can also be used in this sample firewall filter as described earlier to aid in troubleshooting.Apply the firewall filter to the lo0, me0 or both interfaces, depending on whether NTP attacks are coming from the network port or me0 interface.  The recommendation is: 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. How to obtain fixed software:Security vulnerabilities in Junos are fixed in the next available Maintenance Release of each supported Junos version. In some cases, a Maintenance Release is not planned to be available in an appropriate time-frame. For these cases, Service Releases are made available in order to be more timely. Security Advisory and Security Notices will indicate which Maintenance and Service Releases contain fixes for the issues described. Upon request to JTAC, customers will be provided download instructions for a Service Release. Although Juniper does not provide formal Release Note documentation for a Service Release, a list of "PRs fixed" can be provided on request. Information for how Juniper Networks uses CVSS can be found at KB 16446 "Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories."

JSA10721 – 2016-01: Security Bulletin: Junos: SRX-Series denial of service vulnerability...

This issue can affect any SRX-Series devices running Junos OS prior to 12.1X46-D45, 12.1X47-D30, 12.3X48-D20, 15.1X49-D30 in either standalone or HA mode. On all SRX-Series devices, when the RTSP ALG (Real Time Streaming Protocol Application Layer Gateway) is enabled, a certain crafted RTSP packet might cause the flowd process to crash, halting or interrupting traffic from flowing through the device(s).Repeated crashes of the flowd process may constitute an extended denial of service condition for the device(s).If the device is configured in high-availability, the RG1+ (data-plane) will fail-over to the secondary node.If the device is configured in stand-alone, there will be temporary traffic interruption until the flowd process is restored automatically.Sustained crafted packets may cause the secondary failover node to fail back, or fail completely, potentially halting flowd on both nodes of the cluster or causing flip-flop failovers to occur.Example output "show system core-dumps" will show core file such as:/var/tmp/flowd_xlr-SPC*_PIC*.core.0.gz (in high-end SRX)/var/tmp/flowd_octeon_hm.core-tarball.0.tgz (in Branch SRX)RTSP ALG is enabled by default on branch SRX platforms and disabled by default on high-end SRX platforms.The status of ALGs can be obtained by executing the 'show security alg status' CLI command.Juniper SIRT is not aware of any malicious exploitation of this vulnerability.No other Juniper Networks products or platforms are affected by this issue.This issue has been assigned ​​CVE-2016-1262. The following software releases have been updated to resolve this specific issue: Junos OS 12.1X46-D45 (pending release), 12.1X47-D30, 12.3X48-D20, 15.1X49-D30 and all subsequent releases.This issue is being tracked as PR 1116559 and is visible on the Customer Support website. Disable RTSP ALG services on the device(s).Security vulnerabilities in Junos are fixed in the next available Maintenance Release of each supported Junos version. In some cases, a Maintenance Release is not planned to be available in an appropriate time-frame. For these cases, Service Releases are made available in order to be more timely. Security Advisory and Security Notices will indicate which Maintenance and Service Releases contain fixes for the issues described. Upon request to JTAC, customers will be provided download instructions for a Service Release. Although Juniper does not provide formal Release Note documentation for a Service Release, a list of "PRs fixed" can be provided on request. Modification History: 2016-01-13: Initial publication A network based attacker can cause a denial of service condition.

JSA10520 – 2012-07 Security Bulletin: Junos: Loading factory-default from exclusive edit...

2012-07 Security Bulletin: Junos: Loading factory-default from exclusive edit causes escalation of privileges Legacy Advisory Id:PSN-2012-07-646 Product Affected:This issue can affect any Junos configuration utilizing user class restrictions. Problem:An escalation of privileges can occur when the 'load factory-default' command fails while in exclusive edit mode. When the load command fails, the user is no longer subject to any command and/or configuration restrictions. The escalation is limited to authenticated users with the ability to edit the configuration in the first place. The privilege bypass is specific to configured classes of CLI users with restrictions such as 'allow-commands', 'deny-commands', and 'deny-configuration'. For example: class readonly { permissions [ clear network reset trace view ]; } class readwrite { permissions all; allow-commands "(configure|edit) exclusive"; deny-commands "(^start)|(configure$|edit$)|((configure|edit) (private|dynamic));"; deny-configuration "(system login class)|(system root-authentication)|(system login user .+ class)"; } user homer { uid 1001; class readwrite; } } user bart { uid 1002; class readonly; } After user "homer" above executes 'load factory-default' while in exclusive edit mode, the command fails and the user "homer" is no longer limited to commands or configurations as defined by the user class. Juniper SIRT is not aware of any malicious exploitation of this vulnerability. No other Juniper Networks products or platforms are affected by this issue. Solution:Resolved issue where the user performing a 'load' command was not being recognized as the same user who had an exclusive lock on the database. All Junos OS software releases built on or after 2012-06-01 have fixed this specific issue. Releases containing the fix specifically include: 10.0S26, 10.4R10, 11.2R7, 11.3R6, 11.4R3, 12.1X44-D15, 12.1X45-D10, 12.1R2, and all subsequent releases (i.e. all releases built after 12.1R2). This issue is being tracked as PR 743545 and is visible on the Customer Support website. KB16765 - "In which releases are vulnerabilities fixed?" describes which release vulnerabilities are fixed as per our End of Engineering and End of Life support policies. Workaround:Deny access to the 'load factory-default' command. For example: class lfd-workaround { permissions all; deny-commands "load factory-default"; } Implementation:How to obtain fixed software: Security vulnerabilities in Junos are fixed in the next available Maintenance Release of each supported Junos version. In some cases, a Maintenance Release is not planned to be available in an appropriate time-frame. For these cases, Service Releases are made available in order to be more timely. Security Advisory and Security Notices will indicate which Maintenance and Service Releases contain fixes for the issues described. Upon request to JTAC, customers will be provided download instructions for a Service Release. Although Juniper does not provide formal Release Note documentation for a Service Release, a list of "PRs fixed" can be provided on request. Related Links: CVSS Score:6.3 (AV:L/AC:M/Au:M/C:C/I:C/A:C) Risk Level:Medium Risk Assessment:Information for how Juniper Networks uses CVSS can be found at KB 16446 "Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories." Acknowledgements: 

JSA10638 – 2014-07 Security Bulletin: Junos: Denial of Service in TCP...

2014-07 Security Bulletin: Junos: Denial of Service in TCP packet processing (CVE-2004-0230) Product Affected:This issue can affect any product or platform running Junos OS. Problem:For an established TCP session, TCP input validation only ensures that sequence numbers are within the acceptable window prior to examining whether the SYN flag is set on the segment. If the SYN flag is set, the TCP stack drops the session and sends a RST segment to the other side. Given that the SYN only needs to fall within the window, an attacker who can guess an in-window sequence number, source and destination address and port numbers can exploit this vulnerability to reset any established TCP session.This issue only affects TCP sessions terminating on the router. Transit traffic and TCP Proxy services are unaffected by this vulnerability.Juniper SIRT is not aware of any malicious exploitation of this vulnerability.This issue has been assigned CVE-2004-0230. Solution:Junos now implements the TCP robustness improvements outlined in Section 4 of RFC 5961. Junos will send an ACK in response to any SYN or RST flag received, irrespective of the sequence number.The following software releases have been updated to resolve this specific issue: Junos OS 11.4R11, 12.1R10, 12.1X44-D35, 12.1X45-D25, 12.1X46-D20, 12.1X47-D10, 12.2R8, 12.3R6, 13.1R4, 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 935125 and is visible on the Customer Support website.KB16765 - "In which releases are vulnerabilities fixed?" describes which release vulnerabilities are fixed as per our End of Engineering and End of Life support policies. Workaround:Enable TCP authentication. Refer to Junos documentation for config options and examples.Enable IPSec.Enable the system to send ACKs for in-window RSTs and SYN packets on TCP connections via the 'set system internet-options tcp-reset-syn-acknowledge' hidden configuration command.Enable a stateful firewall to block SYN packets on existing sessions.In addition to the recommendations listed above, it is good security practice to limit the exploitable attack surface of critical infrastructure networking equipment. Use access lists or firewall filters to limit access to the router via TCP only from trusted, administrative networks or hosts. Implementation:How to obtain fixed software:Security vulnerabilities in Junos are fixed in the next available Maintenance Release of each supported Junos version. In some cases, a Maintenance Release is not planned to be available in an appropriate time-frame. For these cases, Service Releases are made available in order to be more timely. Security Advisory and Security Notices will indicate which Maintenance and Service Releases contain fixes for the issues described. Upon request to JTAC, customers will be provided download instructions for a Service Release. Although Juniper does not provide formal Release Note documentation for a Service Release, a list of "PRs fixed" can be provided on request. Related Links: CVSS Score:CVSS Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P) Risk Level:Medium Risk Assessment:Information for how Juniper Networks uses CVSS can be found at KB 16446 "Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories." Acknowledgements: 

JSA10642 – 2014-08 Security Bulletin: Network and Security Manager NSM: Multiple...

NSM release 2012.2R9 addresses vulnerabilities in prior releases with updated Java Runtime Environment. Oracle Java runtime 1.6.0 update_34 was upgraded to 1.7.0 update_51 which fixes a number of critical vulnerabilities that affect server side Java as used in NSM: CVE CVSS v2 base score Summary CVE-2012-5081 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P) Vulnerability in JSSE CVE-2013-0169 2.6 (AV:N/AC:H/Au:N/C:P/I:N/A:N) Vulnerability in TLS aka the "Lucky Thirteen" issue CVE-2013-0440 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P) Vulnerability in JSSE CVE-2013-0443 4.0 (AV:N/AC:H/Au:N/C:P/I:P/A:N) Vulnerability in JSSE CVE-2013-1537 10.0 (AV:N/AC:L/Au:N/C:C/I:C/A:C) Vulnerability in RMI CVE-2013-2407 6.4 (AV:N/AC:L/Au:N/C:P/I:N/A:P) Vulnerability in Java libraries CVE-2013-2451 3.7 (AV:L/AC:H/Au:N/C:P/I:P/A:P) Vulnerability in Networking CVE-2013-2457 5.0 (AV:N/AC:L/Au:N/C:N/I:P/A:N) Vulnerability in JMX CVE-2013-2461 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) Vulnerability in Java libraries CVE-2013-4002 7.1 (AV:N/AC:M/Au:N/C:N/I:N/A:C) DoS vulnerability CVE-2013-5780 4.3 (AV:N/AC:M/Au:N/C:P/I:N/A:N) Vulnerability in Java libraries CVE-2013-5802 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) Vulnerability in JAXP CVE-2013-5803 2.6 (AV:N/AC:H/Au:N/C:N/I:N/A:P) Vulnerability in JGSS CVE-2013-5823 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P) Vulnerability in Java security component CVE-2013-5825 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P) Vulnerability in JAXP CVE-2013-5830 10.0 (AV:N/AC:L/Au:N/C:C/I:C/A:C) Vulnerability in Java libraries CVE-2014-0411 4.0 (AV:N/AC:H/Au:N/C:P/I:P/A:N) Vulnerability in JSSE CVE-2014-0423 5.5 (AV:N/AC:L/Au:S/C:P/I:N/A:P) Vulnerability in Java Beans CVE-2014-0453 4.0 (AV:N/AC:H/Au:N/C:P/I:P/A:N) Vulnerability in Java security component CVE-2014-0460 5.8 (AV:N/AC:M/Au:N/C:P/I:P/A:N) Vulnerability in JNDI NSM Appliance Generic Offline Upgrade Package v1 for CentOS 5.x addresses following vulnerabilities in Apache HTTP server and Apache Runtime Environment: CVE CVSS v2 base score Summary CVE-2012-0031 4.6 (AV:L/AC:L/Au:N/C:P/I:P/A:P) Apache HTTP server denial of service related to scoreboard CVE-2012-0053 4.3 (AV:N/AC:M/Au:N/C:P/I:N/A:N) HTTP-only cookie disclosure vulnerability CVE-2011-3368 5.0 (AV:N/AC:L/Au:N/C:P/I:N/A:N) Access restriction bypass vulnerability in mod_proxy module CVE-2011-3192 7.8 (AV:N/AC:L/Au:N/C:N/I:N/A:C) Remote denial of service vulnerability CVE-2011-0419 4.3 (AV:N/AC:M/Au:N/C:N/I:N/A:P) Remote denial of service vulnerability in APR Vulnerabilities in Java are fixed in NSM 2012.2R9 released August 12, 2014 and all subsequent releases. Vulnerabilities in Apache are resolved by applying "NSM Appliance Generic Offline Upgrade Package for CentOS 5.x " v1 or later. Use access lists or firewall filters to limit access to the NSM server only from trusted hosts. Java vulnerability CVE-2013-5830 has the highest CVSS v2 base score of 10.0 in this advisory.