On the (In)Security of Loading Machine Learning Models

논문 개요: 기계 학습 모델 로딩의 (불)안정성

이 논문은 공유된 기계 학습 (ML) 모델을 로드할 때 발생하는 보안 위험을 체계적으로 분석합니다. 저자들은 모델 공유 플랫폼과 프레임워크가 제공하는 '보안' 기능이 실제로 얼마나 안전한지, 그리고 사용자들이 이러한 보안 내러티브를 어떻게 인식하는지 조사하여, 현재 ML 생태계의 보안 상태가 해결된 문제가 아니며 심각한 취약점이 존재함을 증명합니다.

1. 문제 정의 (Problem)

• 배경: 모델 공유 허브 (Hugging Face 등) 와 프레임워크의 발전으로 ML 모델 접근성이 높아졌으나, 공유된 모델을 로드하는 과정의 보안 위험은 충분히 연구되지 않았습니다.
• 핵심 위협: 공격자가 악성 모델 아티팩트를 제작하여 로드 시 사용자의 시스템에서 임의 코드 실행 (Arbitrary Code Execution, ACE) 을 유도하는 공격.
• 연구 질문 (RQ):
  1. 주요 ML 프레임워크와 허브의 모델 공유 메커니즘 보안 태도는 어떠한가?
  2. '보안 지향적'이라고 주장하면서도 완전한 모델 객체 공유를 지원하는 방식은 실제로 안전한가?
  3. 사용자의 보안 인식은 현실과 일치하는가, 아니면 프레임워크/허브의 마케팅 내러티브에 의해 왜곡되는가?

2. 연구 방법론 (Methodology)

저자들은 세 가지 주요 연구 질문에 답하기 위해 다음과 같은 방법론을 적용했습니다.

• 시스템 분석 (RQ1): TensorFlow, Keras, PyTorch, scikit-learn, XGBoost 등 주요 5 개 프레임워크와 Hugging Face, Kaggle, PyTorch Hub 등 5 개 주요 허브의 공식 문서를 분석하여 모델 직렬화 (Serialization) 및 로드 메커니즘을 분류했습니다.
  • 분류 기준: 데이터 기반 (JSON 등) vs 코드 기반 (Pickle 등), 자기 완결형 (Self-contained) vs 비자기 완결형 (Non-self-contained).
• 취약점 분석 및 0-day 발견 (RQ2): '보안 지향적'이라고 명시된 기능 (Keras 의 safe_mode, scikit-learn 의 Skops 등) 을 대상으로 수동 리버스 엔지니어링을 수행하여 0-day 취약점을 발견하고 이를 CVE 로 등록했습니다.
• 허브 스캐너 평가: Hugging Face Hub 에 통합된 보안 스캐너 (ClamAV, Picklescan, Protect AI, JFrog) 가 발견된 취약점 기반의 악성 모델을 탐지하는지 실험했습니다.
• 사용자 인식 조사 (RQ3): ML 실무자 62 명을 대상으로 설문을 진행하여, 보안 플래그 (예: safe_mode, weights_only) 와 허브의 보안 라벨이 사용자의 안전감에 미치는 영향을 정량화했습니다.

3. 주요 기여 및 발견 (Key Contributions & Results)

A. 프레임워크 및 허브의 보안 태도 분석

• 많은 프레임워크와 허브가 보안을 부분적으로만 다루거나, 책임을 사용자에게 전가하는 방식을 취하고 있습니다.
• 데이터 기반 형식의 오해: JSON 기반 형식 (Keras .keras, Skops) 이 Pickle 과 같은 코드 기반 형식보다 본질적으로 안전하다는 통념이 깨졌습니다. 실제로는 JSON 이 실행 가능한 코드를 표현하는 방식으로 사용되어 취약점이 발생합니다.

B. 0-day 취약점 발견 (6 건)

'보안 지향적'이라고 주장하는 메커니즘에서 임의 코드 실행을 가능하게 하는 6 가지 0-day 취약점을 발견했습니다.

1. Keras safe_mode 우회 (CVE-2025-1550, CVE-2025-8747, CVE-2025-9906):
   • config.json 내 모듈 해석 로직 결함으로 subprocess.run 등 악성 함수 실행 가능.
   • Lambda 레이어를 이용한 코드 재사용 (Code Reuse) 으로 safe_mode 비활성화 및 코드 실행 가능.
   • 레거시 HDF5 포맷 로드 시 safe_mode 플래그가 무시되는 침묵 우회 (Silent Bypass) 발견.
2. Skops 취약점 (CVE-2025-54413, CVE-2025-54412, CVE-2025-54886):
   • MethodNode 및 OperatorFuncNode 를 통한 객체 그래프 탐색 및 __builtins__ 접근으로 코드 실행 가능.
   • 모델 카드 생성 시 유효한 ZIP 이 아닌 파일에 대해 joblib (Pickles) 로 자동 폴백되어 보안 체크가 우회됨.

C. 허브 스캐너의 한계

• Hugging Face 에 통합된 보안 스캐너들은 발견된 0-day 취약점 기반의 악성 모델을 탐지하지 못했습니다.
• 특히 .skops 포맷은 어떤 스캐너에서도 지원되지 않아 'Safe'로 잘못 표시되는 경우가 발생했습니다.
• 오히려 정상적인 Lambda 레이어를 가진 모델을 'Unsafe'로 오진하는 False Positive 가 빈번하게 발생했습니다.

D. 사용자 인식 조사 결과

• 보안 내러티브의 영향: safe_mode=True 또는 weights_only=True 와 같은 보안 플래그가 활성화되면 사용자의 안전감이 통계적으로 유의미하게 증가했습니다.
• 위험 인식 저하: safe_mode가 켜진 경우, 사이버보안 전문가가 아닌 사용자의 90% 이상이 임의 코드 실행 위험을 고려하지 않았습니다.
• 허브 신뢰: Hugging Face 와 같은 보안 스캐너가 있는 허브를 사용하면 사용자의 편안함이 크게 증가하는 것으로 나타났습니다.

4. 의의 및 시사점 (Significance & Takeaways)

1. 파일 형식의 환상 깨기: JSON 과 같은 데이터 기반 형식이라도 모델 로딩 과정에서 코드로 해석되면 Pickle 과 동일한 위험을 가집니다. **"모델은 코드 (Models are Code)"**라는 인식이 필요합니다.
2. 보안과 유연성의 트레이드오프: 완전한 보안을 위해서는 허용 목록 (Allowlist) 이나 제한된 연산자 (ONNX 등) 사용이 필요하지만, 이는 모델의 유연성과 사용성을 희생시킵니다.
3. 레거시 지원의 위험: 하위 호환성을 위해 레거시 포맷 (HDF5, Pickle) 을 계속 지원하면 새로운 보안 메커니즘이 무력화됩니다.
4. 스캐너의 한계: 자동화된 모델 스캐너는 첫 번째 방어선일 뿐이며, 지원되지 않는 포맷에 대해서는 오히려 잘못된 안전감을 줄 수 있습니다.
5. 커뮤니티 제언:
   • 개발자: '안전 (Safe)'이라는 용어의 남용을 자제하고, 레거시 옵션은 명시적 경고와 함께 제공해야 함.
   • 사용자: 보안 플래그나 허브 라벨을 맹신하지 말고, 공유된 모델을 실행 가능한 코드로 간주하여 경계해야 함.

결론

이 연구는 ML 모델 공유 생태계의 보안이 해결된 문제가 아님을 강력하게 증명합니다. 프레임워크와 허브가 제공하는 보안 기능은 종종 허위 안전감을 조성하며, 실제로는 0-day 취약점이 존재합니다. 진정한 보안을 위해서는 파일 형식이나 스캐너에 의존하기보다, 모델을 실행 가능한 코드로 취급하고 책임 있는 공유 문화를 정착시키는 것이 필수적입니다.