취약점

취약점 (Vulnerabilities)

SQLite에 대해 보고된 CVE 대부분은 대부분의 사용 사례에는 적용되지 않아요. SQLite에 대해 보고된 모든 역사적 취약점은 공격자가 임의의 SQL을 제출·실행할 수 있거나, 악의적으로 조작된 데이터베이스 파일을 제출할 수 있어야 해요. 실제 애플리케이션 중 이 전제조건을 충족하는 경우는 드물답니다.

출처: 문서

본문

1. 요약 (Executive Summary)

• SQLite에 관한 CVE는 대부분 SQLite 사용에 적용되지 않을 거예요.
• SQLite에 대해 보고된 모든 역사적 취약점은 다음 전제조건 중 적어도 하나를 요구해요:
  • 공격자가 임의의 SQL 문을 제출하고 실행할 수 있음.
  • 공격자가 애플리케이션에 악의적으로 조작된 데이터베이스 파일을 제출하고, 애플리케이션이 그 파일을 열고 쿼리함.
• 실제 애플리케이션 중 이 전제조건 중 하나라도 충족하는 경우는 드물어서, 패치되지 않은 오래된 SQLite 버전을 사용하더라도 취약한 실제 애플리케이션은 드물어요.
• SQLite 개발팀은 버그를 신속하게, 보통 발견 후 몇 시간 안에 고쳐요. 버그가 실제 애플리케이션에 영향을 줄 것 같으면 SQLite의 새 릴리스가 발행돼요.
• 그레이햇 해커들은 작성한 CVE의 수와 심각도에 따라 보상을 받아요. 그 결과 영향이 작거나 전혀 없지만 과장된 영향 주장을 하는 CVE가 proliferate(급증)해요.
• SQLite에 대해 작성된 CVE 중 실제 취약점은 매우 드물어요. 공격자에게 어떤 새로운 능력도 주지 않기 때문이에요. 다음을 고려해보세요:
  • SQLite에 대해 작성된 거의 모든 CVE는 임의의 SQL을 주입하고 실행할 수 있는 능력을 요구해요.
  • 대부분 CVE의 광고된 결과는 "서비스 거부(denial of service)"로, 보통 NULL 포인터 역참조나 0으로 나누기 등으로 크래시를 일으키는 거예요.
  • 하지만 공격자가 이미 임의의 SQL을 실행할 수 있다면, 서비스 거부를 일으키기 위해 버그가 필요하지 않아요. 무제한 CPU, 메모리, 디스크 I/O를 소비해서 버그의 도움 없이 서비스 거부를 만들 완벽히 합법적이고 유효한 SQL 문이 많아요.
  • 따라서 공격자가 임의의 SQL을 주입하고 실행할 방법이 있다는 사실 자체가 곧 서비스 거부 공격이에요. 그 임의의 SQL이 SQLite의 버그를 건드려 크래시를 일으키는 것은 새 취약점이 아니에요.
• SQLite 개발자는 CVE를 작성하지 않아요. SQLite에 대해 찾은 CVE는 모두 제3자가 만든 것으로, 종종 핵심 개발자의 입력 없이 만들어져요. 흔한 시나리오는 누군가 SQLite의 버그를 보고하고 신속히 고쳐진 뒤, 몇 주 후 그 버그에 대한 CVE가 개발자도 모르는 사이 나타나는 거예요.
• SQLite에 관한 CVE가 권위 있는 정보를 담고 있다고 가정하면 안 돼요. CVE는 종종 부정확함을 포함해요. SQLite 개발자들은 SQLite에 관한 CVE에 명확화와 수정을 추가하려고 시도했어요.

2. CVE에 대하여

CVE("Common Vulnerabilities and Exposures")는 시스템이 해킹될 수 있게 할 수 있는 소프트웨어 버그에 대한 보고예요. CVE 뒤의 아이디어는 건전해요. 정보 보안을 손상시킬 수 있는 소프트웨어 버그를 쉽게 추적할 수 있는 공통 명명 체계를 제공하죠.

CVE 뒤의 원래 아이디어는 건전하지만, CVE를 만들고 관리하는 현재 프로세스는 부적절해요. 수많은 그레이햇 해커들이 광범위한 오픈소스 소프트웨어 제품(SQLite와 많은 다른 것)에 퍼저를 돌리고, 발견하는 문제에 대해 CVE를 작성해요. 그레이햇들은 작성한 CVE의 수와 심각도에 따라 때로 명예로, 때로 금전으로 보상받아요. 이 인센티브는 종종 제대로 검증되지 않고 과장된 영향 주장을 가질 수 있는 CVE의 급증을 초래해요. CVE의 품질 관리 절차는 이 입력 홍수를 감당하지 못해서, 과장되거나 오해의 소지가 있거나 누락되거나 부정확한 주장을 수정하기 어려워요.

이것이 CVE가 쓸모없다는 뜻은 아니에요. CVE는 여전히 (대부분) 실제 버그를 보고해요. 하지만 대부분의 경우 그 버그는 그 자체로 데이터 손실이나 손상에 기여하지 않는다는 의미에서 진정한 취약점이 아니에요. 버그가 보고되고 고쳐지는 것은 좋은 일이에요. 하지만 모든 버그가 모든 애플리케이션에서 접근 가능한 것은 아니에요. SQLite의 경우, CVE가 보고한 대부분의 버그는 대부분의 애플리케이션에서 접근 불가능해요. 최신 SQLite 버전으로 업그레이드하는 것은 항상 좋은 계획이지만, 인터넷의 익명 그레이햇이 CVE를 작성했다고 해서 긴급 상황일 필요는 없어요.

2.1. 별도의 SQL 삽입 취약점이 보통 필요해요

복잡한 구조적 입력을 처리하는 다른 C 라이브러리들은 신뢰할 수 없는 소스의 검증되지 않은 입력을 다루도록 일상적으로 요청받아요. libjpeg, libzip, OpenSSL 같은 라이브러리는 잠재적으로 적대적인 에이전트에서 직접 오는 입력 스트림을 넘겨받아요.

하지만 SQLite 같은 데이터베이스 엔진은 보통 이렇지 않아요. SQLite에 전달되는 SQL 스크립트는 (신뢰하는) 애플리케이션 자체에서 오지, 공격자에게서 오지 않아요. 때로 애플리케이션이 외부 공격자가 애플리케이션을 속여 공격자 설계의 SQL을 데이터베이스 엔진으로 보내도록 하는 버그를 포함하기도 해요. 이것은 SQL Injection 취약점이라 불리는 애플리케이션의 별도 버그예요. SQL 텍스트는 실행 가능한 코드이므로, SQL Injection 취약점은 사실 Remote Code Execution (RCE) 취약점의 특수한 경우예요. SQL Injection은 아마 다른 종류의 RCE만큼 심하지는 않아요. SQL은 강력한 언어지만 익스플로잇을 만들기에는 Python이나 셸 스크립트나 원시 머신 코드만큼 편리하지 않기 때문이에요. 그럼에도 SQL Injection은 심각한 문제예요.

SQLite에 대해 작성된 대부분의 CVE는 공격자가 SQLite에서 임의의 SQL 스크립트를 실행할 수 있다고 가정해요. 대부분의 애플리케이션에서 이는 먼저 공격자가 악성 SQL을 주입할 수 있게 하는 SQL Injection 취약점이 있어야 한다는 뜻이에요.

소수의 애플리케이션은 잠재적으로 적대적인 에이전트에서 받은 신뢰할 수 없는 SQL 스크립트를 SQLite에서 직접 실행하게 허용해요. 주요 예로는 Chrome과 Safari 웹 브라우저가 있어요. 이 브라우저들은 익명 웹 페이지가 Javascript의 WebSQL 기능을 사용해 SQL을 실행하게 해줘요. 이는 자원에 대한 엄격히 통제된 제약이 있는 샌드박스 안에서 이루어져요. SQL 스크립트가 서비스 거부 공격에서 사용 가능한 모든 메모리나 CPU 사이클을 흡수하지 못하게요. Chrome과 Safari는 적대적 에이전트가 나머지 머신에 해를 끼치거나 손상시키지 않는 코드를 실행하도록 허용하는 인프라를 갖추고 있어요. Javascript도 실행하기 때문에 그럴 수밖에 없어요. 엄격히 통제하지 않으면 무절제한 SQL보다 더 큰 피해를 줄 수 있거든요. Chrome과 Safari를 제외하면, SQLite 개발자가 아는 어떤 애플리케이션도 익명 원격 에이전트가 임의의 SQL 텍스트를 실행하도록 의도적으로 허용하지 않아요.

하지만 SQLite에 대해 작성된 대부분의 CVE는 공격자가 데이터베이스 엔진에서 어떤 임의의 SQL이든 자유롭게 실행할 수 있다고 경솔하게 가정해요. 그래서 대체로, SQLite에 대해 작성된 대부분 CVE는 사실상 Chrome과 Safari에서 사용되는 SQLite에만 적용돼요. 다시 말해, SQLite용 CVE 대부분은 Chrome이나 Safari의 개발자가 아니면 적용되지 않아요.

2.2. 어둠의 마법에 대한 방어 (Defense Against Dark Arts)

대부분의 애플리케이션은 흔하지 않은 SQL 입력의 버그에 대해 걱정하지 않고 SQLite를 사용할 수 있어요. 애플리케이션이 SQL을 제어하고, 애플리케이션이 의도적으로 SQLite를 깨뜨리려 하지 않는다면, 모든 것이 잘 동작할 거예요. 최신 패치 버전의 SQLite가 필요하지 않아요. 어떤 이전 버전이든 제대로 동작할 거예요.

하지만 애플리케이션이 신뢰할 수 없는 SQL을 안전하게 실행할 수 있어야 하는 경우가 있어요. SQLite 개발자들은 이 목적을 위해 SQLite를 안전하게 만들기 위해 열심히 노력해요, 가끔 실수가 있긴 하지만요. 이 경우 최신 패치를 따라잡는 것이 좋아요. 별도의 "defense against dark arts" 문서는 SQLite가 직접 신뢰할 수 없는 소스에서 오는 입력을 받는 경우 제로데이 공격을 방지하는 데 도움이 되는 추가 제안을 포함해요.

2.3. CVE에 대한 SQLite 개발자의 정책

SQLite 개발자는 버그가 보고되자마자, 보통 몇 시간 안에 SQLite의 모든 버그를 고쳐요. 수정은 공개 SQLite 소스 트리에서 즉시 이용 가능해요. 버그가 기존 애플리케이션에 문제를 일으킬 것 같으면 SQLite용 새 패치 릴리스가 발행돼요.

하지만 SQLite 개발자는 CVE를 추적하지 않아요. 여기에는 여러 이유가 있어요:

• 개발자들은 버그가 고쳐진 지 한참 후에 CVE에 대해 알게 되는 경우가 많아요. 이는 많은 CVE가 초기 보고에서 버그 수정을 언급한다는 사실에서 알 수 있어요.
• CVE는 대부분의 애플리케이션에 영향을 줄 것 같은 SQLite의 버그에 대한 낮은 품질의 정보 소스예요.
• CVE가 보고한 거의 모든 버그는 그냥 버그일 뿐 진정한 취약점이 아니에요. 그것들이 취약점이라고 주장하는 것은 "취약점"이라는 단어의 의미를 확대 해석하는 것이고, SQLite 개발자들은 그런 기만에 참여하고 싶지 않아요.
• 개발자들은 CVE 콘텐츠에 대한 편집 영향력이 없고, 목소리가 없는 그룹에 의해 통제되는 것을 좋아하지 않아요.

3. 최근 SQLite CVE의 상태

SQLite 개발자들은 CVE를 SQLite 버그에 대한 신뢰할 수 있는 정보 소스로 여기지 않지만, 많은 그룹, 특히 높은 관료 조직의 바닥에서 일하는 소규모 팀들이 CVE를 추적할 필요가 있음을 인정해요. 이 수고를 돕기 위해 SQLite에 영향을 주는 최근 CVE의 다음 표를 제공해요.

SQLite와 연관된 새 CVE가 아래 표에 없으면 SQLite Forum의 개발자들에게 알려서 추가되도록 해주세요.

참고: 아래 표에서 "Fix"는 버그를 수정한 버전을, "Comments"는 요약 설명을 나타내요. CVE 번호와 버전, 기술적 내용은 원문 그대로 보존했어요.

더 알아보기 (Learn more)

• Vulnerabilities (원문)
• Defense Against Dark Arts
• SQLite Forum