오 이런, 정말 심각한 취약점임. 이번에 수정됐다니 다행이지만, 처음에 이런 문제가 있었던 것 자체가 문제임. 클라우드 플랫폼에서 사용자 코드를 분석하는 시스템을 만들 때 가장 기본 규칙은 분석기는 반드시 격리된 환경에서 실행해야 한다는 것임. 플러그인을 통해 직접 코드 주입이 일어날 수 있고, linter/분석기/컴파일러는 복잡한 소프트웨어로서 취약점 표면적이 넓음. 임의의 저장소에 이런 도구를 공유 환경에서 실행하는 것이 위험하지 않다고 가정해서는 절대 안 된다고 생각함. 나도 코드 분석 플랫폼을 운영했는데, 고객 저장소에 우리가 직접 개발한 분석기를 돌릴 때도 샌드박스 환경에서 동작하도록 설계함. 환경 변수나 네트워크 요청 권한도 포함하지 않았지만, 분석은 샌드박스에서만 실행됨. 코드 분석을 안전하게 하는 유일한 방법임 https://github.com/getgrit/gritql
Coderabbit 유료 구독을 해지함. 기업이 문제를 인정하기 위해 HN에서 바이럴하게 퍼질 정도가 돼야 하는 상황이 늘 걱정임. 공식 블로그 어디에도 이번 취약점에 대한 언급이 없고, 오늘 새로운 글도 없음. 실수는 누구나 할 수 있다고 생각하지만, 이런 일이 생겼을 때 투명하게 공개하지 않는 점이 기업 이미지를 훼손한다고 봄
두 기사 모두 오늘 올라왔음. 보기에 연구팀과 coderabbit이 동시에 공개하기로 합의한 것 같음. 이런 동시 공개는 고객 데이터 유출이나 정황 증거가 없는 한 반드시 해야만 하는 게 아니라, 업체가 굳이 공개하겠다고 하는 경우에 종종 있는 관행임. 보안 연구원들이 대응을 칭찬하고 있다는 건 좋은 신호로 보임
대다수 보안 버그는 별다른 공지 없이 조용히 해결됨. 만약 고객 정보 유출이 없다면(그리고 그건 보통 확인 가능함), 법적으로 공개가 강제되지 않음. 굳이 공개할 이점이 없는데, 왜 꼭 그래야 한다고 생각하는지 모르겠음
"익스플로잇이 실행되는 동안 CodeRabbit이 직접 PR에 위험 경고 댓글을 남기는 데, 실상은 그 PR을 실행하면서 해킹이 일어난 상황"이 정말 기이함. AI가 자신이 해킹당하고 있다고 이야기하는 세상에 살고 있는 현실이 이질적으로 느껴짐. 또한, CodeRabbit 팀이 재빠르게 대응하기는 했지만, '다른 업체들은 조사 연락에도 전혀 답변하지 않았고, 여전히 취약하다'는 점이 더 걱정스러움. CodeRabbit 팀에게는 박수를 보내지만, 모두 조심해서 움직여야 할 것임
CodeRabbit이 자기 시스템에서 실행된 익스플로잇을 자기 스스로 리뷰한 모습이 재밌음
사실 실제로는 anthropic 모델이 익스플로잇을 말해준 거고, coderabbit 시스템은 무시한 셈임
결국 AI가 똑똑한 게 아니라, 그냥 잘 맞추는 추론 시스템이라는 사실을 또 한번 보여줌
CEO 공식 입장문 일부에서 "Rubocop이 샌드박스 환경 밖에서 돌아서 문제가 됐다"고 하는데, 솔직히 좀 의심스러움. 왜 특정 하나만 완전히 다르게 동작했으며, 그게 하필 뚫린 작업임?
왜 거짓말로 보이는지 모르겠음. 이런 실수는 흔하게 발생함
애초에 Kudelski Security 쪽 연구자들이 여러 정적 분석 도구를 시도해봤을 확률이 높음. Rubocop만 독특하게 작동한 것. 기사에서도 다양한 접근 시도 흔적이 나타남
"왜 어떤 작업만 다르게 구성되어 있었는지" → 누군가 실수한 것. 이런 일은 있을 수 있음. "왜 뚫린 서비스가 하필 뚫렸냐"라는 질문에는, 취약한 서비스가 공격당하는 게 오히려 자연스러운 시나리오라고 생각함
정말 흥미로운 글이었지만, 사실 놀라울 일도 아님. 사용자들이 아무 생각 없이 권한이 넓은 앱을 잔뜩 추가하고, github 권한 시스템도 문제라 이런 일은 필연적으로 일어날 수밖에 없었음. 많은 사람들이 github 앱의 저장소 쓰기 권한, 클라우드 권한까지 남용적으로 허용함. 브랜치 보호가 있어도, pull request를 통해 github actions에서 특권 접근이 가능함. 제대로 설정하려면 github oidc audience를 수정해야 하고, 문서화도 잘 안 되어있음. 앱 개발사에 권한을 줄이고 일부 기능을 비활성화한 별도 버전을 만들어달라고 요청해도 대부분 관심도 없고, 보안 문제를 이해하지 못함. github에서 앱 접근 권한을 더 세분화할 수 있게 해야 하며, 전반적으로 권한 자체가 더 세분화되어야 함
정말 충격적임. 아직 글을 다 읽지도 못했는데, 너무 많아서 정신이 혼미해짐. 해커가 10만~100만 단위의 오픈소스툴/라이브러리/소프트웨어 배포 파일에 멀웨어를 심을 수 있었다는 대목에서는 세상이 멸망할 수도 있었단 생각까지 듦. 앞으로 얼마나 많은 유사한 문제가 남아있을지 상상조차 하기 어려움
이제 'Github Apps' 자체가 위험하다는 생각이 듦. CodeRabbit이 안 뚫렸다고 해도, 이런 업체가 항상 성실하게 행동할 거라는 보장이 어디에 있음? 내부 직원이 악의적 행동을 하지 않는다고 누가 보장할 수 있음? 일반 SaaS에서 개인정보 관리는 한 가지 차원인데, 여기는 타깃형 공급망 공격의 키를 쥐고 있어서 대혼란을 초래할 수 있음
소프트웨어 업계에도 최소한의 안전장치나 규제가 도입되어야 함. 지금처럼 아무나 아무 실수나 저질러도 아무 책임도 없는 상태는 정말 비정상적임
이런 심각한 보안 실패는 "침해사고" 또는 "사건"으로 분류되어, 언론을 통해 의무적으로 공개하라고 해야 한다고 생각함. 7,000여 고객, 100만개 저장소에 접근할 수 있는 도구가, 기껏해야 11살짜리도 만들 수 있는 단순 익스플로잇에 뚫렸다는 사실임. 이렇게 쉬운 해킹이라면 bot, 블랙햇, APT 등이 이미 침투해서 은밀히 자리 잡았을 가능성이 크다고 볼 수 있음. 화이트헷이 공개하기 전 이미 들어와 있었다면, 취약점 패치는 새로운 공격자를 막을 뿐, 이미 잠입해 있는 존재는 퇴치되지 않을 수도 있음. 보안 어려운 건 알지만, 정말 정신 차려야 한다고 말하고 싶음
Code Rabbit은 'vibe coder' 회사인데, 기대할 게 뭔지 모르겠음. 보안 사고를 숨기고, 구글 클라우드 블로그에도 마케팅 글만 올려서 해킹 사실도 언급 안 하고, 여전히 백도어 없는 증거도 못 주는 상황임
나 같은 일반 사용자는, 이렇게 복잡하고 강력한 서비스가 실수로 모든 소중한 데이터를 외부로 유출시킬 수 있다는 사실에 앞으로 이런 걸 계속 써야 하는지 고민하게 됨. 조직이나 정부, 은행 외주 등 수많은 곳에서 이런 앱이 쓰이는데, T&C만 동의하면 제3자 접근권을 넘기는 구조임. >>“모든 회사에 이런 일이 생길 수 있다는 안심 문구”<<는 제공자는 위로하지만 사용자에겐 더 큰 걱정거리가 됨
문제 중 하나는 각종 코드 분석기, 번들러, 컴파일러(예: Rust 컴파일러 등)는 아무 경고 없이 임의 코드를 실행할 수 있다는 점임. 예를 들어, 해커가 채용과제라면서 저장소를 하나 보내고, 내가 “npm install”이나 Rust 컴파일 명령을 실행하면 내 컴퓨터가 곧바로 해커 손에 넘어갈 수 있음. 혹은 회사 동료 한 명 PC가 해킹당해 악성코드가 저장소에 들어가면, 결국 글로벌 대기업 전체가 외국 해커에 점령당하는 상황도 가능함. 이런 구조를 만든 건 npm과 Rust 컴파일러임. 이런 툴들은 외부 명령 실행 때마다 명시적 확인을 요청하는게 필요함(명령 허용목록을 캐시해 묻지 않게 할 수는 있음). 리눅스도 개발자가 쉽게 쓸 수 있는 안전한 샌드박스를 제공해야 하는데, 지금은 일일이 직접 만들어야만 함. 게다가, JS 패키지 설치 등 경우에 따라 외부 코드 실행이 필요하지 않은 작업도 있음. 그리고 환경변수로 비밀과 설정을 넣는 건 정말 나쁜 방법임. "12-factor app"을 만든 사람은 커맨드라인 스위치나 설정 파일이 있다는 걸 모르는 것 같음
코드 분석기/빌더/linter를 저장소에 돌리는 건, 원본 코드 자체를 그냥 실행하는 것보다 결코 더 안전하지 않음을 항상 인지해야 함
Rust 컴파일러(및 LLVM 기반 컴파일러)는 임의코드 실행 취약점이 있다고 가정하는 게 안전함. 하지만 공식적으로는 build system인 cargo에만 해당하는 기능이고, rustc(컴파일러 자체)는 아님
환경변수 대신 커맨드라인/설정파일 쓰면 프로세스 테이블에서 값이 노출됨. "ps" 명령만 해도 모든 정보가 다 보이는 문제임
"절대 실행되지 않는 가치 있는 코드가 있을 거란 암시"가 재밌음
"모든 외부 커맨드 실행 때마다 명시적으로 확인"하는 방식은 소용없음. 문제는 외부 명령이 아니라 임의 코드 자체 실행이기 때문임. 이런 코드는 모든 시스템 API, syscall에 접근 가능하므로 확인할 방법이 없음. Python/pip도 동일한 문제를 갖고 있으니 이미 늦었다고 봄
만약 비밀이 서명을 위한 게 아니라면, 결국은 vault에서 앱으로 가져와야 하기 때문에 프로덕션 시스템에 접근할 수 있다는 건 곧 그 비밀에도 접근할 수 있다는 뜻임. 물론 신뢰할 수 없는 코드 실행 상황에서는 환경을 격리하고, 이런 키를 전달하지 않아야 했지만, 보통은 흔하지 않은 케이스임
CodeRabbit의 Howon임. 우리는 앱 비밀 정보용으로 클라우드 제공업체의 key vault를 사용하고, GH private key도 포함되어 있음
Rubocop 설정 파일로 확장 Ruby 파일 경로를 지정할 수 있다는 문구를 읽는 순간 "설마 사용자 확장 도구를 프로덕션 환경에 직접 돌린 건가..." 했는데, 아니나 다를까 실제였음. 물론 이런 구멍 하나만 막았다고 제대로 안전한 건 아님. 대부분 linter가 공격적 입력에 대해 감사를 받거나 퍼징이 된 것도 드물텐데, 이건 그냥 문 열어두고 “해킹해 주세요!”라는 네온사인을 켜둔 격임
CEO의 공식 답변에 나온 “Rubocop이 샌드박스 밖에서 돌아갔다”는 부분을 보면, 그게 진짜 문제의 핵심은 아닌 거 같음
Hacker News 의견
오 이런, 정말 심각한 취약점임. 이번에 수정됐다니 다행이지만, 처음에 이런 문제가 있었던 것 자체가 문제임. 클라우드 플랫폼에서 사용자 코드를 분석하는 시스템을 만들 때 가장 기본 규칙은 분석기는 반드시 격리된 환경에서 실행해야 한다는 것임. 플러그인을 통해 직접 코드 주입이 일어날 수 있고, linter/분석기/컴파일러는 복잡한 소프트웨어로서 취약점 표면적이 넓음. 임의의 저장소에 이런 도구를 공유 환경에서 실행하는 것이 위험하지 않다고 가정해서는 절대 안 된다고 생각함. 나도 코드 분석 플랫폼을 운영했는데, 고객 저장소에 우리가 직접 개발한 분석기를 돌릴 때도 샌드박스 환경에서 동작하도록 설계함. 환경 변수나 네트워크 요청 권한도 포함하지 않았지만, 분석은 샌드박스에서만 실행됨. 코드 분석을 안전하게 하는 유일한 방법임
https://github.com/getgrit/gritql
Coderabbit 유료 구독을 해지함. 기업이 문제를 인정하기 위해 HN에서 바이럴하게 퍼질 정도가 돼야 하는 상황이 늘 걱정임. 공식 블로그 어디에도 이번 취약점에 대한 언급이 없고, 오늘 새로운 글도 없음. 실수는 누구나 할 수 있다고 생각하지만, 이런 일이 생겼을 때 투명하게 공개하지 않는 점이 기업 이미지를 훼손한다고 봄
"익스플로잇이 실행되는 동안 CodeRabbit이 직접 PR에 위험 경고 댓글을 남기는 데, 실상은 그 PR을 실행하면서 해킹이 일어난 상황"이 정말 기이함. AI가 자신이 해킹당하고 있다고 이야기하는 세상에 살고 있는 현실이 이질적으로 느껴짐. 또한, CodeRabbit 팀이 재빠르게 대응하기는 했지만, '다른 업체들은 조사 연락에도 전혀 답변하지 않았고, 여전히 취약하다'는 점이 더 걱정스러움. CodeRabbit 팀에게는 박수를 보내지만, 모두 조심해서 움직여야 할 것임
CEO 공식 입장문 일부에서 "Rubocop이 샌드박스 환경 밖에서 돌아서 문제가 됐다"고 하는데, 솔직히 좀 의심스러움. 왜 특정 하나만 완전히 다르게 동작했으며, 그게 하필 뚫린 작업임?
정말 흥미로운 글이었지만, 사실 놀라울 일도 아님. 사용자들이 아무 생각 없이 권한이 넓은 앱을 잔뜩 추가하고, github 권한 시스템도 문제라 이런 일은 필연적으로 일어날 수밖에 없었음. 많은 사람들이 github 앱의 저장소 쓰기 권한, 클라우드 권한까지 남용적으로 허용함. 브랜치 보호가 있어도, pull request를 통해 github actions에서 특권 접근이 가능함. 제대로 설정하려면 github oidc audience를 수정해야 하고, 문서화도 잘 안 되어있음. 앱 개발사에 권한을 줄이고 일부 기능을 비활성화한 별도 버전을 만들어달라고 요청해도 대부분 관심도 없고, 보안 문제를 이해하지 못함. github에서 앱 접근 권한을 더 세분화할 수 있게 해야 하며, 전반적으로 권한 자체가 더 세분화되어야 함
정말 충격적임. 아직 글을 다 읽지도 못했는데, 너무 많아서 정신이 혼미해짐. 해커가 10만~100만 단위의 오픈소스툴/라이브러리/소프트웨어 배포 파일에 멀웨어를 심을 수 있었다는 대목에서는 세상이 멸망할 수도 있었단 생각까지 듦. 앞으로 얼마나 많은 유사한 문제가 남아있을지 상상조차 하기 어려움
이런 심각한 보안 실패는 "침해사고" 또는 "사건"으로 분류되어, 언론을 통해 의무적으로 공개하라고 해야 한다고 생각함. 7,000여 고객, 100만개 저장소에 접근할 수 있는 도구가, 기껏해야 11살짜리도 만들 수 있는 단순 익스플로잇에 뚫렸다는 사실임. 이렇게 쉬운 해킹이라면 bot, 블랙햇, APT 등이 이미 침투해서 은밀히 자리 잡았을 가능성이 크다고 볼 수 있음. 화이트헷이 공개하기 전 이미 들어와 있었다면, 취약점 패치는 새로운 공격자를 막을 뿐, 이미 잠입해 있는 존재는 퇴치되지 않을 수도 있음. 보안 어려운 건 알지만, 정말 정신 차려야 한다고 말하고 싶음
문제 중 하나는 각종 코드 분석기, 번들러, 컴파일러(예: Rust 컴파일러 등)는 아무 경고 없이 임의 코드를 실행할 수 있다는 점임. 예를 들어, 해커가 채용과제라면서 저장소를 하나 보내고, 내가 “npm install”이나 Rust 컴파일 명령을 실행하면 내 컴퓨터가 곧바로 해커 손에 넘어갈 수 있음. 혹은 회사 동료 한 명 PC가 해킹당해 악성코드가 저장소에 들어가면, 결국 글로벌 대기업 전체가 외국 해커에 점령당하는 상황도 가능함. 이런 구조를 만든 건 npm과 Rust 컴파일러임. 이런 툴들은 외부 명령 실행 때마다 명시적 확인을 요청하는게 필요함(명령 허용목록을 캐시해 묻지 않게 할 수는 있음). 리눅스도 개발자가 쉽게 쓸 수 있는 안전한 샌드박스를 제공해야 하는데, 지금은 일일이 직접 만들어야만 함. 게다가, JS 패키지 설치 등 경우에 따라 외부 코드 실행이 필요하지 않은 작업도 있음. 그리고 환경변수로 비밀과 설정을 넣는 건 정말 나쁜 방법임. "12-factor app"을 만든 사람은 커맨드라인 스위치나 설정 파일이 있다는 걸 모르는 것 같음
"원하는 대로 github 앱이 될 수 있는" 권한 열쇠(프라이빗 키)가 환경 변수에 보관됐던 건 정말 최악의 관행임. 누구나 해킹당할 수는 있지만, 이건 비밀 관리의 가장 기본 중 기본임. github 공식 문서에도 환경 변수에 프라이빗 키를 넣지 말라고 분명히 나와있음. 정말 기초 중의 기초임
https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/managing-private-keys-for-github-apps#storing-private-keys
Rubocop 설정 파일로 확장 Ruby 파일 경로를 지정할 수 있다는 문구를 읽는 순간 "설마 사용자 확장 도구를 프로덕션 환경에 직접 돌린 건가..." 했는데, 아니나 다를까 실제였음. 물론 이런 구멍 하나만 막았다고 제대로 안전한 건 아님. 대부분 linter가 공격적 입력에 대해 감사를 받거나 퍼징이 된 것도 드물텐데, 이건 그냥 문 열어두고 “해킹해 주세요!”라는 네온사인을 켜둔 격임