A Missing Release of Resource after Effective Lifetime vulnerability the xinetd process, responsible for spawning SSH daemon (sshd) instances, of Juniper Networks Junos OS Evolved allows an unauthenticated network-based attacker to cause a Denial of Service (DoS) by blocking SSH access for legitimate users. Continued receipt of these connections will create a sustained Denial of Service (DoS) condition.
The issue is triggered when a high rate of concurrent SSH requests are received and terminated in a specific way, causing xinetd to crash, and leaving defunct sshd processes. Successful exploitation of this vulnerability blocks both SSH access as well as services which rely upon SSH, such as SFTP, and Netconf over SSH.
Once the system is in this state, legitimate users will be unable to SSH to the device until service is manually restored. See WORKAROUND section below.
Administrators can monitor an increase in defunct sshd processes by utilizing the CLI command:
> show system processes | match sshd
root 25219 30901 0 Jul16 ? 00:00:00 [sshd]
This issue affects Juniper Networks Junos OS Evolved:
- All versions prior to 21.4R3-S7-EVO
- 22.3-EVO versions prior to 22.3R2-S2-EVO, 22.3R3-S2-EVO;
- 22.4-EVO versions prior to 22.4R3-EVO;
- 23.2-EVO versions prior to 23.2R2-EVO.
This issue does not affect Juniper Networks Junos OS Evolved 22.1-EVO nor 22.2-EVO.
Weakness
The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
Potential Mitigations
- Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.
- Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.
- When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.
- Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).
References