본문으로 건너뛰기
검색
주 메뉴
검색어:
cURL and libcurl
2026년 3월 26일Daniel Stenberg댓글 1개
소프트웨어와 디지털 보안은 신뢰 가 아니라 검증 에 의존해야 합니다. 저는 더 많은 사용자와 소프트웨어 소비자들이 curl을 검증하기를 강력히 권장하고 싶습니다. 그리고 이상적으로는, 여러분의 의존성 체인에 있는 다른 소프트웨어 구성요소들에 대해서도 최소한 이 정도 수준의 검증을 할 수 있기를 요구해야 합니다.
공격은 어디에나 있다
모든 소스 코드 커밋과 모든 소프트웨어 릴리스에는 위험이 따릅니다. 그리고 그것들과는 완전히 별개인 위험도 있습니다.
널리 사용되는 프로젝트가 피해자가 될 수 있는 일들에는 다음과 같은 것들이 있습니다…
- Jia Tan 은 프로젝트 팀의 유능하고 친절한 구성원이지만, 의도적으로 다른 것처럼 위장한 악성 내용을 병합하고 있다.
- 기존 커미터가 본인도 모르게 침해당했을 수 있고, 이제 그들의 커밋이나 릴리스에 오염된 비트가 포함된다.
- 어떤 뜬금없는 사람이 버그 수정처럼 보이는 것을 병합하도록 우리를 설득했지만, 사실 그것은 심어 놓은 취약점이나 심지어 백도어를 구축해 가는 작은 조각들의 긴 사슬 중 한 단계였다.
- 누군가 기존 curl 팀 구성원을 협박하거나 갈취하여, 프로젝트에서 원래는 받아들여지지 않았을 변경을 수행하게 만든다.
- 기존의 선의의 프로젝트 구성원이 기능을 추가하거나 버그를 수정하는 변경이, 실수로 보안 취약점을 만들어 낸다.
- 보통 tarball을 배포하는 웹사이트가 해킹되어, 최신 릴리스의 사악한 대체 버전이 제공되고 악성코드가 퍼진다.
- 알려진 curl 프로젝트 구성원의 자격 증명이 침해되어, 알려져 있고 신뢰받는 출처 에서 온 것처럼 보이는 허위 정보가 배포된다. 이메일, 소셜 미디어 또는 웹사이트를 통해서. 심지어 이 블로그일 수도 있다!
- 이 목록의 어떤 항목은, 알려진 프로젝트 구성원이 악의적 행위자를 돕기 위해 잘못된 내용을 반복하는 것처럼 보이게 만드는 온라인 딥페이크 영상으로 뒷받침될 수도 있다.
- 클라우드 제공업체에 호스팅된 CI에서 사용하는 도구가 해킹되어 악성 무언가를 실행한다.
- 기본 curl git 저장소에 장애가 있는 동안, 누군가 온라인에서(아마도 curl 팀 구성원으로 사칭하며?) 오염된 코드를 담은 임시 “curl 미러”를 제공한다.
이런 일들 중 어느 하나라도 발생한다면, 물론 그것들은 조합되어 매우 빠른 연쇄로 일어날 수도 있습니다.
여러분은 검증할 수 있다
curl은, 대부분 libcurl의 형태로, 수백억 대의 장치에서 실행됩니다. 분명히 세계에서 가장 널리 사용되는 소프트웨어 구성요소 중 하나입니다.
사람들은 사실상 어느 시점에서든 일어날 수 있는 엄청나게 많은 끔찍한 일들을 생각하면 제가 어떻게 밤에 잠을 자는지 묻습니다.
이런 종류의 불면과 맞서는 방법은 단 하나뿐입니다. 가능한 모든 것을 하고, 그것을 공개적이고 투명하게 수행하는 것입니다. 지난주보다 이번 주에 조금이라도 더 낫게 만드는 것입니다. 소프트웨어 엔지니어링을 제대로 하는 것입니다. 우리가 하는 일과 우리가 배포하는 것을 모두가 검증할 수 있는 수단을 제공하는 것입니다. 반복하고, 반복하고, 반복하는 것입니다.
단 몇 명의 사용자라도 자신이 받은 curl 릴리스가 curl 릴리스 관리자에 의해 서명되었다는 것을 검증하고, 릴리스 내용이 오염되지 않았으며 git 저장소에서 나온 비트만 포함하고 있다는 것을 검증한다면, 우리는 꽤 좋은 상태에 있는 것입니다. 우리는 충분히 많은 독립적인 외부 사용자들이 이것을 하기를 필요로 합니다. 그래야 어느 시점에서든 무언가 이상해 보인다면 그들 중 한 명이 경고를 울릴 수 있습니다.
저는 이 사용자들이 누구인지, 아니 실제로 존재하는지조차 여러분에게 말할 수 없습니다. 왜냐하면 그들은 저와 curl 프로젝트로부터 완전히 독립적이어야 하고 또 반드시 그래야 하기 때문입니다. 하지만 우리는 모든 수단을 제공하고 있으며, 그런 사용자들이 이 검증을 수행 하기 쉽게 만들어 두었습니다.
우리는 반드시 검증해야 한다
릴리스에서 아무것도 변조되지 않았음을 검증하는 소수의 외부인은, 릴리스가 git에 존재하는 것으로부터 만들어졌다는 것만 확인할 수 있습니다. git에 존재하는 것이 진짜 그 자체 인지 확인하는 것은 우리 자신의 일입니다. 안전하고 신뢰할 수 있는 curl 말입니다.
우리는 git에 반영하는 모든 것이 괜찮다는 점을 보장하기 위해 아주 많은 일을 해야 합니다. 다음은 우리가 하는 활동들의 목록입니다.
- 우리는 일관된 코드 스타일을 갖고 있습니다(유효하지 않은 스타일은 오류를 발생시킵니다). 이는 실수의 위험을 줄이고 기존 코드를 디버그하기 쉽게 만듭니다.
- 우리는 여러 “민감한” 그리고 “사용하기 어려운” C 함수를 금지하고 피합니다(그런 함수의 사용은 오류를 발생시킵니다).
- 우리는 함수의 복잡도 상한을 두어 따라가기 쉽고 읽기 쉽고 이해하기 쉽게 유지합니다(이를 지키지 않으면 오류가 발생합니다).
- 우리는 병합 전에 모든 pull request를 사람과 봇 모두로 검토합니다. 우리는 커밋 메시지에서 커밋을 원래의 pull request에 다시 연결합니다.
- 우리는 악의적 행위자가 암호화된 페이로드를 묶어 넣을 수단을 제공하지 않기 위해 git에서 “바이너리 블롭” 사용을 금지합니다(블롭을 포함하려 하면 오류가 발생합니다).
- 우리는 base64 인코딩된 조각들도 악성 내용을 난독화하는 방식으로 기능할 수 있기 때문에 적극적으로 피합니다.
- 우리는 다른 문자처럼 보이는 쉽게 혼동되는 문자를 피하기 위해 코드와 문서에서 대부분의 Unicode 사용을 금지합니다(Unicode 문자를 추가하면 오류가 발생합니다).
- 우리는 모든 것이 어떻게 동작해야 하는지 명확하게 하기 위해 모든 것을 문서화합니다. 놀랄 일은 없습니다. 많은 문서는 맞춤법 검사와 일관된 표현뿐 아니라 테스트와 검증도 거칩니다.
- 우리는 수천 개의 테스트를 보유하고 있으며 (이상적으로는) 모든 기능에 대해 테스트 케이스를 추가합니다. “빈 구역”을 찾아 커버리지를 추가하는 것은 최우선 과제입니다. curl은 셀 수 없이 많은 운영체제와 CPU 아키텍처에서 실행되고, 수십억 가지 서로 다른 구성으로 빌드할 수 있습니다. 모든 조합을 실제로 테스트하는 것은 불가능합니다.
- 우리는 모든 커밋과 모든 PR에 대해 실행되는 200개가 넘는 CI 작업에서 curl을 빌드하고 테스트를 수행합니다. 설명되지 않은 테스트 실패가 있는 커밋은 병합하지 않습니다.
- 우리는 CI에서 가장 까다로운 컴파일러 옵션을 활성화한 상태로 curl을 빌드하며, 컴파일러 경고가 남아 있도록 절대 두지 않습니다. 우리는 항상 경고를 오류로 바꾸고 빌드를 실패시키는
-Werror 를 사용합니다.
- 우리는 메모리 문제, 정의되지 않은 동작 및 유사한 문제의 위험을 찾아 줄이기 위해 valgrind와 여러 sanitizer 조합을 사용하여 모든 테스트를 실행합니다.
- 우리는 모든 테스트를 “고문 테스트”로도 실행하는데, 여기서는 각 테스트 케이스를 다시 실행하여 호출된 모든 실패 가능한 함수 호출이 각각 한 번씩 실패하도록 해서, curl이 이로 인해 메모리를 누수하거나 크래시하지 않음을 확인합니다.
- 우리는 curl에 대해 fuzzing을 수행합니다. Google의 OSS-Fuzz 프로젝트의 일환으로는 중단 없이, 그리고 모든 커밋과 PR에 대해서는 CI 설정의 일부로 짧게 수행합니다.
- 우리는 curl용 CI 작업이 절대로 curl에 “되돌려 쓰기”를 하지 않도록 보장합니다. 이들은 소스 저장소에 읽기 전용으로 접근하며, 설령 침해되더라도 소스 코드를 감염시키거나 오염시킬 수 없습니다.
- 우리는 insecure한 CI 작업을 실행하거나 사용하는 위험을 줄이기 위해 CI 작업 설정 스크립트에 대해
zizmor 및 기타 코드 분석 도구를 실행합니다.
- 우리는 보고된 취약점을 다음 릴리스에서 항상 수정하겠다고 약속합니다. 보안 문제는 한 번 보고되면 결코 그대로 방치되지 않습니다.
- 우리는 지금까지 보고된 모든 curl 취약점에 대한 모든 것과 모든 세부 사항을 문서화합니다.
- ABI나 API를 절대 깨지 않겠다는 우리의 약속은 모든 사용자가 새 릴리스로 쉽게 업그레이드할 수 있게 합니다. 이는 사용자가 오래된 불안전한 버전 대신 최근의 보안 수정 버전을 실행할 수 있게 합니다.
- 우리의 코드는 외부 보안 전문가들에 의해 여러 차례 감사를 받았고, 그 과정에서 발견된 소수의 문제들은 즉시 해결되었습니다.
- GitHub의 2단계 인증은 모든 커미터에게 필수입니다.
이 모든 것은 완전한 투명성과 완전한 책임성 아래 공개적으로 이루어집니다. 누구나 이 과정을 따라가며 우리가 이를 지키는지 검증할 수 있습니다.
여러분의 모든 의존성에도 이것을 요구하십시오.
편집증이 아니다
우리는 누군가가 실제로 우리와 우리 사용자들에게 심각한 피해를 주고 싶어 하며 실제로 시도하는 상황을 대비합니다. 혹은 그것이 실수로 일어나는 상황도 대비합니다. curl에 대한 성공적인 공격은 이론적으로 매우 넓게 퍼질 수 있습니다.
이것은 편집증이 아닙니다. 이 체계 덕분에 우리는 밤에 편히 잠들 수 있습니다.
이것이 바로 30년이 지난 지금도 사용자들이 curl에 의존하는 이유입니다.
문서화됨
저는 최근 이 글에서 쓴 내용의 일부를 설명하는 검증 페이지 를 curl 웹사이트에 추가했습니다.
cURL and libcurl보안
이전 글 기묘한 이메일 백 통
“믿지 말고, 검증하라”에 대한 한 가지 생각
Mayank Sinha님 글: 2026년 3월 26일 18:29 안녕하세요 Daniel,
당신의 블로그를 많이 읽습니다. AI가 생성한 이슈가 오픈소스를 어지럽히고 있다는 당신의 분노 어린 글부터 읽기 시작했습니다. 제가 거의 매일 사용하는 가장 중요한 라이브러리 중 하나에 대해 당신이 투명성에 헌신하는 모습을 보는 것이 정말 좋습니다.
그동안 해주신 모든 일에 감사드리고 싶었습니다. 답글
이메일 주소는 공개되지 않습니다.필수 입력 항목은 * 로 표시됩니다.
댓글 *
이름 *
이메일 *
웹사이트
시간 제한이 초과되었습니다. CAPTCHA를 다시 불러오십시오.nine 4 nine seven five
Δ
이 사이트는 스팸 감소를 위해 Akismet을 사용합니다. 댓글 데이터가 처리되는 방법 알아보기.
curl, 오픈소스와 네트워킹
후원하기:on GitHub
팔로우하기: @bagder
구독하기: RSS-feed
이메일: 주간 보고서
2026년 3월| 월 | 화 | 수 | 목 | 금 | 토 | 일 |
| --- | --- | --- | --- | --- | --- | --- |
| | 1 |
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 | |
« 2월
개인정보 처리방침Proudly powered by WordPress
