I have discovered a new security issue in the Yubico HSM client-side code. An attacker with control over the data input of the SSH Certificate Signing
functionality can cause a stack buffer overflow with arbitrary data in the yubihsm-shell tool. The overflow is mitigated into a denial of service through existing runtime hardening.
I’m a freelance Security Consultant and currently available for new projects.
If you are looking for assistance to secure your projects or organization, contact me.
Please see some of the previous articles on libyubihsm for the technical background and relevance of this code.
Unlike other Yubico HSM client issues, this flaw is specific to the standalone CLI program and doesn’t affect users of the library code.
Let’s talk about the code that leads to the issue.
When yubihsm-shell is called with the sign-ssh-certificate action, it checks the required parameters:
Once the checks are passed, the SSH certificate file is read in via get_input_data() and stored in the local buf buffer.
Notably, this buffer accepts up to 8192 bytes of binary input and is generically used for different actions.
The buffer is then passed to the yh_com_sign_ssh_certificate() function, which is defined like this:
The YH_MSG_BUF_SIZE is set to 2048, so the local data buffer holds 3072 bytes. Since the correlating response_len size limit is not used correctly to restrict write operations, the memcpy() operation performs a classic stack buffer overflow beyond the end of data if yubihsm-shell is called on SSH certificate input files that are between 3073 and 8192 bytes in length.
Stack buffer overflows with arbitrary binary data of variable length are fairly interesting for attackers since they can be used for reliable stack smashing attacks. If successful, this redirects the program control flow and allows - more or less - arbitrary code execution.
Fortunately for yubihsm-shell users, the existing RELEASE target build steps include the hardening flags -fstack-protector-all and -D_FORTIFY_SOURCE=2 (on non-Windows builds). This instructs the compiler to add runtime checks which detect the buffer overflow and terminate the program before additional harm is done.
As a result, the program terminates either directly during the memcpy() or at the end of the yh_com_sign_ssh_certificate() function.
The expected impact therefore is a denial of service of yubihsm-shell.
Attack Scenario and Security Implications
Based on my understanding of the affected CLI functionality, the SSH certificate file is plausibly generated a lower-privileged or untrusted external user and moved to the target system for signing via the HSM by a higher-privileged user. The trust boundary step that is involved makes this vulnerability interesting from a conceptual standpoint. However, the denial of service impact is without major consequences, especially if yubihsm-shell is operated manually.
A notable side effect of the specific CLI crash behavior is that one of the 16 communication session slots of the HSM2 target stays blocked until it times out after 30 seconds. If there is an automated system that can be tricked into processing problematic SSH certificates via yubihsm-shellrepeatedly and in quick succession, this can be used to cause a temporary denial of service of the HSM for other client connections, if there are any.
I have focused on the CVSS score for
a local attack
enough privileges to influence the SSH certificate file on disk before it is used
manual use by the yubihsm-shell operator
with an availability impact
There are other ways to score this and Yubico has chosen a slightly different approach. Overall, the issue severity is somewhere between Low and Medium, primarily due to the effective mitigations that prevent more serious effects in practice.
It definitely helped to have an existing communication channel. My impression is that the disclosure coordination was not as fluid as with previous issues, and there were a number of hiccups along the way that required extra attention.
However, I still think it is positive that yubihsm-shell is developed as open source code and available for independent review, even though the release schedule and extra release preparations make it more time consuming than other projects to report security issues in.