XZ_utils Respond

개요

요즘 보안에 관한 이슈들중 리눅스 해킹에 대한 뉴스를 접하였다.
그중 여러가지 보안 이슈가 있었지만 최근의 Xz_utils라는 사건에 대해 알아보자.

XZ_utils란?

일단 xz utils가 무엇인지 찾아보았다. 2005년 Slackware라는 리눅스 배포판의 포크인 Tukaani리눅스의 배포를 위한 그룹이라고 생각되는데 정작 Tukaani리눅스는 나온적이 없다.
이 그룹의 목표는 리눅스 배포를 700MB로 압축하는 것이었고 gzip대신 LZMA가 압축률이 높아서 LZXA로 700MB로 압축할수 있게 된다. Slackware는 .tar.gz의 약어인 .tgz파일로 배포하고 있었는데 LZMA를 쓴 경우에는 .tar.lzma의 약자로 .tlz를 사용하게 되었다.

Tukaani 프로젝트는 멈췄지만, LZMA Utils개발은 계속 진행되었고 Slackware기반 일부 배포판 에서는 여전히 LZMA를 사용하고 있었다. 이 LZMA Utils에는 lzmash라는 쉘 스크립트와 lzmadec라는 디코더 CLI가 포함되어 있었는데 이는 Lasse Collin이라는 개발자가 작성하였다. 개발이 진행되면서 새 포맷을 만들게 되었지만 만드는데 시간이 꽤 걸리게 되어 기존 .lzma파일 확장자를 쓸수 없게 되자 .xz파일 확장자를 쓰기로 하고 2008년 12월에 드디어 릴리스 하게 된다.

새로운 LZMA Utils의 핵심은 liblzma라이브러리 였지만 프로젝트 이름을 LZMA Utils에서 XZ Utils로 바꾸게 된다. XZ Utils는 압축률이 높았기 때문에 다양한 리눅스 배포판에 포함되기 시작하고 Fedora, ubuntu, Debian, Redhat,Kali Linux등 대부분의 배포판에 포함되어 기본 유틸리티로 사용하게 된다.
이렇게 수많은 배포판에 기본 유틸리티로 쓰이는 압축 라이브러리가 되었지만 , XZ Utils를 만든 Lasse Collin가 2007년부터 2022년까지 혼자서만 이 프로젝트를 유지보수 하였다.

이때 문제가 발생하였다. 악의적이게도 사회공학적인 공격을 진행하였는데, 다음과 같다.
2021년 JiaTan이라는 사람이 jiaT75라는 Github계정을 만들고 libarchive라는 저장소에 PR를 날린다.
xz-utils의 메일링 리스트에 Jia Tan이 패치를 제출한다.
Jigar Kumar라는 사람이 나타나서 이 패치를 병합해야 한다고 압력을 가한다. 이 jigar Kumar라는 사람은 누군지 모른다
이 Jigar Kumar는 Lasse Collin에게 혼자만 작업을 하는 실정이니 다른 메인테이터가 필요하다고 압박을 가한다.
Dennis Ens라는 사람도 비슷한 레파토리로 압박을 가한다.
이후 Jia Tan은 xz에 커밋을 또 올리게 되고 이후 메이테이너가 된다.
2022년부터 활발하게 컨트리뷰터가 된 것을 확인할 수 있다.
이시점 어느정도부터 git.tukaani.org와 Github의 xz저장소가 같이 올리게 된다.
2023년이 되면서 Jia Tan은 완전한 신뢰를 얻게 되고 3월에는 기본 연락처가 Lasse Collin에서 Jia Tan으로 바뀐다.
프로젝트에 백도어를 심는 커밋을 추가하고 5.6.0을 릴리즈 한다. 의도적으로 모든 tarball백도어를 심은 것은 아니고 타겟팅한 시스템의 tarball에만 심었다.
이 백도어로 인해서 valgrind에러가 발생하자 백도어는 남겨둔 채 이 에러를 우회한 5.6.1을 릴리스 한다.

Andres Freund라는 개발자가 ssh 접속시 CPU사용률이 비정상적으로 높다는 것을 확인하면서 발견이 되었다.
그는 리포팅을 통해 단순히 sshd의 속도가 느리다고만 리포팅 한것이 아니라 XZ utils가 원인이었고, 여기에 백도어가 숨겨져 있다고 첫 리포트에 분석까지 다 해버린 것이다.

신기한 점은 그가 리눅스를 관제하는 개발자가 아니고 Microsoft의 개발자라는 것이다. 또한 XZ유틸즈는 오픈소스 중에서도 가장 신뢰받는 프로젝트 중 하나였다는 것이다.
이번공격은 백도어를 여는 악성코드를 테스트코드인척하고 빌드가 될때 악성코드가 tarbal에 추가되는 구조로 되어 있고 glibc를 사용하는 amd64리눅스에만 포함되도록 만들어졌다.
모든 아키텍처에 집어넣으면 들킬 확률도 높아지기에 64비트 기반에만 집어넣은것 같다. 이번 백도어는 sshd를 이용한 것이므로 인증을 우회해서 서버에 접속할 수 있거나 원격코드를 실행할 것으로 보인다. CentOS를 관리하는 레드햇은 문제가 된 백도어에 취약점 CVE-2024-3094 라는 식별 번호를 부여했다. 그리고 CVSS 기준 10점 만점에 10점이라는 점수를 매겼다.
일단 대부분의 프로젝트는 glibc를 사용하지는 않을것 같았지만 xz커널에 대한 이슈는 amd64, 데비안 계열인 우분투에도 있기 때문에 빠르게 대응을 할 필요가 있었다. 현재는 코인프로젝트에 대한 인프라를 주로 다루고 있긴 하였지만 나머지 프로젝트들도 모두 데비안 계열을 사용중이기에 빠르게 xz의 버전을 체크해 주어야 했다.

리눅스 해킹에 대한 대응 절차

현재 해커가 백도어를 심어놓은 xz버전은 5.6.0, 5.6.1 버전이므로 그보다 높은지 빠르게 체크를 해주었다.

• Koin DataBase Server
  

• Koin Production Server
  

• Koin Stage Server
  

• BCSD Build Server
  

• BCSD Internal Server
  

• JJbaksa Production Server
  

• JJbaksa Stage Server
  

다행히 현재 동아리 내에서 우분투 서버는 최근의 xz 해킹에서 영향을 받지 않았다.
물론 기타 호환을 위해 apt update/upgrade를 한 적은 없지만 서버를 관리하는 백엔드 인원들에게는 주간회의에 꼭 공지를 하여야 할 것 같다.

회고

개인적으로 리눅스를 좋아하는 사람으로서 뭔가 오픈소스의 생태계에 대해 다시한번 경각심을 가지게 되었다. 이렇게 대부분이 사용하는 서버의 os가 무료로 메인테이너들이 관리하며 지속이 되고 있음에 감사함을 느꼈고, 최근의 DB서버 증설 당시 우분투가 마냥 좋고 익숙하여 서버의 OS로 채택하였는데, 모든지 조심스럽게 알아보고 해야할것 같다.

수많은 의존성을 가진 오픈소스를 사용하고 있지만 개발자가 직접 사용하는 유명한 프로젝트나 모던한 프로젝트에만 관심을 두지(ex- 우아한xx코x에서 Tomcat의 컨트리뷰터가 되는것이 트렌드가 되었다고 들었다.) 그 뒤에 있는 많은 프로젝트에는 관심을 가지지 않는다. 특히 이번의 XZ Utils와 마찬가지로 오픈소스에서는 그중 어떤 의존성은 한명의 메인테이너에게 완전히 의존하고 있어서 그 사람이 지치거나 더는 작업을 할 수 없게 되었을때 전체 의존성이 깨질수 있음을 지적한 것이다.
물론 백도어 오픈소스의 배포가 워낙 최근의 배포판이기도 하고, 대부분은 이 백도어를 가지고 있지 않겠지만 어느정도의 대책이 필요하다고 생각이 든다.
그나마의 해결책을 생각해보자면 최근 도입을 시도중인 도커라이즈를 통해 특정 os에 종속되지 않는 시스템을 구축하는게 좋겠다는 생각을 하였다.

출처:
https://blog.outsider.ne.kr/1714
https://m.boannews.com/html/detail.html?idx=128442
https://ko.wikipedia.org/wiki/XZ_Utils_%EB%B0%B1%EB%8F%84%EC%96%B4
https://m.boannews.com/html/detail.html?idx=128372