오픈 소스 프로젝트 내 상호작용의 축소판인 xz 백도어 이슈

• xz/liblzma 취약점에 대한 많은 분석이 있겠지만, 대부분 공격의 첫 단계를 건너뛰는 경향이 있음
  • 원래 유지보수자가 탈진하고, 공격자만이 도움을 제안함(따라서 공격자는 원래 유지보수자가 쌓아온 신뢰를 물려받음).
• 이메일 스레드 아카이브에서 이 단계 0이 일어나던 시점의 상황을 포착

유지보수자의 탈진과 공격자의 등장

• 유지보수자에게 합리적으로 보이는 요청이 제기됨

  • "XZ for Java가 아직 유지보수 되구 있나요? 일주일전에 질문을 올렸는데 답변이 없네요"

• 이 질문은 유지보수자에게 "실패"를 인정하게 만듦
  • 실제로는 유지보수자는 아무것도 빚진거 없고 실패하지 않았지만, 그렇게 느낌
  • "커뮤니티"를 실망시키는 것은 끔찍한 일이기 때문
• 유지보수자는 자신이 "뒤처져 있다"고 인정하며 도움을 요청하는 듯한 신호를 보냄
• 그러나 그 스레드에서는 도움이 오지 않았고, 대신 xz/liblzma 공격자가 자신에게 도움을 줬다고 소개함

  • Jia Tan(이번 공격자)이 저를 도와줬고... 앞으로 더 큰 역할을 할 수도 있습니다... 제 자원이 너무 제한적이어서 장기적으로 뭔가 바뀌어야 한다는 게 분명합니다.

• 유지보수자는 자신의 자원이 한정되어 있어 장기적으로 무언가 변화가 필요하다고 언급함

비협조적인 소비자의 등장

• 비협조적인 소비자가 유지보수자에게 비판적인 발언을 함

  • "새로운 유지 보수자가 있을 때까지는 진전이 없겠네요. ... 현재 관리자는 관심을 잃었거나 더 이상 유지 관리에 신경을 쓰지 않습니다. 이런 리포지토리를 보는 것은 슬픈 일입니다."

• 유지보수자는 자신이 관심을 잃지 않았지만, 정신 건강 문제 등으로 인해 관리 능력이 제한되었다고 방어함
• 유지보수자는 또한 이것이 무급 취미 프로젝트라는 점을 상기시킴

요구사항의 증가

• 한 주 후, 비협조적인 소비자가 다시 나타나 유지보수자를 비난함.

  • "당신은 이 메일링 리스트에서 조금씩 썩어가고 있는 수많은 패치를 무시하고 있어요."

  • "정신 건강 문제에 대해서는 유감이지만 자신의 한계를 인식하는 것이 중요해요. 이 프로젝트가 모든 기여자를 위한 취미 프로젝트라는 것은 알지만 커뮤니티는 더 많은 것을 원합니다."

• 그 요청자가 제안을 하기도 하지만, 실제로 도움을 주겠다는 제안은 없음

  • "XZ for C에 대한 유지 관리 권한을 넘겨서 XZ for Java에 더 집중할 수 있도록 하는 것은 어떨까요? 아니면 XZ for Java를 다른 사람에게 넘겨서 XZ for C에 집중할 수 있도록 하면 어떨까요? 둘 다 유지하려고 하면 둘 다 잘 유지되지 않을 수 있습니다."

• 유지보수자는 새로운 공동 유지보수자를 찾거나 프로젝트를 완전히 넘기는 것이 쉽지 않다고 설명함

오픈 소스 프로젝트의 현실

• 소프트웨어 개발자는 마음대로 끼웠다 뺐다 할 수 있는 톱니바퀴가 아님
• 이메일 스레드는 불만을 토로하는 소비자가 계속 요구를 하면서도 아무런 도움을 제공하지 않는 것으로 끝나고, 공격자만 남게 됨

  • "Jia Tan은 앞으로 프로젝트에서 더 큰 역할을 맡게 될지도 모릅니다. 그는 목록 밖에서 많은 도움을 주고 있으며 사실상 이미 공동 관리자입니다. :-)"

• 이 이메일 스레드는 오픈 소스 프로젝트에서의 상호작용을 축소판으로 보여줌
• 소비자들은 유지보수자에게 요구사항을 제시하며, 유지보수자는 스트레스와 탈진으로 다양하게 반응함
• 이러한 방식은 변화가 필요함

[GN⁺]

Hacker News 의견

• 개발자가 사용자에게 친절하려고 노력하고 댓글 작성자의 좋은 의도를 보려고 할 때 많은 정신적 에너지를 낭비하는 것 같다는 의견이 있음. 이러한 의견은 주로 재미로 진행하는 사이드 프로젝트(에뮬레이터, 게임 리메이크 등)에서 나옴. 이러한 프로젝트는 기부금 문제나 저작권 문제를 피하기 위해 기부금 언급을 피함. 프로젝트에 대한 관심은 많지만 실제 기여할 수 있는 숙련된 관심은 극히 제한적임. 사용자들의 대화가 허용되고 격려되지만, 때로는 개발자들의 동기를 저하시키는 '제안'이나 '요구'로 인식될 수 있음. 커뮤니티를 유지하는 것이 중요하지만, 직접 기여하지 않는 사람들을 배제하지 않는 것에 대한 우려도 있음.

• 오픈소스 프로젝트 개발자가 공격자에게 저장소 제어권을 더 많이 넘기도록 압박받는 사회공학 공격이 문제의 첫 단계였음.

• 보안 지향적인 오픈소스 라이브러리의 유지보수자로서, PR을 읽을 때마다 "이 사람이 도움을 주려는 건지, 이용하려는 건지"에 대한 의심이 무겁게 다가옴. 개발 속도를 늦추는 것이 유일한 해결책이라고 생각하지만, 그로 인해 느껴지는 감정은 기사에 나온 것과 같음. 신뢰할 수 있는 전문가 커뮤니티에 도움을 요청할 수 있는 간단한 방법이 있다면 언제든지 환영할 것임.

• 암호화폐, AI, 그리고 이번 사건과 같이, 가장 큰 문제는 신뢰 문제로 귀결됨. 암호화폐는 신뢰 문제를 코드로 해결하려고 시도하고, LLM은 신뢰를 얻기 위해 화려함으로 속이려 하며, 공격자는 신뢰를 세탁하는 데 일부 성공함. 가장 중요한 기술자들이 신뢰에 대해 제대로 생각하지 못하고 있음. 이 경우, 지친 무급 오픈소스 개발자에 대한 이해가 있음.

• 포트 노킹이 설정된 SSH 서버가 이 백도어로부터 안전할지에 대한 질문이 있음. RCE가 SSH 서버에 연결한 후에만 수행될 수 있으므로, 합리적인 TCP/UDP 노킹 시퀀스 뒤에 포트가 숨겨져 있다면 문제가 발생하지 않을 것 같음. 포트 노킹은 적절한 SSH 구성을 대체하지 않지만, SSH 취약점이 나타날 때 예방하거나 대응 시간을 벌어주는 추가적인 방어층으로 유용함.

• OpenSSH의 리눅스 특정 패치와 관련된 문제에 대한 링크가 있음. 이 패치가 없었다면 문제가 발생하지 않았을 것임. 이는 OpenSSH의 문제가 아니라 리눅스의 문제임.

• 사람들이 여전히 left-pad 사건 이후에도 하드 의존성과 복잡성을 소홀히 다루고 있다는 의견이 있음. OpenSSH는 코드의 거대한 벽임. 복잡한 시스템은 어떤 언어로 작성되었든 간에 본질적으로 신뢰하기 어려움.

• 중국 해커가 악의적인 행동을 하려고 한다면, 왜 중국 이름/핸들러를 사용할까? 오픈소스 유지보수자들로부터 더 많은 신뢰를 얻기 위해 영어/유럽 이름을 사용하는 것이 더 나을 것임. 반면, 비중국 해커가 악의적인 행동을 하려고 한다면, 중국 이름을 사용하는 것이 더 의미가 있음(중국은 악, 등등).

• Jigar Kumar 계정은 사회공학 공격의 일부로 보이며 매우 의심스러워야 함.

• 소프트웨어 개발자는 교체 가능한 부품이 아니며, 커뮤니티에서 댓글을 달거나 참여할 수 있는 권한을 제한하는 것에 대해 생각하고 있음. 예를 들어, GitHub이 '게이트'를 도입한다면, 첫 번째 게이트는 테스트 스위트에 버전 번호와 테스트 출력의 해시를 생성하는 테스트를 추가하는 것일 수 있음. 이 번호를 프로필에 추가하면 GitHub은 사용자가 적어도 make test를 다운로드하고 실행했다고 신뢰할 수 있음. 이는 어느 정도의 헌신을 보여줌.