vLLM의 eval() RCE 사례로 본 악성 LLM 출력의 추론 호스트 공격면

에이전트 하네스가 격리를 책임진다는 전제부터 틀렸다고 봄. VM이나 컨테이너로 분리하고, 에이전트는 그 안에서 root 권한으로 뭘 하든 상관없게 만들어야 함.

글은 에이전트 격리 얘기가 아니라, 악성 모델의 출력 토큰이 추론 엔진을 공격해 GPU 호스트를 뚫는 경우를 말하는 거임.

프런티어 모델 추론은 보통 여러 GPU 클러스터에서 돌아가고, 공개 API용 JSON 파서는 추론 서버와 다른 장비에 있을 가능성이 큼. 배치 처리도 해야 하니 글이 가정한 단일 호스트 경계는 너무 뭉뚱그렸다고 봄.

그래도 Ollama로 Qwen 같은 모델을 단일 GPU에서 돌리는 로컬 호스트는 무시하면 안 됨. 공격할 가치가 있는 표적은 그런 장비도 많을 수 있음.

macOS 자체 샌드박싱은 괜찮은 편인데 LM Studio, Ollama, Darkbloom은 샌드박스 안에서 돌지 않음. 그래서 Mac App Store 배포도 못 하는 경우가 있음.

글이 말하는 건 공급자 모델 가중치가 사용자 호스트에 올라간다는 얘기가 아님. 로컬 가중치를 vLLM 같은 도구로 돌리거나 자체 데이터센터를 운영하는 경우의 공격면임.

터미널 이스케이프 시퀀스도 생각해볼 만함. 터미널 에뮬레이터 취약점으로 VM 경계를 넘어 호스트까지 갈 가능성을 걱정해야 함.

ANSI 파서는 샌드박스 프로세스로 떼고, 기본 서식만 남긴 뒤 Sixel 같은 특수 이스케이프는 제거하는 쪽이 낫겠음. 터미널 이스케이프 주입 CVE도 이미 많았음.

추론 엔진이 실행하는 건 아니고 명령을 실행하는 건 에이전트 루프인데, 그래서 호스트 장악까지 간다는 설명이 어색함.

아니, 요점은 모델이 내부에서 vLLM 같은 추론 엔진을 해킹하는 거임. 파서나 토크나이저, API 입력 처리 버그가 RCE로 이어질 수 있는 일반적인 공격면임.

무작위 모델을 내려받아 실행할 때 조심해야 한다는 얘기임. 악성 PDF를 Acrobat으로 열면 뚫리던 것과 같은 종류이고, 악성 모델 출력이 파서를 찌르는 문제는 놀랄 일이 아님.

스트리밍 토큰에 호스트 장악 기회를 주는 구현은 매우 허술한 거고, 인용한 CVE가 그 증거임. 가중치도 TEE를 쓰면 메모리에서 암호화할 수 있어서 쉽게 읽힌다는 주장에는 동의 못 함.

추론 엔진의 복잡성과 빠른 개발 주기가 공격면을 늘리는 건 맞지만, 글은 아직 가상 공격 시나리오에 가까움. GPU와 파서를 분리할 수는 있어도 대형 클러스터에서는 구성요소 경계가 흐려져 구현이 쉽지 않음.

우리는 vLLM을 방화벽 VLAN 안의 별도 샌드박스 VM에서 돌림. DNS와 AD/LDAP는 막고, 외부 캐시에서 업데이트와 모델을 넣으며, 로그와 텔레메트리는 다른 격리 서브넷 VM으로만 보냄.