당분간 새 소프트웨어를 설치하지 않는 게 좋을지도 모릅니다

• copy.fail 이후 Linux 커널 취약점이 추가로 발표됨
• 현재는 NPM 공급망 공격이 큰 피해를 내기 좋은 시점으로 평가됨
• 배포판이 제공하는 Linux 커널 패치는 예외로 두는 권고가 있음
• 그 외에는 약 일주일 정도 새 소프트웨어 설치를 중단하는 편이 좋음
• 게시 이후 사실관계나 상황이 달라졌을 수 있어, 잘못되었거나 불명확해 보이는 부분은 결론 전에 연락해 달라는 단서가 붙어 있음

[GN⁺]

Hacker News 의견들

• 이건 늘 터질 수밖에 없던 악몽이었음. 패키지 수가 너무 많고 그만큼 공급망 공격 표면이 거대해진 게 언젠가 모두에게 터질 문제였음
  하지만 너무 편리했음. 경고하거나 피해를 줄이려는 사람들은 다른 방식으로 해본 경험이 없는 사람들에게 묵살됐고, "import antigravity"는 포기하기엔 너무 쉬웠음
  이제 “대가를 치르는” 단계에 들어선 듯함

  • 한 회사에서는 정말 보수적으로 운영했음. 모든 외부 구성요소는 버전이 고정됐고, 검토 없이 업데이트하지 않았으며 보통 충분한 안정화 기간을 거쳤음
    컴파일러, 커널 등을 포함해 거의 모든 것을 소스에서 빌드했고, 빌드 서버/인프라는 인터넷에 전혀 접근할 수 없었으며 변경을 들여오는 절차도 있었음. 관련 CVE는 공개될 때마다 검토해서 우리에게 해당하는지, 어떻게 완화하거나 처리할지 판단했음
    이후 옮긴 회사에서는 빌드가 인터넷에 접근했고, 새 버전이 나오자마자 업그레이드했음. 최신 버그 수정을 받는다는 이유로 사람들이 이를 좋은 관행으로 여겼고, CVE 검토는 보안팀이 맡았음
    그다음 스타트업은 여러 관행이 섞여 있었음. 아주 좋은 부분도 있었지만 CVE 부채도 컸음. 예를 들어 서버에 보안 부팅과 암호화 디스크를 적용했고, 구성요소 간 통신 보안도 꽤 잘 파악하고 있었음
    모두가 자신들이 옳게 하고 있다고 생각함. “자주 업그레이드하는” 사람에게 새 문제를 도입할 위험이 있다는 점을 설득하기가 거의 불가능함. 업계에는 더 나은 관행 묶음이 필요하고, 개인적으로 첫 번째 회사의 의존성 관리 방식이 더 낫다고 봄. 전반적으로 보안 관행이 잘 자리 잡았고 제품도 정말 안전했음
  • 판도라의 상자를 여는 셈 치고, 이런 알려지지 않은 공격 벡터를 모두 드러내는 순효과가 전 세계 정보기관의 비축 취약점을 비우는 것이라면 어떨까 싶음
    유용한 소프트웨어가 모두 퍼징 테스트, 속성 테스트, 형식 검증을 거친 상태가 되어, 취약점을 찾는 모두가 처음부터 다시 시작해야 하는 상황이 되는 것임
    물론 그 사이 각국이 남은 수단을 최악의 적에게 던져대는 공백기를 우리가 버틴다는 전제가 필요함. 아니면 결국 동물 뼈다귀로 서로 때리면 될지도 모름
  • 몇 년째 권한 기반 보안 모델을 원해왔고, 여기서도 논쟁한 적이 있음. 권한은 연관된 권한을 가진 객체 포인터 같은 것으로, Unix 파일 디스크립터와 비슷함
    운영체제 수준에서는 실행된 프로그램이 셸이나 실행한 곳에서 권한 토큰을 전달받고, 모든 시스템 호출이 첫 번째 인자로 권한을 받아야 함. 그래서 "open path /foo"는 open(cap, "/foo")가 됨. 이 권한은 가짜 파일시스템, 실제 파일시스템의 한 분기, 네트워크 파일시스템 등 무엇이든 될 수 있고, 프로그램은 자신이 어떤 샌드박스 안에 사는지 알 필요가 없음
    라이브러리/언어 수준에서도 npm 모듈 같은 서드파티 라이브러리를 가져올 때 import 시점이나 호출 위치마다 권한을 넘겨야 함. 그 라이브러리가 내 프로그램 주소 공간의 모든 바이트에 읽기/쓰기 접근을 가져서는 안 되고, 내 컴퓨터에서 나인 것처럼 무엇이든 할 수 있어서도 안 됨. 핵심 질문은 “이 코드의 폭발 반경이 어디까지인가?”임. 사용하는 라이브러리가 악성이거나 취약할 때, 피해 규모에 대해 합리적인 기본값이 필요함. lib::add(1, 2) 호출이 내 컴퓨터 전체의 지속적 침해로 이어져서는 안 됨
    SeL4는 빠르고 효율적인 운영체제 수준 권한을 오래전부터 제공했고 잘 작동함. 많은 경우 Linux보다 빠르며, 투명한 샌드박싱, 사용자 공간 드라이버, 프로세스 간 통신, 보안 개선 등에 매우 유용함. Linux를 SeL4 위의 프로세스로 실행할 수도 있음. Linux 데스크톱의 모든 기능을 가지면서 SeL4처럼 동작하는 운영체제를 원함
    아쉽게도 원하는 형태의 언어 수준 권한을 가진 프로그래밍 언어는 없는 것 같음. Rust가 꽤 가깝지만, 서드파티 crate가 어떤 unsafe 코드도 호출하지 못하게 제한할 방법이 필요함. 신뢰하지 않는 의존성이 부르는 unsafe도 포함됨. Rust의 오래된 건전성 버그도 고쳐야 하고, 권한 기반 표준 라이브러리도 필요함. 전역 open() / listen() 같은 것은 없어져야 하고, openat()과 운영체제의 다른 부분에 대응하는 동등한 형태만 있어야 함
    LLM이 계속 좋아진다면, 몇 년 안에 아무도 먼저 만들지 않으면 LLM에게 이걸 전부 만들게 할 생각임. 현대 데스크톱 운영체제의 보안은 농담 수준임
  • 대부분의 사람은 기본적으로 아무거나 입에 넣지 않음. 미생물 배양 결과가 양성으로 돌아올 때까지 기다렸다가 거부하지 않음
    코드에도 위생 문화가 필요하고, 이는 대부분의 문화권이 음식에 대해 발전시킨 규범과 별로 다르지 않음. 조잡한 휴리스틱의 조합이지만 “으엑”이라는 감각이 수십억 명을 살리고 있음
  • 1년 전에는 가능하면 서드파티를 가져오기보다 직접 코드를 쓰는 편이 낫다는 생각을 꺼냈음. 당시에는 LLM이 빈틈을 채우는 걸 고려하는 것 자체가 이단처럼 받아들여졌음
    지금은 의존성 노출을 그 어느 때보다 줄이고 있고, 특히 몇백 줄이면 구현 가능한 것들은 더 그렇음. 이건 그야말로 패러다임 전환임

• “소프트웨어 설치를 일주일 기다리라”는 방식은 통하지 않음. 불과 몇 달 전에도 대규모 취약점이 웹을 강타했는데, 한 달 넘게 잠복했다가 실행된 시간차 공격이었음
  모두가 일주일 기다리기 시작하면 공격자는 2주를 기다릴 것임. 사이버 범죄자는 즉시 악용할 필요가 없고, 결국 악용하기만 하면 됨. 오타스쿼팅 같은 많은 취약점 유형도 이 방식으로는 달라지지 않음

  • 글쓴이는 모든 업데이트를 계속 지연하자는 뜻이 아니라, 이번에 너무 이르게 공개된 특정 취약점들에 대한 수정과 패치 배포가 이루어질 때까지 일회성으로 일주일 기다리라는 제안으로 보임. 그 외의 부분에는 동의함
  • 글을 오해한 것 같음. 제안은 소프트웨어가 공개된 뒤 일주일 기다렸다가 설치하라는 게 아님. 지금부터 다음 7일 동안은 그냥 설치하지 말라는 뜻임
    이 취약점들에 대한 패치가 아직 없을 가능성이 높고, 있다 해도 곧 더 무서운 취약점이 발견될 가능성이 크기 때문임
  • 그렇다면 한 달이나 두 달을 기다리면 됨. 대기 기간의 핵심은 이미 설치된 익스플로잇의 실행을 막는 게 아니라, 새 익스플로잇 설치를 피하는 데 있음
  • 인기 패키지는 노출이 더 큼. 산출물이 공개되면 전 세계가 볼 수 있고, 누군가는 버전 간 차이를 확인하길 기대할 수 있음
    하지만 지연이 전혀 없으면 아직 아무도 보지 못한 익스플로잇에 당할 수 있음
  • “지난 몇 달” 동안 기억나는 의존성 침해는 모두 몇 시간이 아니라 몇 분 안에 발견됐음. litellm, axios, bitwarden CLI, Checkmarx Docker 이미지, Pytorch lightning, intercom/intercom-php가 그랬음
    더구나 이런 침해의 발견은 실제로 악용됐는지 여부에 전혀 의존하지 않았음. 그래서 “모두가 일주일 기다리면 공격자는 2주 기다릴 것”이라는 말이 이해되지 않음

• 다른 선택지로, 보안에 YOLO식으로 접근하지 않는 FreeBSD 같은 운영체제로 옮길 수 있음
  보안 수정이 조율 없이 FreeBSD 커널에 그냥 던져지지 않음. FreeBSD 보안팀을 거치며, 패치가 src 트리에 들어간 뒤 몇 분 안에 FreeBSD Update와 15.0-RELEASE용 pkgbase를 통해 바이너리 업데이트가 배포됨
  대략 Slack에 “패치를 푸시했다”는 메시지가 나가는 데 몇 초, 패치 업로드에 10~30초, 미러 동기화에 최대 1분 정도 걸림

  • 여기에 대해서는 조금 회의적임. 몇 년 전 FreeBSD 보안팀에 취약점을 알렸는데, 몇 주 뒤 후속 메일까지 보냈지만 답을 받지 못했음
    공정하게 말하면 내 보고는 핵심 구성요소가 아닌 것에 관한 것이었고 악용도 쉽지 않았지만, Debian, OpenBSD, SUSE, Gentoo는 모두 일주일 안에 패치했음 https://www.maxchernoff.ca/p/luatex-vulnerabilities#timeline
    그렇다고 단일한 사소한 보고 처리만으로 전체 운영체제를 평가하자는 뜻은 아님. 내가 본 다른 모든 점은 FreeBSD가 보안 보고를 꽤 진지하게 다룬다는 쪽에 가깝기 때문임. 다만 같은 논리를 Linux 커널 버그에도 적용할 수 있음. 그런 식으로 패치가 잘못 관리되는 일은 Linux에서도 꽤 드묾
  • 보안 때문에 BSD로 옮긴다면 왜 FreeBSD인가? OpenBSD가 엄청 안전한 쪽 아닌가? 그 프로젝트들을 본 지 오래돼서 묻는 것임
  • FreeBSD는 보안, 특히 기본값과 설정에 관해서는 꽤 느슨함
    보안보다 사용성을 선호하는 편임. 유명한 예가 여기 있음: https://vez.mrsk.me/freebsd-defaults
    프로젝트에 기여하는 일은 고맙게 생각하지만, 이런 나쁜 기본값이 있는 동안에는 양심상 사람들에게 옮기라고 권할 수 없음
  • FreeBSD는 2019년까지 사용자 공간 ASLR도 없었고, 다른 완화책들 중 하나인 kASLR도 아직 없음. 보안을 중시하는 사람에게는 진지한 운영체제가 아님
    FreeBSD와 보안을 원한다면 Shawn Webb의 HardenedBSD를 쓰는 편이 맞음
  • 이런 얘기에는 항상 누군가가 나오기 마련임. 좋아하는 배포판이 확실히 더 안전하다니 좋음. 익스플로잇이 한 자릿수 배로 줄어도 결국 몇천 개쯤은 남겠지만. Ozymandias는 Gentoo를 썼을 것임

• 보안 전문가들조차 이제 우리 세계가 엄청나게 취약한 균형 위에 있다는 점을 받아들여야 함. 사람들이 이걸 정말 과소평가한다고 봄
  IT 세계만이 아니라, 전체 세계가 수많은 매우 취약한 균형 위에 세워져 있음. 보안 익스플로잇은 늘 존재할 것임. 소프트웨어뿐 아니라 현실에서도 마찬가지임. 누군가는 보안 콘퍼런스에 몰래 들어가기도 했고, 그것도 그냥 유튜버였음. 물론 초고보안 행사는 아니었지만 떠오른 예시가 그거임. 기본적으로 대부분의 경우 보안을 우회하기는 정말 쉬움
  말하고 싶은 건, 근본적으로 우리 세계는 적어도 대부분의 사람이 악용하지 않기 때문에 작동한다는 것임. 인간 사회는 늘 그렇게 작동해왔고, 앞으로도 그럴 가능성이 큼

  • 영국 인플루언서들 사이에서 “사다리와 형광 조끼” 수법으로 장소에 들어가 물리 보안이 얼마나 허술한지 보여주는 유행이 있었던 걸 기억함 https://www.youtube.com/watch?v=LTI0SeyhAPA
    Max Fosh라는 유튜버가 International Security Expo에 연달아 들어갔던 것으로 알고 있음. 영국에서는 https://www.youtube.com/watch?v=qM3imMiERdU, 미국에서는 https://www.youtube.com/watch?v=NmgLwxK8TvA에서 가명으로 각각 “Rob Banks”와 “Nick Everything”을 썼음
    보안 문화를 공부해본 적이 있는데, 대부분은 한쪽에 보안, 다른 한쪽에 편의성/접근성이 있는 슬라이딩 스케일로 귀결됨. 더 안전할수록 덜 접근 가능하고, 그 반대도 마찬가지임

• npm, PyPI, Cargo 같은 의존성 관리자에 대한 공급망 공격에는 이미 괜찮은 해결책이 있음. 패키지 버전이 며칠 이상 지난 것만 설치하도록 설정하는 것임
  최근의 큰 공격들은 모두 하루 안에 발견되어 되돌려졌으므로, 이렇게 했다면 안전하게 피할 수 있었음. 이 동작은 기본값이어야 함. 스스로 선택한 베타 테스터와 보안 스캐너 회사들이 최신 패키지 버전을 하루쯤 먼저 써보게 하면 됨. 방법은 여기 있음: https://cooldowns.dev/

  • 3개월 전 Show HN에 올라온 이런 도구가 더 적절해 보임: https://github.com/artifact-keeper
    산출물 관리자임. 승인한 것만 가져오게 해줌. 필요할 때는 빠르게 업데이트하고, 필요할 때는 일관되게 검증된 안정 버전을 쓸 수 있음. 약간의 설정 재정의가 필요하지만 쉬운 작업임
    비슷한 목적의 엉성한 도구를 직접 만들어 쓴 적이 있는데, 이건 좋은 프로젝트임
  • 더 나은 방법은 회사가 검증한 저장소만 쓰고, 누구도 인터넷 저장소에서 직접 설치하지 못하게 하는 것임
    물론 기업 밖에서는 자연스럽게 잘 안 통함
  • 그러면 보안 업데이트도 늦게 받게 되는 것 아닌가? 많은 취약점은 발견되고 패치되기 전까지 몇 년 동안 실제 환경에 존재함
    일단 발견되면 바로 익스플로잇 폭발이 일어나고, 지연 업데이트는 흥분한 공격자들에게 더 많은 시간을 줌
  • 개인적으로 가장 지속 가능한 방식은 Linux 배포판/BSD ports/Homebrew 모델이라고 봄. 새 라이브러리를 공개 레지스트리에 바로 밀어 넣는 게 아니라, 새 변경마다 검토되는 패키징 스크립트를 작성하는 방식임
    또 다른 모델은 소스 파일만 배포하는 Perl의 CPAN임

• 지속적 통합과 컨테이너화된 빌드를 비교적 최근에 도입한 사람들은, 매 빌드마다 여러 패키지에서 latest를 끌어오고 있지 않은지 시스템을 확인해보는 게 좋음
  우리는 외부 의존성을 모두 넣은 기본 컨테이너를 만들어두고, 업데이트할 때가 됐다고 판단할 때만 명시적으로 갱신함
  그래서 최첨단보다 조금 뒤처질 수는 있지만, 무작위 공급망 취약점이 즉시 전 세계로 배포되는 위험은 훨씬 덜 떠안게 됨

  • 이렇게 하면 CI 빌드 시간과 불안정한 실패도 크게 줄어드는 걸 알게 될 것임
  • 추가로, 내부 저장소만 쓰는 게 좋음

• 적극적으로 해로운 의견 글임. 논리를 이해하기가 어려움
  copyfail과 dirtyfrag 취약점이 실제로 얼마나 오래됐는지 확인하는 데는 45초면 충분함. 글을 읽는 시간보다 길긴 함. Dirtyfrag는 2017년까지 거슬러 올라가는 시스템에도 관련될 수 있음
  영향을 받는 건 “새” 소프트웨어가 아님. 그리고 실제 오래된 소프트웨어는 문제를 찾을 시간이 훨씬 많았기 때문에 상태가 더 나쁨

  • 원글은 지금 공급망 공격이 발생하면 나쁠 수 있으니, NPM 패키지 설치/업데이트를 하지 말아 그 위험을 줄이자는 제안임

• 언젠가는 누군가 운영체제부터 애플리케이션까지 전체 스택을 증명 운반 코드 업그레이드로 다시 만들 것임
  신뢰할 수 있는 코드를 실행하는 유일한 방법은 증명과 코드의 공동 설계 및 공동 구축임

• 이건 소프트웨어에만 적용되는 게 아니라, 사실 거의 모든 것에 적용됨
  어디서 읽었는지는 기억나지 않지만 결국 필요와 욕구의 차이로 귀결됨
  새 차를 살지 중고차를 살지, 고급 청소기를 살지 기본형을 살지 결정할 때 이 규칙을 써왔음. 반짝이는 새 기기, 기술 스택에 새 무언가를 들이는 일, 새 기술 스택을 고르는 일에도 마찬가지임

• copyfail이 무엇이고 NPM 패키지와 어떻게 연결되는지 이해하는 데 도움을 받고 싶음
  정리해보니 copyfail은 악성 npm 패키지가 Linux 서버에서 루트 권한을 얻을 수 있게 하는 커널 버그인 것 같음
  그래서 아직 패치되지 않은 서버가 있는 지금이 공격자들이 NPM 패키지를 노리기에 완벽한 시점이라는 뜻임
  조언이 단순히 “커널을 업데이트하라”가 아닌 이유는 관련된 새 문제가 아직 계속 발견되고 있기 때문인가?

  • 최신 취약점들에 대한 패치는 아직 나오지도 않았음. 그래서 지금 새 공급망 공격이 벌어지면 거의 모든 시스템에서 루트를 얻을 수 있어 정말 나쁜 시점임
  • NPM 공급망 공격은 정말 빠르게 퍼짐
    인기 NPM 패키지가 침해되어 copy.fail 익스플로잇을 포함한다면, 많은 시스템이 루트 권한 상승에 취약해질 것임
  • 조언이 “커널을 업데이트하라”가 아닌 이유는 업데이트가 없기 때문임. copy.fail 이후에 발견된 최신 취약점은 아직 수정이 없음