JSA10748 – Protect-RE(loopback) Firewall Filter does not discard OSPF packets from...

Protect-RE(loopback) Firewall Filter does not discard OSPF packets from non-permitted prefixes Product Affected:This issue affects the EX4300, EX4600, QFX3500, QFX5100 platforms running 14.1X53-D30. Problem:On EX4300, EX4600, QFX3500, QFX5100 platforms, a firewall filter applied on the lo0 interface may not work as expected.  OSPF adjacencies form irrespective of the source-address.

The adjacency should never form using the configuration below.
It should only form if the correct source-address is used in the OSPF_NEIGHBORS term, in this case, the 192.168.1.x/24 subnet.This same configuration works on the EX4200 as expected.

The adjacency does not form until the incorrect source-address is replaced with the correct one.In below example, an incorrect source-address 172.16.1.x/32 subnet is used intentionally in the OSPF_NEIGHBOR term.

The term should not match and it should go to the next term - DENY_ANY term, where the action is count and discard. However, the adjacency forms regardless of the source-address in the OSPF_NEIGHBOR term.
It is not discarded or counted by DENY_ANY term as indicated by the formation of a Full adjacency and DENIED_TRAFFFIC counter.JTAC Lab setup DetailsThis limitation is reproduced in the JTAC lab using EX4300. EX4300-1 - ge-0/0/15 ------------ ge-0/0/15 - EX4300-2Configuration {master:0} root@ospf-1> show configuration | display set set version 13.2X51-D37.1 set system host-name ospf-1set system root-authentication encrypted-password "$1$QKgKM4mj$SjcxtW9i/ILQQYLK2IMzF1"set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/24set interfaces lo0 unit 0 family inet filter input OSPF_FILTERset interfaces lo0 unit 0 family inet address 1.1.1.1/32set protocols ospf area 0.0.0.0 interface ge-0/0/0.0set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from source-address 172.16.1.2/32set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from protocol ospfset firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then logset firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then acceptset firewall family inet filter OSPF_FILTER term DENY_ANY then count DENIED_TRAFFICset firewall family inet filter OSPF_FILTER term DENY_ANY then discard{master:0}root@ospf-2> show configuration | display setset version 14.1X53-D30.3set system host-name ospf-2set system root-authentication encrypted-password "$1$m0KUv05.$jkU1qDmiRaEuW5zTQxNm80"set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/24set interfaces lo0 unit 0 family inet filter input OSPF_FILTERset interfaces lo0 unit 0 family inet address 2.2.2.2/32set protocols ospf area 0.0.0.0 interface ge-0/0/0.0set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from source-address 172.16.1.1/32set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from protocol ospfset firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then logset firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then acceptset firewall family inet filter OSPF_FILTER term DENY_ANY then count DENIED_TRAFFICset firewall family inet filter OSPF_FILTER term DENY_ANY then discard Solution:Root CauseIn a nutshell, EX4200 and EX4300 use different chipsets and hence there are changes in the way these (multicast destination IP – 224.0.0.X) packets are handled. OSPF packets are making it to CPU due to implicit rule to allow IP reserved Multicast packets which is placed before last discard term.

This is needed to allow all multicast transit packets to not get discarded. We are basically running into chipset limitations.

To handle limitations/behaviors, our design expects user to add explicit discard term for the kind of packets that are not needed to be trapped to CPU.

The last discard term discards regular L3 data packets (except destination IP=224.0.0.x packets) and control packets which are L3 routed and not explicitly accepted by terms before.We are basically dealing with below limitations:Chipset on EX4300, EX4600, QFX3500, QFX5100 platforms sets destination port as CPU port even for transit multicast packetsEX4300, EX4600, QFX3500, QFX5100 platforms chipset's action resolution engine, Discard wins over any action and hence in the absence of implicit term to allow reserved multicast packets, protocol packets would get discarded if user does not configure explicit term for each and every packet which is not scalable.EX4300, EX4600, QFX3500, QFX5100 platforms chipset does not treat TTL expired packets as routed packets and loopback filter being applied on family inet, it is expected to act only on L3 routed packetsSolutionTo overcome this limitation, it is required to configure explicit discard term for unwanted OSPF packets as below to overcome specific chipset limitations. root@ospf-2# show | compare [edit firewall family inet filter OSPF_FILTER] term OSPF_NEIGHBOR { ... } + term OSPF_tmp { + from { + source-address { + 192.168.1.1/32; + } + protocol ospf; + } + then { + count intersted_SA; + discard; <--------- + } + } term DENY_ANY { ... } root@ospf-2> show ospf neighbor (no output returned)This is specific to the packets with multicast destination IP – 224.0.0.X address.
Since OSPF hello uses 224.0.0.5 address, it requires explicit discard for unwanted source IP addresses.

Any other terms which do not use this address should not be impacted.

For example, SSH and IPV6 traffic is not affected by this limitation. Workaround:See Solution section above. Implementation:  Related Links: CVSS Score:5.3 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) Risk Level:Medium Acknowledgements: 

JSA10748 – Protect-RE (loopback) Firewall Filter does not discard OSPF packets...

Protect-RE (loopback) Firewall Filter does not discard OSPF packets from non-permitted prefixes Product Affected:This issue affects any EX4300, EX4600, QFX3500, QFX5100 platforms running Junos OS. Problem:On EX4300, EX4600, QFX3500, QFX5100 platforms, a firewall filter applied on the lo0 interface may not work as expected.  OSPF adjacencies form irrespective of the source-address.

The adjacency should never form using the configuration below.
It should only form if the correct source-address is used in the OSPF_NEIGHBORS term, in this case, the 192.168.1.x/24 subnet.This same configuration works on the EX4200 as expected.

The adjacency does not form until the incorrect source-address is replaced with the correct one.In below example, an incorrect source-address 172.16.1.x/32 subnet is used intentionally in the OSPF_NEIGHBOR term.

The term should not match and it should go to the next term - DENY_ANY term, where the action is count and discard. However, the adjacency forms regardless of the source-address in the OSPF_NEIGHBOR term.
It is not discarded or counted by DENY_ANY term as indicated by the formation of a Full adjacency and DENIED_TRAFFFIC counter.JTAC Lab setup DetailsThis limitation is reproduced in the JTAC lab using EX4300. EX4300-1 - ge-0/0/15 ------------ ge-0/0/15 - EX4300-2Configuration {master:0} root@ospf-1> show configuration | display set set version 13.2X51-D37.1 set system host-name ospf-1set system root-authentication encrypted-password "$1$QKgKM4mj$SjcxtW9i/ILQQYLK2IMzF1"set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/24set interfaces lo0 unit 0 family inet filter input OSPF_FILTERset interfaces lo0 unit 0 family inet address 1.1.1.1/32set protocols ospf area 0.0.0.0 interface ge-0/0/0.0set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from source-address 172.16.1.2/32set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from protocol ospfset firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then logset firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then acceptset firewall family inet filter OSPF_FILTER term DENY_ANY then count DENIED_TRAFFICset firewall family inet filter OSPF_FILTER term DENY_ANY then discard{master:0}root@ospf-2> show configuration | display setset version 14.1X53-D30.3set system host-name ospf-2set system root-authentication encrypted-password "$1$m0KUv05.$jkU1qDmiRaEuW5zTQxNm80"set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/24set interfaces lo0 unit 0 family inet filter input OSPF_FILTERset interfaces lo0 unit 0 family inet address 2.2.2.2/32set protocols ospf area 0.0.0.0 interface ge-0/0/0.0set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from source-address 172.16.1.1/32set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from protocol ospfset firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then logset firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then acceptset firewall family inet filter OSPF_FILTER term DENY_ANY then count DENIED_TRAFFICset firewall family inet filter OSPF_FILTER term DENY_ANY then discard Solution:Root CauseIn a nutshell, EX4200 and EX4300 use different chipsets and hence there are changes in the way these (multicast destination IP – 224.0.0.X) packets are handled. OSPF packets are making it to CPU due to implicit rule to allow IP reserved Multicast packets which is placed before last discard term.

This is needed to allow all multicast transit packets to not get discarded. We are basically running into chipset limitations.

To handle limitations/behaviors, our design expects user to add explicit discard term for the kind of packets that are not needed to be trapped to CPU.

The last discard term discards regular L3 data packets (except destination IP=224.0.0.x packets) and control packets which are L3 routed and not explicitly accepted by terms before.We are basically dealing with below limitations:Chipset on EX4300, EX4600, QFX3500, QFX5100 platforms sets destination port as CPU port even for transit multicast packetsEX4300, EX4600, QFX3500, QFX5100 platforms chipset's action resolution engine, Discard wins over any action and hence in the absence of implicit term to allow reserved multicast packets, protocol packets would get discarded if user does not configure explicit term for each and every packet which is not scalable.EX4300, EX4600, QFX3500, QFX5100 platforms chipset does not treat TTL expired packets as routed packets and loopback filter being applied on family inet, it is expected to act only on L3 routed packetsSolutionTo overcome this limitation, it is required to configure explicit discard term for unwanted OSPF packets as below to overcome specific chipset limitations. root@ospf-2# show | compare [edit firewall family inet filter OSPF_FILTER] term OSPF_NEIGHBOR { ... } + term OSPF_tmp { + from { + source-address { + 192.168.1.1/32; + } + protocol ospf; + } + then { + count intersted_SA; + discard; <--------- + } + } term DENY_ANY { ... } root@ospf-2> show ospf neighbor (no output returned)This is specific to the packets with multicast destination IP – 224.0.0.X address.
Since OSPF hello uses 224.0.0.5 address, it requires explicit discard for unwanted source IP addresses.

Any other terms which do not use this address should not be impacted.

For example, SSH and IPV6 traffic is not affected by this limitation. Workaround:See Solution section above. Implementation:Modification History: 2016-04-26: Initial publication2016-05-02: Removed software version reference.  Affects all versions of Junos OS. Related Links: CVSS Score:5.3 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) Risk Level:Medium Acknowledgements: 

JSA10722 – Cross-protocol attack on TLS using SSLv2 (DROWN) (CVE-2016-0800)

Refer to Problem section below.On March 1, 2016, a cross-protocol attack was announced by OpenSSL that could lead to decryption of TLS sessions by using a server supporting SSLv2 and EXPORT cipher suites as a Bleichenbacher RSA padding oracle. Note tha...

JSA10718 – 2016-01 Security Bulletin: Junos: Vulnerability in ISC BIND named...

2016-01 Security Bulletin: Junos: Vulnerability in ISC BIND named (CVE-2015-5477) Product Affected:This issue can affect any SRX-Series and J-Series configured with DNS Proxy server services enabled. Problem:A vulnerability in ISC BIND's handling of queries for TKEY records may allow remote attackers to terminate the daemon process on an assertion failure. Juniper SIRT is not aware of any malicious exploitation of this issue on Junos devices.   The Juniper SIRT is aware of publicly available PoC exploits.This issue affects only SRX-Series and J-Series configured with DNS Proxy server services enabled.  This issue can affect both standalone and HA configurations.This issue has been assigned CVE-2015-5477. Solution:The following software releases have been updated to resolve this specific issue: Junos OS 12.1X44-D55, 12.1X46-D40, 12.1X46-D45, 12.1X47-D30, 12.3R11, 12.3R12, 12.3X48-D20, 12.3X50-D50, 13.2R9, 13.2X51-D39, 13.2X51-D40, 13.3R8, 14.1R6, 14.1R7, 14.1X53-D30, 14.2R5, 15.1F3, 15.1R2, 15.1R3, 15.1X49-D30, 15.1X53-D20, 15.2R1 and all subsequent releases. Note:  To proactively mitigate this issue in the future, should DNS Server features be introduced into other Junos OS platforms and products, this issue is fixed in the other stated platforms other than the ones listed as vulnerable under this JSA. This BIND issue does affect, but these versions are not vulnerable to this issue, as enabling the DNS Server feature does not exists on these platforms. Should SRX-Series and J-Series releases assume R-releases in the future, these versions are fixed moving forward in these release trains as well.This issue is being tracked as PR 1108761 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:DNS proxy can be disabled; the following example set statements show if the service is enabled: set dns dns-proxy interface ge-0/0/1.0set dns dns-proxy default-domain * forwarders 172.17.28.100You may view the status of DNS proxy via the command: show system services dns dns-proxyFirewall filters limiting receipt of DNS queries on TCP and UDP port 53 can be implemented for different hosted groups of DNS servers; external DNS servers should be separate from internal DNS servers. External DNS servers should only accept DNS queries from internal DNS servers and reject externally facing DNS queries if using BIND.A layered approach utilizing non-BIND based DNS servers may be taken as well; non-BIND servers can be deployed for externally hosted domains, and servers using BIND can be deployed internally.In addition to the recommendations listed above, it is a 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 devices 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-01-13: Initial publication Related Links: CVSS Score:5.3 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) Risk Level:Medium Acknowledgements: 

JSA10714 – 2016-01: Security Bulletin: Junos: Multicast denial of service related...

This issue can affect any product or platform running Junos OS with IGMPv3 enabled Receipt of a crafted IGMPv3 protocol message can create a denial of service to a portion of a multicast network.  This issue only affects IGMPv3.  IGMPv2 is unaffected by this vulnerability.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-1256. The following software releases have been updated to resolve this specific issue: Junos OS 12.1X44-D55, 12.1X46-D40, 12.1X47-D25, 12.3R10, 12.3X48-D20, 13.2R8, 13.2X51-D40, 13.3R7, 14.1R5, 14.1X53-D18, 14.1X53-D30, 14.1X55-D25, 14.2R4, 15.1R2, 15.1X49-D10, and all subsequent releases. This issue is being tracked as PR 1079503 and is visible on the Customer Support website. Disabling IGMPv3, falling back to IGMPv2, will mitigate this issue, but may result in reduced functionality (e.g. PIM source-specific multicast requires IGMPv3).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-01-13: Initial publication Information for how Juniper Networks uses CVSS can be found at KB 16446 "Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories."

JSA10720 – 2016-01 Security Bulletin: Junos: J-Web denial of service due...

2016-01 Security Bulletin: Junos: J-Web denial of service due to vulnerability in Embedthis Appweb Server (CVE-2016-1258) Product Affected:These issues can affect any product or platform running Junos OS with J-Web enabled. Problem:A denial of service vulnerability in Embedthis Appweb Server while processing certain malformed HTTP requests may allow a remote unauthenticated user to crash the J-Web service. 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-1258 Solution:The following software releases have been updated to resolve this specific issue: Junos OS 12.1X44-D60, 12.1X46-D45 (pending release), 12.1X47-D30, 12.3R10, 12.3R11, 12.3X48-D20, 13.2X51-D20, 13.3R8, 14.1R6, 14.2R5 and all subsequent releases. This issue is being tracked as PR 925108 and is visible on the Customer Support website. Workaround:Disable J-Web, or limit access to only trusted 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-01-13: Initial publication. Related Links: CVSS Score:5.3 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) Risk Level:Medium Risk Assessment:A network based unauthenticated attacker can cause the J-Web service on a device to become unavailable. Acknowledgements: 

JSA10715 – 2016-01 Security Bulletin: Junos: RPD crash in processing LDP...

2016-01 Security Bulletin: Junos: RPD crash in processing LDP packets (CVE-2016-1257) Product Affected:This issue can affect any product or platform running a Junos OS release listed below with LDP enabled Problem:If LDP is enabled via the 'protocols ldp' configuration option on a device running Junos OS, receipt of a crafted LDP packet may cause the RPD routing process to crash and restart.  The interface on which the packet arrives does not need to have LDP enabled.  As long as one interface to the peer has LDP enabled, the packet will be sent to Routing Engine for further processing, exposing the router to a denial of service (RPD crash). This issue is a regression defect introduced in JUNOS 13.2R5, 13.3R1, 14.1R1, 14.2R1, and 15.1 releases. Junos versions prior to 13.2R5 are not affected by this issue. Juniper SIRT is not aware of any malicious exploitation of this vulnerability. However, the issue has been seen in a production network due to LDP packets originating from a different vendor's device. No other Juniper Networks products or platforms are affected by this issue. This issue has been assigned CVE-2016-1257. Solution:The following software releases have been updated to resolve this specific issue: Junos OS 13.3R7-S3, 13.3R8, 14.1R3-S9, 14.1R4-S7, 14.1R6, 14.1X51-D65, 14.1X53-D12, 14.1X53-D28, 14.1X53-D35, 14.2R3-S4, 14.2R4-S1, 14.2R5, 15.1F2-S2, 15.1F3, 15.1R3, 15.1X49-D40* and all subsequent releases.This issue is being tracked as PR 1096835 and is visible on the Customer Support website.*15.1X49-D40 will be available later in Q1/2016 Workaround:Disable LDP if it is not required, or use access lists or firewall filters to limit access to the device via LDP only from trusted 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-01-13: Initial publication. Related Links: CVSS Score:5.9 (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) 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: 

JSA10719 – 2016-01 Security Bulletin: Junos: EX4300 Series denial of service...

2016-01 Security Bulletin: Junos: EX4300 Series denial of service due to artificial loop in network topology (CVE-2016-1260) Product Affected:This issue can affect EX4300-Series switches. Problem:A certain type of legitimate traffic which can be maliciously crafted or may be valid traffic for networking requirements in customer sites received from ingress interfaces through the EX-PFE leak out blocked Spanning Tree Protocol egress interfaces creating an artificial loop in network topology. This can lead to a high bandwidth usage denial of service condition.  Continued packets can create a persistent denial of service condition. This issue is most likely to occur in Virtual Chassis (VC) configurations. 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-1260. Solution:The following software releases have been updated to resolve this specific issue: Junos OS 13.2X51-D36, 13.2X51-D39, 14.1X53-D25, 14.1X53-D26, 15.2R1 and all subsequent releases. This issue is being tracked as PR 1069179 and is visible on the Customer Support website. Workaround:Eliminating Spanning Tree Protocol usage from the network and blocking any ingress or egress STP traffic may mitigate this issue. Implementation: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 Related Links: CVSS Score:5.3 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) Risk Level:Medium Risk Assessment:A network based attacker can create high network bandwidth usage denial of service condition. Acknowledgements: 

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.

JSA10712 – 2015-12 Out of Cycle Security Bulletin: ScreenOS: Crafted SSH...

2015-12 Out of Cycle Security Bulletin: ScreenOS: Crafted SSH negotiation may trigger system crash (​CVE-2015-7754) Product Affected:This issue can affect any product or platform running ScreenOS 6.3.0r20. Problem:A crafted SSH negotiation may result in a system crash when ssh-pka is configured and enabled on the firewall. In the worst case scenario, the unhandled SSH exception resulting in a system crash could lead to remote code execution.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-2015-7754. Solution:The following software releases have been updated to resolve this specific issue: ScreenOS 6.3.0r21, and all subsequent releases.This issue is being tracked as PR 1139205 which 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:Use access lists or firewall filters to limit access to the device via administrative login (e.g. SSH) only from trusted hosts, or restrict management access to specific IP addresses.  Refer to KB3905 for more information about restricting management access in ScreenOS.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 management access to the device only from trusted, administrative networks or hosts. Implementation:How to obtain fixed software:ScreenOS software releases are available at http://www.juniper.net/support/downloads/screenos.htmlModification History: 2015-12-17: Initial publication Related Links: CVSS Score:9.8 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) Risk Level:Critical 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: 

JSA10713 – 2015-12 Out of Cycle Security Bulletin: ScreenOS: Multiple Security...

2015-12 Out of Cycle Security Bulletin: ScreenOS: Multiple Security issues with ScreenOS (CVE-2015-7755) Product Affected:These issues can affect any product or platform running ScreenOS 6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 6.3.0r20. Problem:During an internal code review, two security issues were identified.The first issue allows unauthorized remote administrative access to the device over SSH or telnet. Exploitation of this vulnerability can lead to complete compromise of the affected system.Upon exploitation of this vulnerability, the log file would contain an entry that ‘system’ had logged on followed by password authentication for a username.Example: Normal login by user username1:2015-12-17 09:00:00 system warn 00515 Admin user username1 has logged on via SSH from …..2015-12-17 09:00:00 system warn 00528 SSH: Password authentication successful for admin user ‘username1’ at host …Compromised login by user username2:2015-12-17 09:00:00 system warn 00515 Admin user system has logged on via SSH from …..2015-12-17 09:00:00 system warn 00528 SSH: Password authentication successful for admin user ‘username2’ at host …Note that a skilled attacker would likely remove these entries from the log file, thus effectively eliminating any reliable signature that the device had been compromised.The second issue may allow a knowledgeable attacker to decrypt encrypted VPN traffic.There is no way to detect that this vulnerability was exploited.Juniper SIRT is not aware of any malicious exploitation of these vulnerabilities.No other Juniper Networks products or platforms are affected by these issues.These issues have been assigned CVE-2015-7755.Juniper has issued a statement about these vulnerabilities at: http://forums.juniper.net/t5/Security-Incident-Response/bg-p/SIRT Solution:The following software releases have been updated to resolve these specific issues: ScreenOS 6.2.0r19, 6.3.0r21, and all subsequent releases.Additionally, earlier affected releases of ScreenOS 6.3.0 have been respun to resolve these issues. Fixes are included in: 6.3.0r12b, 6.3.0r13b, 6.3.0r14b, 6.3.0r15b, 6.3.0r16b, 6.3.0r17b, 6.3.0r18b, 6.3.0r19b.All affected software releases on http://www.juniper.net/support/downloads/screenos.html have been updated with these fixes.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:The Juniper SIRT strongly recommends upgrading to a fixed release (in Solution section above) to resolve these critical vulnerabilities.No workaround exists for these issues. 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 management access to the device only from trusted, internal, administrative networks or hosts. Doing so would mitigate the first issue but not the second. Implementation:How to obtain fixed software:ScreenOS software releases are available at http://www.juniper.net/support/downloads/screenos.htmlModification History: 2015-12-17: Initial publication Related Links: CVSS Score:9.8 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) Risk Level:Critical 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: