OpenEXR, EXR 파일 읽기 관련 취약점 15건 수정

OpenEXR 라이브러리 개발진이 10월 31일 패치 릴리스 3.5.3을 공개했다. 이 릴리스는 취약점 15건을 수정했으며, 그중 10건은 아직 CVE 번호 부여를 기다리고 있다. 거의 전부가 손상되거나 의도적으로 조작된 EXR 파일을 읽을 때 발동한다. 버퍼 오버플로와 할당된 메모리 범위를 벗어난 쓰기다. 릴리스 작성자들에 따르면 이 가운데 몇 건은 원격 코드 실행을 허용했다.

스튜디오에는 구체적인 위험이다. EXR 시퀀스는 외주 업체, 클라이언트, 외부 아카이브, 파일 공유 서비스에서 들어오며 보통 별도의 검사 없이 열린다. 공격이 성립하려면 파일을 실행할 필요도 없다. 취약한 버전의 OpenEXR을 기반으로 한 프로그램이 그 파일을 읽으려 시도하기만 하면 된다. 같은 날 3.5.3보다 조금 앞서 이전 브랜치용 3.4.17 버전이 나왔다. 이 버전은 3.4 브랜치에 해당하는 취약점 9건을 수정하므로, 3.4 사용자는 3.5로 옮기지 않고도 업데이트할 수 있다.

어디에 결함이 있었나

수정 목록은 EXR이 메모리로 들어가는 거의 모든 경로를 아우른다.

DWAA/DWAB 압축: 디코더의 메모리 범위 밖 쓰기, 압축 스트림이 짧을 때 초기화되지 않은 데이터 유출, 서브샘플링된 채널에서의 널 포인터 접근을 포함한 5개 항목;
B44 압축: 압축 해제된 블록 크기를 계산할 때의 오버플로로, 작성자들이 원격 코드 실행 가능성으로 명시한 항목, 그리고 서브샘플링 시 인코더의 결함;
deep 이미지: ZSTD로 압축된 deep 데이터를 풀 때의 결함 2건과 타일 방식 deep 파일을 다시 저장할 때의 오버플로. 후자는 개발진의 평가에 따르면 과거 결함을 불완전하게 고친 결과일 수 있다;
HTJ2K: 디코딩 중 잘못된 메모리 접근;
멀티파트(multipart) 파일: 크기 제한이 없는 헤더 때문에 프로그램이 시간과 자원을 제곱에 비례해 소모하며 헤더를 파싱하게 될 수 있었다;
OpenEXR Python 모듈: 두 RGB 채널 그룹의 이름이 일치할 때의 버퍼 오버플로, 그리고 구형 채널 읽기 인터페이스에서 공격자가 선택한 오프셋으로의 쓰기;
헤더 속성: 채널 이름이 31바이트보다 길 때 이미 해제된 메모리에 접근하는 문제, 그리고 검증되지 않은 추가 채널 목록으로 인한 오버플로.

개발진이 원격 코드 실행과 직접 연결한 결함은 릴리스 노트에 이렇게 기술돼 있다.

«B44 블록의 압축 해제 크기 계산 시 정수 오버플로로 인한 힙 범위 밖 쓰기 — OpenEXRCore에서의 원격 코드 실행».

3.5.3에는 새 기능이나 다른 동작 변경은 없고, deep 이미지 관련 리그레션 수정(아래 참조)만 포함됐다. 사용자가 체감할 변화가 하나 더 있다. 라이브러리가 이제 입력 데이터를 더 엄격하게 검사하고 올바르지 않은 파일을 거부한다. 메모리 처리 오류, 정의되지 않은 동작, 스레드 경쟁을 잡아내는 디버그 검사 아래에서 전체 테스트 세트가 이제 오류 없이 통과한다. 전체 변경 목록은 CHANGES.md 파일에 있다.

릴리스에 함께 들어간 내용

빅엔디언 시스템에서의 deep 이미지 읽기. 3.4.14 버전 이후 그런 머신에서는 바이트 순서 오류로 라이브러리가 잘못된 샘플 개수 테이블을 받았다. 리틀엔디언 시스템은 이 문제의 영향을 받지 않았다. 이 수정은 3.4.17에도 들어 있다.
Python 3.15 지원 — 최신 인터프리터로 파이프라인 스크립트를 작성하는 사용자를 위한 것이다.
exrmetrics, exrmultipart, exrcheck 유틸리티가 주요 압축 해제 경로와 마찬가지로 진단 및 정확성 수정을 받았다. 이 수정의 작성자는 Alex Khal이다.
플랫폼. 32비트 Linux(i686)와 s390x에서의 오래된 빌드 및 테스트 오류, 10.15 미만 macOS와 powerpc에서의 빌드 문제, Windows 7에서의 실행 문제가 수정됐다.

누가 얼마나 급히 업데이트해야 하나

취약점 구성으로 보면 문제의 대부분은 오래전부터 존재한 코드에 있다. 15개 항목 중 ZSTD 압축과 관련된 것은 두 건뿐이다. ZSTD는 9월 3.5.0 출시와 함께 3.5 계열에 등장했고, 당시 가장 큰 이점은 deep 데이터에서 나타나 파일이 ZIPS보다 20~30% 작아졌다. 나머지 결함은 DWA, B44, 타일 방식 deep 파일, 헤더 파싱, Python 모듈에 해당한다. 그래서 새 압축 형식을 쓰지 않는 선택은 별 도움이 되지 않을 것이다. 렌더와 컴포지트가 오래전부터 거쳐 온 라이브러리 부분도 취약했기 때문이다.

deep 이미지 리그레션은 좁은 범위의 머신에만 해당한다. x86과 ARM 기반의 일반적인 워크스테이션은 리틀엔디언으로 동작해 이 문제를 느끼지 못했다. 이 수정은 서버용이나 비교적 드문 하드웨어용으로 OpenEXR을 빌드하는 쪽에 더 중요하다.

대다수 아티스트는 OpenEXR을 직접 설치하지 않는다. 이 라이브러리는 DCC 패키지, 컴포지팅 프로그램, 렌더러, 뷰어 개발사가 자체 빌드에 내장한다. 수정이 작업 현장에 도달하는 것은 이들 벤더가 업데이트를 내놓은 뒤이며, 릴리스 자료에는 시기가 명시돼 있지 않다. 직접 움직일 수 있는 쪽은 OpenEXR Python 모듈 기반의 자체 도구나 라이브러리 자체 빌드를 보유한 파이프라인 TD와 스튜디오다. 이들은 3.5.3이나 3.4.17로 우선 옮기는 것이 좋으며, 특히 그 도구가 외부에서 온 파일을 처리한다면 더욱 그렇다.

외부에서 온 EXR 파일은 주로 어디에서 들어오나?