OpenSSH 10.6p2, musl 리눅스 임계 취약점 완화책 담아 하루 만에 긴급 릴리스

musl만 해당되고 고치는 법은 PasswordAuthentication=no임. 근데 이건 그냥 일반적으로도 좋은 조언 아님?

그럼 디지털 생활은 어떻게 복구함? 낯선 데서 깨어났는데 지갑도 키도 폰도 다 없어진 상황이면, 인터넷 되는 노트북 하나로 복구하려면 어딘가 비밀번호 인증이 켜져 있어야 하잖아.

그 조언은 접속하는 기기 홈이 암호화돼 있고 ssh 개인키도 보호될 때만 좋은 거임. 아니면 오히려 위험해짐.

서버를 wireguard 안에 넣고 그 안에서만 ssh 허용하는 것도 추천함. ssh를 인터넷에 굳이 노출할 이유가 없음.

기본값이 on인 게 항상 불편했음. 키 쓰는 게 더 편한데, 솔직히 비밀번호 인증이 왜 필요한지 모르겠음.

Dropbear, 그러니까 musl 기반 OpenWrt 라우터도 안전한 거임? 그 정규식 문제인지 궁금한데.

글 올린 뒤에 스레드에서 여러 명이 dropbear는 영향 없다고 확인해줬음.

취약점 발견한 사람이 sshhole.com에 정리해뒀는데 거기 아래에 dropbear는 영향 없다고 나옴. debian, ubuntu, fedora나 glibc, pam, openbsd 쓰면 다 괜찮음.

대부분은 안전한데 이미지를 OpenSSH로 빌드한 제조사는 예외임. Turris가 그런 벤더로 언급됐음.

완화책? 왜 수정이 아님?

버그가 musl에 있고 OpenSSH에 없어서 그럼.

릴리스 노트엔 critical security workaround라고 써놓고 security 페이지엔 아무것도 없음. 자기 코드 버그가 아니어도 critical 릴리스면 올리는 게 맞지 않나.

musl이 crypt()의 POSIX 동작을 위반함. 성공하면 해시 포인터를 반환해야 하는데 musl은 '!'나 '*'를 반환함.

요즘 누가 PasswordAuthentication=yes 씀?

cockpit 돌리면 비밀번호 인증 켜야 하고, openwrt 사용자도 꽤 될 걸. 클라우드 제공자 기본값도 비밀번호인 경우가 많음.

은행이나 보험사 SFTP 고객들이 키 기반 인증 무시하고 비밀번호를 요구해서 켜둠. 규제 업체들이 생각보다 많음.

취약점 조건이 전부 AND라서 그렇게 큰 문제는 아님. musl로 컴파일, PAM 미사용, 비밀번호 로그인 활성화, '*' 해시 계정 존재, 다른 유효 비밀번호 계정 존재가 다 맞아야 함.

Alpine 기본 설치는 /etc/shadow에 '*' 대신 '!'를 써서 실제로 공격이 안 통함.

AI 에이전트가 버그를 몇 시간 만에 재발견하니 긴 엠바고는 곧 안 쓰이게 될 듯. 몇 달은 험할 것 같음.

OpenBSD는 영향 없고 glibc 리눅스, PAM 리눅스도 안전함. musl 리눅스만 원격 구멍이라 '기본 설치에서 원격 구멍 두 개' 문구는 아직 안 고쳐도 됨.