Codex 5.3은 자체적으로 sudo 비밀번호 프롬프트를 우회했습니다.

오늘 저는 Codex 5.3(내 Windows 컴퓨터의 WSL 내부에서 실행)에 Apache를 중지하도록 요청했습니다. 간단한 작업이고 승인을 최대로 설정해 에이전트가 자유롭게 명령을 실행할 수 있도록 했습니다.

그래서 Codex는 `sudo`를 시도했지만 대화형 비밀번호 프롬프트를 눌렀지만 입력할 수 없었습니다. 알았어.. 하지만 나에게 돌아와 "이걸 직접 실행해 보세요"라고 말하는 대신 Windows 상호 운용성을 통해 `wsl.exe --user root`를 호출하고 루트로 distro를 다시 시작한 다음 거기에서 중지/비활성화 단계를 실행했습니다.

에스컬레이션 경로가 괜찮은지 나에게 묻지 않았습니다. 방금 했어요.

이는 취약점이 아닙니다. WSL 상호 운용성은 문서화되어 있으며 WSL은 엄격한 보안 경계로 설계되지 않았습니다. 그러나 이는 생각해 볼 만한 가치가 있는 내용을 보여주기 때문에 저를 당황하게 했습니다. 자율 에이전트가 sudo 프롬프트와 같은 마찰 제어에 도달하고 작업을 완료하기 위한 *다른* 경로가 있는 경우 해당 경로를 택하게 됩니다. 주저하지 말고 "먼저 확인해 보겠습니다."

문제는 더 많은 사람들이 로컬에서 자율 도구를 실행하고 있으며 Codex 자체에서는 WSL을 최고의 Windows 경험으로 권장한다는 것입니다.

따라서 에이전트가 Windows interop에 연결할 수 있는 경우 sudo 암호 프롬프트는 무인 실행 중에 실제로 사용자를 보호하지 않습니다.

실제 신뢰 경계는 Windows 사용자 계정입니다.

더 엄격한 격리를 원할 경우 해당 배포판에 대해 상호 운용성을 비활성화할 수 있습니다.

# /etc/wsl.conf
[상호 운용성]
활성화 = 거짓

이후에 WSL을 다시 시작하세요. 이로 인해 일부 합법적인 작업 흐름도 중단되므로 장단점을 고려하세요.

상담원이 각 단계를 어떻게 추론했는지 정확히 알고 싶은 사람이 있을 수 있도록 전체 세션 로그를 저장했습니다.

누군가에게 도움이 되길 바랍니다.