OpenSSH 10.6p2, musl·PAM 비활성 Linux sshd의 암호 우회 완화

OpenSSH는 2026년 11월 5일 10.6p2를 공개하며, musl libc를 사용하고 PAM 지원을 끈 일부 Linux에서 sshd의 암호 인증 우회를 막는 완화책을 넣었다고 밝혔습니다. 릴리스 노트는 원인이 sshd 바깥에 있지만 sshd에서 악용을 막을 수 있다고 설명합니다. OpenSSH는 보고자로 Wakefield의 Özgün Kültekin을 지목했습니다. Kültekin이 공개한 *sshole 페이지에는 공격 조건과 자체 시험 결과가 담겼습니다.

이 문제에서는 별표 두 개가 서로 다른 곳에서 같은 문자열로 쓰입니다. /etc/shadow의 비밀번호 필드에 *를 넣으면 해당 계정의 암호 인증을 잠그는 표식이 됩니다. musl의 crypt()도 해시 계산에 실패하면 *를 반환합니다. 첫 번째 별표는 계정 잠금 상태를 나타내고, 두 번째는 해시 계산 실패를 나타내지만, sshd가 비교하는 값은 둘 다 같은 문자열입니다.

musl은 2012년 변경에서 crypt()가 실패할 때 NULL 대신 일치하지 않는 해시 문자열을 반환하도록 했습니다. musl의 변경 설명은 crypt()를 호출하는 프로그램 중 반환값이 NULL인지 확인하지 않아 오류가 생기는 경우가 많다는 점을 이유로 들었습니다. 이어 추가된 SHA-512 방식의 암호 해시는 입력 키 길이를 256바이트로 제한합니다. 긴 입력의 계산 비용이 커져 서비스 거부 공격에 이용될 수 있다는 점을 막기 위한 제한입니다. 이 한도를 넘긴 입력의 계산은 실패하고, musl의 crypt()는 그 실패를 *로 나타냅니다.

PAM을 쓰지 않는 OpenSSH의 암호 인증 경로에는 사용자 계정의 존재 여부가 처리 시간 차이로 드러나는 것을 줄이기 위한 처리가 있습니다. 계산할 수 있는 비밀번호 해시가 없으면 sshd는 비밀번호가 설정된 다른 계정의 salt를 가져와 입력값을 해시합니다. 일반적인 길이의 입력에서는 계산 결과가 실제 해시 문자열이 되므로 잠금 표식 *와 일치하지 않습니다. 하지만 입력이 musl의 256바이트 한도를 넘으면 crypt()가 *를 반환하고, 이 값이 대상 계정의 shadow 필드에 저장된 *와 같아져 암호 인증이 통과하는 경로가 생깁니다.

공격에는 조건이 겹쳐야 합니다. 서버가 musl 기반 Linux에서 실행되고, sshd가 PAM을 사용하지 않으며, 암호 로그인이 켜져 있어야 합니다. 대상 계정의 shadow 필드가 *이고, salt를 가져올 수 있는 실제 비밀번호 해시를 가진 다른 계정도 있어야 합니다. *sshole 페이지가 제시한 공격 입력 길이는 257~1024자입니다. 따라서 musl을 사용한다는 사실만으로 이 우회가 성립하지는 않습니다.

Alpine의 rootfs 설정은 잠금 표식 *가 실제로 쓰이는 사례입니다. Alpine aports의 2022년 변경은 root 계정의 shadow 필드를 !에서 *로 바꿨습니다. 변경 설명에 따르면 PAM을 사용하지 않는 환경에서도 SSH 키 로그인을 허용하면서 암호 로그인은 계속 막기 위한 설정입니다. 이처럼 암호 인증을 잠근 계정의 *가 musl의 해시 실패 표시와 겹치는 환경이 만들어질 수 있습니다.

Kültekin은 공개 페이지에서 glibc와 musl, PAM 사용 여부와 shadow 설정 등을 달리한 sshd 빌드에 약 1만7600건의 비정상 로그인 입력을 보냈다고 밝혔습니다. 그의 시험에서는 musl을 사용하면서 PAM을 끈 조합에서만 예상과 다른 로그인이 나타났습니다. 이는 Kültekin이 공개한 자체 시험 결과이며, OpenSSH 릴리스 노트는 취약점 보고와 10.6p2의 완화책을 확인합니다.

10.6p2는 musl의 해시 동작이 아니라 sshd에서 우회 경로를 막는 완화책을 제공합니다. 업데이트가 어려운 경우에는 암호 인증을 끄는 방법도 있습니다. *sshole 페이지는 PasswordAuthentication no 설정을 대안으로 제시합니다.