We receive some questions regarding the "ssh-keysign-pwn" exploit.
To our understanding, exploiting this Linux kernel bug relies on setuid binaries that open files that an unprivileged user otherwise couldn't read, and let users steal those open file descriptors in a race against the setuid binary exiting. This means it is not a "root exploit" in the sense that an unprivileged user would gain root permissions, and it also does not allow to open any file of the attacker's choice, but only stealing the file descriptors of files opened by the setuid binary.
While a patch made it into the mainline kernel, as of now, no updated kernel release has been made, and no updated kernel packages are available for any major Linux distribution including those we use for U7 and U8; because of that, we label this incident as "Identified", not "Fixed".
We have however removed the setuid bits of the chage and ssh-keysign commands. We are aware that this is not a fix but rather a mitigation for that specific exploit that is in the wild. For a real fix we have to wait for Linux kernel updates becoming available.
Regarding U7:
ssh-keysign never worked. On CentOS 7, ssh-keysign is installed setgid ssh_keys, not setuid root. Because the private keys are mode 0600 owned by root:root, the setgid bit does not grant read access to them. Therefore this specific exploit vector does not work there.chage would have worked until we stripped the permissions of the binary, in theory giving access to the /etc/shadow file. This does not contain passwords though, but password hashes only, and only for those users who actively set SSH passwords (we don't set one by default, and we recommend using SSH keys). This is not an immediate danger, but having the password hashes available allows them to be cracked later. We recommend to change the asteroid SSH password.Regarding U8:
ssh-keysign could in theory have exposed the private keys of the SSH host keys. While not a direct compromise, stolen SSH host private keys allow an attacker who can also manipulate DNS or network routing to impersonate the U8 host in question. This could enable interception of password-based logins. Even in this case, only users using SSH passwords would be in danger; using SSH keys to log in would not reveal any sensitive information to an attacker.chage would have worked until we stripped the permissions of the binary, in theory giving access to the /etc/shadow file. This does not contain passwords though, but password hashes only, and only for those users who actively set SSH passwords (we don't set one by default, and we recommend using SSH keys). This is not an immediate danger, but having the password hashes available allows them to be cracked later. We recommend to change the asteroid SSH password.This statement will be updated when kernel updates become available.