Arch Linux, 이제 악성코드 사고가 통제됐다고 판단: 1,500개 이상 패키지 영향

 (phoronix.com/news)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Arch Linux의 AUR 사용자 기여 저장소에서 악성코드 감염 패키지가 처음 400개 이상으로 확인된 뒤 최종적으로 1,500개 이상으로 늘어남
  • 몇 시간 전 업데이트에서는 이번 주 사고로 감염된 패키지가 약 900개로 파악됐음
  • 이후 Arch Linux 개발자들은 인지한 악성 커밋을 모두 삭제했으며, 영향받은 패키지 수는 1,579개로 집계됨
  • 1,579개 목록도 영향받은 패키지의 많지만 전체는 아닌 목록으로 표시돼 전체 범위가 더 클 수 있음
  • 사용자 유지 관리 저장소의 많은 소프트웨어가 이번 보안 사고의 영향을 받았으며, 별도 업데이트에서는 더 정교한 악성코드 공격이 다시 발생함

사고 개요

  • Arch Linux 사용자를 위한 AUR 사용자 기여 저장소에서 악성코드에 감염된 패키지가 400개 이상 발견되며 사고가 시작됨
  • 하루가 끝날 무렵 Arch Linux 측은 영향받은 커밋이 모두 처리됐다고 판단했지만, 영향받은 패키지 수는 1,500개 이상으로 늘어남
  • 이번 사고는 사용자 유지 관리 Arch Linux 저장소의 많은 소프트웨어에 영향을 준 보안 사고였음

영향 범위 변화

  • 몇 시간 전 업데이트에서는 이번 주 사고로 약 900개 패키지가 악성코드에 감염된 것으로 파악됐음
  • 이후 보안 사고 스레드의 마지막 메시지 기준으로 Arch Linux 개발자들은 인지한 악성 커밋을 모두 삭제함
  • 인용된 목록은 악성코드 영향을 받은 패키지 수를 1,579개로 표시함

남은 불확실성

  • 1,579개 패키지가 표시된 목록도 “영향받은 패키지의 많지만 전체는 아닌 목록”으로 표시됨
  • 따라서 공개된 숫자는 확인된 대규모 영향 범위를 보여주지만, 목록 자체가 전체 패키지를 포괄하지는 못함

후속 업데이트

  • 별도 업데이트로 Arch Linux AUR이 더 정교해진 악성코드 공격의 또 다른 물결을 맞았다는 내용이 이어짐

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • AUR 팀에서 사후 분석을 낸 적이 있는지 궁금함
    이번 대응은 인상적으로 빨랐지만, 솔직히 AUR 정책이든 래퍼든 변화가 필요해 보임
    pnpm처럼 최소 패키지 나이를 설정할 수 있어야 하고, 고아 패키지를 아무나 입양할 수 있으면 안 됨
    입양에는 전역 속도 제한을 둬서 공격 신호로 삼을 수도 있고, NPM에서 여러 회사가 하듯 게시 시점에 취약점 스캔도 필요함
    다만 이런 변화의 대부분은 AUR 유지보수자보다 패키징 도우미와 제3자가 해야 할 일에 가까움

    • AUR 패키지를 이름공간으로 나누는 편이 더 나음
      그러면 소유권이 사라지지 않아서 고아 처리 자체가 필요 없어짐
    • AUR 저장소를 내려받는 공식 도구는 없으니, 그 부분은 각자 쓰는 방식에 달려 있음
    • pnpm에서 영감을 받아 pakku에 최소 AUR 나이를 두는 패치 [1]를 최근 만들어 봤음
      [1] https://github.com/gavinhungry/patches/blob/main/pakku/pakku...
      [2] https://github.com/zqqw/pakku
    • 고아 패키지 입양을 너무 막으면 제대로 유지보수될 수 있는 것들도 방치될 수 있음
      제한은 필요하지만, 예를 들어 일정 기간 이전에 가입한 사용자에게 월 1개 입양 정도로 제한하는 식이 적당해 보임
      어차피 로컬에 설치된 AUR 패키지에 자동·무검토 업데이트를 적용하는 사람은 없을 테니, 공격면은 이미 꽤 작음
    • 단순 취약점 스캔으로는 못 잡았을 가능성이 큼
      miasma 웜의 핵심이 바로 서명과 도우미 방식이 너무 빨리 바뀐다는 점임
      암호화된 악성 임플란트는 업로드된 GitHub 위치마다 달라지는 AES-128-GCM 키로 페이로드를 복호화하고, 코드의 메서드 이름도 동적으로 바뀌며 암호화된 심볼 오프셋도 섞어 재사용함
      변이형 악성코드라 서명 기반 도구에는 최악의 상대임
      APT28/29는 GitHub에서 C2 인프라로 쓰이는 사용자와 저장소를 Microsoft가 자동 차단하는 속도가 느리다는 점에 어느 정도 의존하는 것으로 보임
      이게 보안 전략에 무엇을 뜻하는지 생각해 볼 필요가 있음
      서명이나 문자열을 스캔할 수 있을 때쯤이면 이미 완전 자동화된 봇넷과 고양이쥐 게임을 하는 단계이고, 이길 수 없음
      지난주 동안 이 임플란트 변화를 따라간 공급망 도구는 socket.dev 정도뿐이었고, 다른 도구들은 Miasma를 알지도 못한 채 새 캠페인으로 재발견했음
      새 생태계용 어댑터가 24시간마다 나오는 속도를 따라갈 만큼 페이로드를 빠르게 역공학할 인력과 도구체인이 부족했음
      여기서 완전 자동화란 다른 패키지 생태계에서 48시간도 안 된 시점에 훔친 자격 증명을 이미 쓰고 있다는 뜻임
      이메일 주소와 이름이 계속 등장하는데, 이 자기 전파 웜의 영향을 이해하지 못했을 가능성이 큰 사람들로 보임
      예를 들어 bun에 의존하는 패키지를 찾는 침해 지표도 큰 도움이 안 됨
      악성코드는 외부 수단으로 다시 내려받으면 그만임
      두 번째 PyPI 캠페인에서는 RedHat 캠페인의 첫 악성 드로퍼 물결이 PyPI 유지보수자에게 표시된 뒤, 압축 WHL 파일과 자동 실행되는 setup.pth 파일로 드로퍼를 내려받도록 바꿨음
      이 생태계들의 패키지 관리자가 chroot, 샌드박스, 네트워크·도메인 로그, 항목별 허용 목록을 전제로 처음부터 다시 작성되지 않는 한, 공급망 공격을 통한 악성코드 배포 전략은 계속 현실적일 것임
      완화 도구 저장소는 [1]이고, 기술적 세부사항은 블로그 글 [2]에 있음
      Composer, Rubygems, NPM, PyPI, Go도 모두 영향을 받는 등 모든 패키지 관리자 전반의 문제임
      패키지 관리자 전반에 얼마나 많은 부주의와 외부 신뢰를 얹고 있는지 더 공개적으로 논의해야 하고, 이건 정말 바뀌어야 함
      [1] https://github.com/cookiengineer/antimiasma
      [2] https://cookie.engineer/weblog/articles/malware-insights-mia...

  • AUR에서 직접 설치할 수 있는 pacman 래퍼가 나오기 시작했을 때 정말 불편했음
    AUR에서 뭔가 설치한 적은 있지만, 대부분은 중간 단계를 건너뛰고 프로젝트 웹사이트로 직접 가는 쪽을 선호함
    미리 만들어진 PKGBUILD가 오타 선점이나 npm·pip 의존성 악용 위험을 감수할 만큼 편리하지는 않음

    • yay 같은 래퍼는 업데이트 때마다 PKGBUILD 차이를 보여줌
      처음 설치할 때 URL을 확인하고 설치 스크립트 등이 타당한지 보며, 이후 업데이트는 대부분 버전 번호와 체크섬만 바뀜
      오타 선점 공격은 꽤 명확하게 드러날 것임
      첫 설치에는 조금 취약하지만, 프로젝트 웹사이트에 가서 다운로드를 누르는 방식도 마찬가지임
    • Arch가 엘리트주의적이거나 일반 사용자를 막는다는 비판을 계속 받지만, 위험한 일을 쉽게 만들지 않는 것에는 분명한 장점이 있음
      삶의 여러 측면에서도 마찬가지임
      Void Linux를 쓰고 난 뒤 Arch에서도 비슷한 분리를 위해 aurutils로 바꿨음
      직접 빌드해 로컬 AUR 저장소를 쉽게 유지하고, pacman으로 설치·관리할 수 있어 전체 업그레이드 과정이 나아짐
    • 이 절충은 나에게는 가치가 없음
      Linux로 옮긴 이유가 Windows 사용자처럼 웹사이트에 가서 “download”를 누르며 프로그램 업데이트에 시간을 낭비하려는 건 아니었음
      다만 언급한 pacman 래퍼들은 위험해 보임
    • AUR과 다른 배포판의 비슷한 저장소들은 정말 무섭게 느껴짐
      이런 저장소를 쓰는 튜토리얼이 너무 널리 퍼져 있어서, 거의 동료 검토도 없는 낯선 사람에게 무기한 root 권한을 주고 싶지 않은 내가 이상한 사람처럼 느껴질 정도임
      업데이트가 필요 없거나 드문 패키지 한 버전을 설치하려고 그런 위험을 감수하는 셈임

  • 빠르게 읽어보니 npm에서 atomic-lockfile, js-digest, lockfile-js를 설치한 것으로 보임
    영향을 받은 패키지 목록은 [1]에 있음
    시스템 확인 방법을 바로 찾지 못해서, 외부 패키지와 날짜 관련 정보를 찾으려고 pacman -Qmi를 실행했음
    출력 결과를 영향 받은 패키지 목록과 대조하면 됨
    또 여러 위치에서 다음처럼 파일을 검색할 수 있음
    grep -rl "atomic-lockfile" / --include="package.json" --include="package-lock.json"
    grep -rl "atomic-lockfile" ~/.npm 2>/dev/null
    grep -i "atomic-lockfile" /var/log/pacman.log 2>/dev/null
    실행 후 패키지가 자신을 삭제하는지는 모름
    다른 정보들이 별 도움이 되지 않아 기본 명령어라도 공유하고 싶었음
    [1] https://md.archlinux.org/s/SxbqukK6IA

    • 내가 한 방식은 이렇음
      yay로 AUR에서 온 설치 패키지 목록을 얻음: yay -Qam > packages_aur.last
      https://md.archlinux.org/s/SxbqukK6IA#에서 목록을 받음: curl https://md.archlinux.org/s/SxbqukK6IA/download > compromised.txt
      그다음 grep -wFf compromised.txt packages_aur.last를 실행하면 두 파일에 모두 있는, 즉 어느 시점에 손상됐던 패키지가 나올 것 같음
    • 공격자는 최소 세 가지 Node 의존성을 사용했으니 atomic-lockfile만 확인해서는 부족함
      js-digest와 lockfile-js도 사용됐고, 어느 시점에는 npm 대신 bun으로 바꿨음
    • 이것도 참고할 만함: https://github.com/lenucksi/aur-malware-check
    • Arch Linux AUR에 악성코드를 넣으려는 상황에서도 악성코드는 여전히 NPM을 통해 배포된다는 점이 웃김
      전설적인 플랫폼임
    • emacs-magit은 어떻게 영향을 받은 건지 모르겠음
      내가 알기로는 JavaScript가 전혀 없음

  • 검토 없이 임의의 서드파티 패키지·라이브러리·애플리케이션을 설치하지 말라는, 늘 그렇듯 공정한提醒가 됨
    다행히 이번 일은 AUR에 국한됐고, AUR은 사실상 누구나 올릴 수 있는 패키지 저장소이며 공식 저장소와 달리 설치 전 검토가 필수라고 여러 번 경고되어 있음
    rua와 비슷한 명령줄 도구들은 AUR에서 설치하기 전에 패키지를 검토하기 쉽게 해 줌
    같은 컴퓨터에서 은행 업무를 한다면 의존하는 소프트웨어를 검토하지 않을 변명은 없음
    패키지 수를 낮게 유지하고 필요한 것만 쓰면 업그레이드할 때도 훨씬 단순해짐

    • “검토”를 어떻게 하라는 건가
      설치하기 전에 코드 한 줄 한 줄을 전부 읽으라는 뜻인가
      바이너리 패키지라면 어떻게 하나
      설치하는 모든 것에 재현 가능한 빌드를 만들라는 건가, 아니면 소스 기반 배포판으로 옮기라는 건가
      이 책임을 사용자에게 떠넘기는 건 지속 가능한 해법이 아님
      상식이 들어갈 여지는 있지만, 이걸 사용자 탓으로 돌리는 건 말이 안 됨
    • 그럴듯하게 들리지만 결국 실행 불가능한 조언이라서, 오히려 무용한 것을 넘어 해로움
      세상에는 한 사람이 평생 읽을 수 있는 양보다 훨씬 많은 코드가 있음
      본인도 자기 컴퓨터에서 현재 실행 중인 소스 코드의 1%도 읽지 않았을 가능성이 큼
      그렇다면 컴퓨터 사용을 멈췄나
      그 안에서 일어나는 일을 어떻게 신뢰할 수 있나
    • “설치 전 반드시 검토하라”는 입장은 다시 평가해야 한다고 봄
      Arch Linux 개발자들은 훌륭한 일을 하고 있고 개인적으로 감사하지만, 공급망 공격이 이렇게 늘어나는 요즘에는 사용자 경고만으로는 이미 오래전에 한계가 왔다고 느낌
      쉬운 해법은 보이지 않지만, 게시 전 동료 검토나 유예 기간 같은 통제가 문제를 어느 정도 완화할 수는 있을 것임
    • AUR은 예전부터 Arch의 큰 장점으로 높게 평가됐지만, 그 편의성에는 대가가 따랐음
      패키지를 고아로 표시하고 2주 기다린 뒤 원 유지보수자가 휴가 중이라 응답하지 못하면, 공격자가 유지보수자로 배정되어 매운 업데이트를 배포할 수 있다는 게 말이 안 됨
    • 불변 시스템 파일, 기본 사용자 로컬 설치, 구성요소와 프로그램에 최소 권한만 주는 조합을 강하게 뒷받침하는 사례라고 봄
      불변 배포판, Wayland, Flatpak에 일부 조각은 있지만 중요한 구멍이 남아 있음
      가장 큰 문제는 샌드박싱이 패키지 형식에 묶여 있다는 점인데, 이건 실수라고 생각함
      샌드박싱과 접근 권한은 시스템 수준의 기능이어야 해서 임의 바이너리도 쉽게 빈틈을 빠져나가지 못해야 함
      문제를 완전히 해결하지는 못해도 피해 범위를 크게 줄이고 배포판 사용자를 덜 매력적인 표적으로 만들 수 있음

  • 걱정되는 사람들을 위해 최신 스크립트와 패키지 목록을 모아 감염 여부 확인에 도움 되는 저장소를 찾았음: https://github.com/lenucksi/aur-malware-check

    • 같은 목록(https://md.archlinux.org/s/SxbqukK6IA)을 Claude에 주고 악성코드 확인을 해 봤는데, 이 스크립트가 하는 것과 본질적으로 같은 검증을 수행했음
      어느 쪽이든 충분할 것 같음

  • Arch Linux 사용자는 아니지만 NodeJS를 많이 쓰는데, 여기도 비슷한 공격을 자주 겪음
    요즘 패키지 관리를 제대로, 안전하게 하는 곳이 어디인지 궁금함

    • AUR은 사용자 지원 기반이라 악성코드가 종종 패키지에 섞여 들어감
      이번처럼 큰 규모는 아니었지만, 애초에 안전하지 않다는 점이 분명했고 곳곳에 위험 경고가 붙어 있었음
    • Linux 배포판들은 잘하고 있음
      모두 패키지를 검토하고 책임지는 유지보수자가 있음
      Arch Linux도 마찬가지임
      AUR의 본질적인 불신뢰성은 Arch Wiki와 주변 문화에서 늘 명시적으로 드러났고, npm이나 pip 같은 프로그래밍 언어 패키지 관리자와는 다름
    • AUR을 쓰지 않으면 Arch는 괜찮음
      AUR을 쓴다면 전부 확인해야 함
      대부분의 배포판도 괜찮고, 큰 배포판들은 꽤 좋은 기록을 갖고 있음
    • Node 생태계에는 특히 취약하게 만드는 뭔가가 있는 것 같음
      지나친 DRY 문화 때문일 수도 있고 다른 이유일 수도 있음
      내가 써 본 것 중 비슷한 수준의 의존성 트리 악몽은 없었음

  • AUR에는 고아 패키지 1만 5천 개가 있음
    오늘 아침 인기순으로 정렬해서 거의 업데이트되지 않는 3개를 입양해 빌드했음
    고아 패키지를 쓰고 있다면 나쁜 사람들이 가져가기 전에 직접 입양하는 걸 고려해 볼 만함

  • 틀릴 수도 있지만, 이번 상황은 데스크톱 Linux 채택 증가의 신호처럼 보임

  • AUR이 필요했던 적이 없음
    공식 저장소에 없는 패키지가 필요하면 직접 빌드하거나, 바이너리 릴리스가 있으면 내려받음
    이렇게 하면 빌드할 때 root를 쓸 필요가 없고, 프로그램을 단일 사용자용으로 로컬 설치할 수 있어 대부분의 데스크톱 사용 사례에는 오히려 맞는 방식임
    최소한 개발자 → 사용자 경로에 비해 개발자 → 유지보수자 → 사용자라는 한 단계의 악성 코드 삽입 가능성이 줄어듦

    • makepkg는 root로 실행하면 적극적으로 거부함
      굳이 env EUID=123 makepkg ... 같은 식으로 우회하지 않는 한 root로 돌지 않음
      다만 pacman이 사용자 수준 설치를 지원하면 좋겠음
      현재는 root가 아니면 설치를 거부하고, 사용자 이름공간으로 자신을 root에 매핑하는 식으로 우회할 수는 있음

  • 이번이 AUR이었다는 건 이해함
    AUR 여부와 관계없이 패키지를 설치할 때 어떤 단계를 거치는지, 설치하려는 패키지와 의존성이 악성코드가 아님을 어떻게 보장하는지 공유해 주면 좋겠음
    나쁜 패키지를 설치하고 나면 정말 되돌리기 어려워 보임

답변달기