skrkcb2/cve-2024-5452CVE-2024-5452에 대한 상세한 기술 분석: DeepDiff 델타 속성 오염을 통해 PyTorch Lightning에서 발생하는 원격 코드 실행 취약점, 개념 증명 및 완화 가이드 포함.
RCE(Remote Code Execution, 원격 코드 실행)는 공격자가 원격에서 시스템이나 애플리케이션 내에서 임의의 코드를 실행할 수 있도록 하는 취약점 이며 CWE-94: Improper Control of Generation of Code ('Code Injection') 입니다.
PyTorch Lightning은 PyTorch 기반의 딥러닝 모델 훈련을 쉽게 관리할 수 있도록 도와주는 라이브러리 이며 DeepDiff는 두 개의 Python 객체를 비교하여 차이를 분석하는 라이브러리 입니다.
CVE-2024-5452는 Lightning의 AI 모델 가중치 관련 웹 애플리케이션 기능에서 DeepDiff와 Lightning을 활용하는 과정에서 DeepDiff의 취약한 헤더 검증 과 델타 속성 오염을 통하여 역직렬화 시 RCE를 일으키는 취약점 입니다.
이로 통해 공격자가 임의의 객체를 주입하거나 원격 코드 실행(RCE)을 수행할 수 있는 취약점이 발생하는 코드 흐름을 살펴보고, 이에 대한 대응 방안을 모색 해보겠습니다.
pytorch-lightning 에서 웹 애플리케이션 소스의 DeepDiff 엔드 포인트 중 /api/v1/delta 에 delta의 속성을 오염시켜 보내어 공격 할 수 있습니다.
예제를 살펴 보며 delta의 dunder속성 오염 시켜 어떻게 객체 역직렬화 취약점이 유발 되는지 알아보고자 합니다.
첫 요청은 Client 공격예제, 오염 설정 -> Deepdiff의 /api/v1/delta에서 취약한 헤더 검증 -> 오염 설증을 통한 상태 저장 입니다.
[그림 1] POC - Endpoint 공격
[그림 2] POC - Vuln Injection / 전체 오염 설정 내용
[그림 3] lightning/api/core/api.py / 취약한 헤더 검사 로직 파트
[그림 4] lightning/api/core/app.py / 설정 구간
[그림 5] lightning/api/core/app.py / 설정 저장 구간
첫번쨰 요청은 [그림 3]의 /api/v1/delta의 header 검증을 [그림 1]를 통해 우회 후 조작한 오염 설정(delta) [그림 2]를 주입 시키고 [그림 4],[그림 5] 를 통하여 설정을 저장 시킵니다. 그럼 이제 두번째 요청에서 이 조작 한 델타의 설정들이 어떻게 작용 하는지 살펴 보겠습니다.
[그림 6] lightning/api/core/app.py / 초기 경로 흐름
[그림 6]은 델타가 설정 된 후 두번 째 요청 흐름이며 run_once() -> maybe_apply_change() -> _collect_deltas_from_ui_and_work_queues() 
[그림 7] isinstance 오염 케이스
[그림 7] _collect_deltas_from_ui_and_work_queues()에서의 isinstance 검사를 오염된 설정으로 통과(isinstance(delta, _DeltaRequest) == False)시켜 else로 동작한다. 
[그림 8] isinstance 오염 케이스 1
[그림 8] 이해를 돕기 위해 isinstance(delta, _DeltaRequest), delta, _DeltaRequest(타입)의 결과를 출력 첫번째 요청은 설정을 위한 요청으로 변조를 세팅중 이여 정상이고 다음 요청은 _DeltaRequest타입이 str로 오염되어 조건을 우회 하고 있다. 흐름 상 다음 타겟인 _process_requests의 예시를 보겠습니다. 
[그림 9] isinstance 오염 케이스 2
[그림 9] 를 보다시피 위와 동일한 내용으로 _process_requests는 오른쪽 클라이언트 POC코드의 세팅 으로 isinstance(request, _APIRequest)의 검사를 오염된 설정으로 통과 하였습니다, 해당 오염은 str을 OrderSet 인스턴스에 대해 isinstance 호출이 참을 반환 하는 케이스 입니다. 현재 까지 2가지 형태의 isinstance 오염을 봤는데 이후의 상황 은 오염을 통해 속성들을 호출 할수 있게 설정을 제작 합니다. 
[그림 10] isinstance 오염 케이스 3
[그림 10] 의 isinstance 우회, 함수 설정이 끝나고 [그림 10]의 "내부 상태 고정"(_INTERNAL_STATE_VARS: ()을 비워 둠)을 설정하여 [그림 11]에서 내부 설정 상태를 검수 할수 없게 만듭니다. 
[그림 11_1] /lightning/app/core/flow.py 의 _INTERNAL_STATE_VARS 체크 함수
[그림 11_2] /lightning/app/core/flow.py 의 __setattr__
[그림 11]을 마지막 으로 전체적인 오염 및 설정은 끝났습니다.
[그림 12] RCE Commnad
[그림 13] RCE Response
최종적으로 [그림 13] 에서 root 권한의 exec를 call해서 [그림 12]의 커맨드를 실행하여 마무리 합니다
지금까지 lightning환경에서 객체 역직렬화(CVE-2024-5452)를 통한 RCE 취약점이 수행되는 흐름을 확인 해봤습니다. 서버 자체가 탈취 당하는 공격 방식이기에 대응 방안이 중요합니다. 이를 위해 최신 버전 업데이트 제시 하고자 합니다.
지금까지 Lightning과 Deepdiff 를 통한 Dunder 속성을 오염시켜 RCE를 발생 시키는 취약점을 알아 봤습니다. 해당 취약점은 첫번째로 취약한 헤더 검증, 다음으로는 취약한 delta의 속성 검사 를 통한 객체 역직렬화 에서 일어나는 취약점 이였습니다.
(poc) https://security.snyk.io/vuln/SNYK-PYTHON-PYTORCHLIGHTNING-7218866
(nist) https://nvd.nist.gov/vuln/detail/CVE-2024-5452
