Perl 보안 보고 처리 정책

Perl 보안 보고 처리 정책 (perlsecpolicy)

Perl 프로젝트는 보안 이슈를 진지하게 다뤄요. 보안 보고를 시기적절하고 효과적으로 처리할 책임은 Perl 코어 개발자 일부로 구성된 보안 팀에 위임돼 있어요. 이 문서는 그 팀이 어떻게 운영되고, 새로운 보안 보고를 어떻게 평가하는지 설명해요.

출처: perldoc - perlsecpolicy

Perl 보안 이슈 신고하기 (REPORTING SECURITY ISSUES IN PERL)

Perl 인터프리터나 Perl 코어 코드베이스에서 관리되는 모듈에서 보안 취약점을 발견했다고 생각되면, 자세한 내용을 [email protected]로 이메일을 보내세요. 이 주소는 Perl 보안 팀이 모니터링하는 폐쇄 회원 메일링 리스트예요.

보고 후 72시간 안에 초기 응답을 받아야 해요. 그 시간 안에 응답이 없으면 Perl 운영 위원회(Steering Council)에 연락하세요.

보안 팀이 답장할 때는 대개 응답의 "To"나 "CC" 필드에 [email protected] 주소를 포함해요. 그래야 보안 팀 전체가 논의를 따라가고 필요할 때 끼어들 수 있어요. 후속 응답을 보낼 때는 이메일 클라이언트의 "Reply-all" 기능을 써서 보안 팀 전체가 메시지를 받게 하세요.

보안 팀은 보고를 평가하고, 팀이 다루는 이슈 범위에 맞을지 초기 판단을 내려요. 그 판단 기준의 일반 지침은 아래 "보안 이슈란 무엇인가" 절에 상세히 있어요.

보고가 팀 기준을 충족하면 CVE ID를 받게 돼요. 이슈 식별자는 CVE-YYYY-NNNNN 형태인데, YYYY는 CVE가 보고된 연도이고 NNNNN은 고유 번호예요. 후속 메시지에 이 식별자를 포함하세요.

보안 팀은 이슈 상태에 대한 주기적 업데이트를 보내고, 취약점 대응 절차를 완료하는 데 필요한 추가 조치를 안내해요. 취약점이 거치는 단계는 아래 "보안 이슈 처리 방법" 절에 설명돼 있어요.

보안 이슈란 무엇인가 (WHAT ARE SECURITY ISSUES)

취약점(vulnerability) 은 소프트웨어 시스템의 예상된 기밀성·무결성·가용성 보호를 손상시키는 동작이에요. 보안 이슈(security issue) 는 소프트웨어 시스템의 특정 구성 요소 하나 이상에서 취약점을 만들어내는 버그예요.

Perl로 작성된 소프트웨어는 보통 서로 다른 여러 집단이 만든 많은 소프트웨어 계층으로 이뤄져요. 복잡한 실제 애플리케이션에서 어떤 특정 계층이 취약한 동작을 막을 책임이 있었는지 판단하는 건 매우 복잡할 수 있는데, 이는 취약점을 고치는 데 필수적인 부분이에요.

Perl 보안 팀이 다루는 소프트웨어

Perl 보안 팀은 다음에서 보안 이슈를 처리해요:

Perl 인터프리터
인터프리터와 함께 배포되는 모듈 중 Perl 코어 저장소에서 개발된 것
인터프리터와 함께 배포되는 명령행 도구 중 Perl 코어 저장소에서 개발된 것

Perl 저장소와 릴리스 타르볼의 cpan/ 디렉터리 아래 파일들은 독립적으로 개발·유지보수돼요. Perl 보안 팀은 이 모듈들의 보안 이슈를 직접 처리하지 않지만, 이 코드가 Perl에 번들되어 있으므로 관련 유지보수자에게 이슈를 전달하는 것을 돕고, 그래도 비밀리에 보고할 수 있어요.

Perl에서 보안 이슈로 인정될 수 있는 버그

Perl은 빠르고 유연한 범용 프로그래밍 언어로 설계됐어요. Perl 인터프리터와 모듈은 안전하고 보안성 있는 애플리케이션을 쉽게 작성하게 해주지만, 한계가 있어요.

일반적으로 Perl의 버그가 보안 이슈로 간주되려면 다음 기준을 모두 충족해야 해요:

취약한 동작이 Perl 문서나 공개 이슈 트래커에 언급되지 않았을 것
취약한 동작이 예상된 동작에서 암시되지 않을 것
취약한 동작이 일반적으로 받아들여지는 구현의 한계가 아닐 것
취약한 동작이 그 외에는 안전한 Perl 애플리케이션에서 공격에 노출될 가능성이 있을 것
취약한 동작이 그것을 유발한 공격자에게 특정한 실질적 이득을 제공할 것

Perl에서 보안 이슈로 인정되지 않는 버그

보안 팀에 자주 보고되지만 위 기준에 맞지 않는 버그 범주들이 있어요. 흔히 보고되지만 보안 이슈로 취급되지 않는 버그 목록은:

인터프리터에 신뢰할 수 없는 코드를 먹이는 것 — Perl 파서는 신뢰할 수 없는 코드를 평가하도록 설계되지 않았어요. 애플리케이션이 신뢰할 수 없는 코드의 평가를 요구한다면, OS 수준 샌드박스에 보안을 의존해야 해요.
과도한 재귀로 인한 스택 오버플로 — 과도한 재귀는 종종 입력에 한계를 강제하지 않는 코드 때문에 생겨요. Perl 인터프리터는 재귀 한계가 애플리케이션에 의해 강제될 것이라고 가정해요.
메모리 부족 오류 — pack, x 연산자, 정규식 같은 흔한 Perl 구문은 중간 값이나 결과를 저장할 메모리 할당을 제어하는 숫자 수량자(quantifier)를 받아들여요. 공격자에게 이 수량자를 제공하게 하고 가용 메모리를 전부 소모하게 해도 Perl 인터프리터는 막지 않아요.
Safe 격실 탈출 — Opcode 제한과 Safe 격실은 보안 메커니즘으로 지원되지 않아요. Perl 파서는 신뢰할 수 없는 코드를 평가하도록 설계되지 않았어요.
p와 P pack 템플릿 사용 — 이 템플릿은 설계상 안전하지 않아요.
스택 비참조계수(stack not reference-counted) 이슈 — 이 버그는 대개 use-after-free 오류나 SV 타입에 대한 단언(assertion) 실패로 나타나요. 스택 비참조계수 크래시는 보통 코드가 참조나 glob을 수정하면서 동시에 그 glob·참조가 가리키는 값을 사용할 때 발생해요. 이 유형의 버그는 Perl 인터프리터의 오래된 이슈로 정상 코드에선 드물게 발생해요. 이 유형의 예는 대개 공격자가 공급한 코드가 Perl 인터프리터에 의해 평가된다고 가정해요.
Storable로 공격자 공급 데이터를 thaw — Storable은 매우 빠른 직렬화 형식으로 설계됐어요. 신뢰할 수 없는 입력을 역직렬화하는 데 안전하게 설계되진 않았어요.
공격자 공급 SDBM_File 데이터베이스 사용 — SDBM_File 모듈은 신뢰할 수 없는 SDBM 데이터베이스와 함께 쓰도록 의도되지 않았어요.
잘못 인코딩된 UTF-8 플래그 스칼라 — :utf8 PerlIO 레이어로 잘못 인코딩된 데이터를 읽거나, 다른 메커니즘으로 SV의 UTF-8 플래그를 직접 조작할 때 생기는 버그예요. 잘못 인코딩된 UTF-8 플래그 SV는 유효한 SV가 아니에요. 이런 식으로 SV를 만드는 코드는 Perl의 내부 상태를 손상시키는 거예요.
blead나 릴리스 후보에만 존재하는 이슈 — blead 브랜치와 Perl 릴리스 후보는 보안 지원을 받지 않아요. 사전 릴리스 버전에만 있는 보안 결함은 일반 버그 보고·해결 절차로 처리돼요.
CPAN 모듈이나 다른 Perl 프로젝트 리소스 — Perl 보안 팀은 Perl 인터프리터와 코어 코드베이스의 모듈에 집중해요. 팀은 CPAN 모듈·Perl 애플리케이션·Perl 프로젝트 웹사이트·메일링 리스트·IRC 서버를 고칠 특별한 접근 권한이 없어요.
Windows 시스템에서 에뮬레이션된 POSIX 동작 — Perl 인터프리터는 Windows에서 fork, system, exec 등 POSIX 동작을 에뮬레이션하려 해요. 이 에뮬레이션은 Perl의 공개 이슈 트래커에 광범위하게 문서화된 많은 특이점이 있어요. 이 동작을 바꾸면 Windows의 기존 사용자에게 상당한 혼란을 초래해요.

특별 분류가 필요한 버그

Perl 인터프리터의 일부 버그는 보안에 민감하면서도 정상 사용 중 실패하기 쉬운 코드 영역에서 발생해요.

정규식 — 신뢰할 수 없는 정규식은 몇 가지 주의사항과 함께 일반적으로 컴파일·매치하기 안전해요. 다음 Perl 정규식 엔진 동작은 개발자가 제한할 책임이 있어요:
- use re 'eval';이 적용 중일 때 신뢰할 수 없는 정규식을 평가하는 것은 절대 안전하지 않아요.
- 정규식이 특정 유한 시간 안에 컴파일·평가된다는 보장은 없어요.
- 정규식은 컴파일·평가 시 시스템 메모리를 모두 소모할 수 있어요.
- 정규식은 perl 인터프리터를 중단시키는 과도한 재귀를 일으킬 수 있어요.
- 일반적으로 Perl 정규식 엔진이 서비스 거부 공격에 견고하길 기대하지 마세요.
DB_File, ODBM_File, GDBM_File 데이터베이스 — 이 모듈들은 데이터베이스 파일과 상호작용하기 위해 외부 라이브러리에 의존해요. 이 파일 형식을 읽고 쓰면서 생기는 버그는 대개 기반 라이브러리 구현 때문에 생기며 Perl의 보안 이슈가 아니에요. Perl이 기반 라이브러리의 예상치 못한 유효 반환값을 잘못 처리하는 버그는 Perl의 보안 이슈로 인정될 수 있어요.
알고리즘 복잡도 공격 — perl 인터프리터는 알고리즘 복잡도 공격에 합리적으로 견고해요. 면역이진 아니지만요. 인터프리터가 극도로 많은 양의 공격자 공급 데이터를 처리하는 데 의존하는 알고리즘 복잡도 버그는 일반적으로 보안 이슈로 처리되지 않아요. 추가 정보는 perlsec의 "Algorithmic Complexity Attacks"를 참고하세요.

보안 이슈 처리 방법 (HOW WE DEAL WITH SECURITY ISSUES)

Perl 보안 팀은 책임 있는 공개(responsible disclosure) 관행을 따르고, 대부분의 사용자가 쉽게 고칠 수 있을 때까지 보안 이슈를 비밀로 유지해요. 이는 사용자가 Perl 취약점으로 겪는 내재적 위험을 최소화해요.

문제를 사용자에게 잠시 숨기는 것은 그들을 안전하게 지키기 위해 필요한 트레이드오프예요. 문제를 영구히 숨기는 게 목표는 아니에요.

[email protected]에 사적으로 보안 이슈를 보고할 때 팀은 대개 보고 처리에서 책임 있는 공개 관행을 따를 것을 기대해요. 사용자에게 수정이 제공될 때까지 이슈를 비밀로 유지할 수 없거나 원하지 않으면, 초기 보고에 이를 명확히 밝혀야 해요.

보안 팀의 취약점 대응 워크플로는 보안 보고 상태에 대해 가능한 한 개방적이고 투명하도록 설계됐어요.

Perl의 취약점 대응 워크플로

초기 연락 (Initial contact) — 새 취약점 보고는 보안 팀 메일링 리스트에 도착한 시점부터 72시간 안에 초기 답장을 받아요. 그 시간 안에 응답이 없으면 Perl 운영 위원회에 연락하세요. 초기 응답은 메시지를 받았다는 확인과 트리아지 분석의 예상 기간을 알려줘요.
초기 트리아지 (Initial triage) — 보안 팀이 보고를 평가해 보안 이슈로 처리할 기준에 맞을지 결정해요. 초기 보고 트리아지를 2주 안에 완료하는 것을 목표로 해요. 상당한 논의나 조사가 필요한 복잡한 이슈는 더 오래 걸릴 수 있어요. 보고를 재현할 수 없거나 팀 기준에 맞지 않으면 이메일로 통보받고 응답할 기회를 받아요.
CVE 할당 (CVE assignment) — 초기 트리아지를 통과한 보고는 CVE로 전환돼요. 이 단계에 이르면 팀이 CVE를 하나 이상 예약해요. 식별자는 CVE-YYYY-NNNNN 형태예요. CVE ID 부여가 그 보고가 Perl의 취약점임을 확정하는 건 아니에요. 많은 보고는 그 판단에 더 많은 분석이 필요해요. 이 단계에서 취약점을 공개적으로 논의하면 안 돼요. 내부 티켓도 열리는데, perl-security#NNN 또는 Perl/perl-security#NNN 형식이에요. 보안 팀의 비공개 트래커의 이슈들은 문제의 세부사항을 모으고 해결 진행을 추적하는 데 쓰여요. 이슈가 해결돼도 이 메모가 공개되진 않아요. 노트를 비공개로 유지하면 팀이 공격 방법·공격 도구·관련 비공개 이슈를 자유롭게 논의할 수 있어요.
패치 개발 (Development of patches) — 팀원들이 보고와 관련 코드를 자세히 조사해 지원되는 Perl 버전용 수정을 만들어요. 이 단계에서 보고가 팀 기준에 맞지 않음을 발견하면 이메일로 통보하고, 이슈가 닫히기 전 응답할 기회를 받아요. 팀은 잠재 수정을 논의하거나 테스트용 패치를 제공할 수 있어요.
CVE 초안 (The CVE is drafted) — 이슈가 완전히 확인되고 잠재 수정이 발견되면 팀은 CPAN Security Group CNA와 소통해요. 취약한 Perl 버전 범위, 결함을 발견한 사람 정체 같은 세부사항을 수집해야 해요. 팀은 발견을 공로로 인정할 때 쓸 정확한 이름을 명확히 해달라고 요청할 수 있어요.
사전 릴리스 알림 (Pre-release notifications) — 팀이 수정을 공개할 준비가 됐다 싶으면 Openwall Distros List로 사전 릴리스 알림을 보내고, 추가 재패키저들에게도 알려요. 참고: Openwall Distros List에 보낸 임바고 정보는 공개 후 2주 내에 만료돼요. 사전 릴리스 알림에는 영향을 받는 Perl 버전 목록, 사용자 위험 분석, 팀이 만든 패치, 완화/백포트 정보가 포함돼요. 그리고 이슈가 공개될 특정 목표 날짜가 포함돼요. 이 기간 동안 취약점 세부사항과 수정은 임바고되고 공개 공유하면 안 돼요. 테스트에서 문제가 발견되면 이 "임바고 기간"이 더 연장될 수 있어요. 자신이 보고한 이슈와 관련된 사전 릴리스 알림 부분을 받게 되는데, 목표 릴리스 날짜가 포함돼요.
사전 릴리스 테스트 (Pre-release testing) — Perl 보안 팀이 공식 Perl 릴리스를 직접 만들진 않아요. 팀은 Perl의 공개 git 저장소에 커밋을 넣고 알림을 보내는 방식으로 보안 수정을 릴리스해요. 많은 사용자·재패키저가 옛 릴리스에 패치를 적용하는 것보다 공식 Perl 릴리스를 선호해요. 팀은 Perl 릴리스 매니저와 협력해 이를 가능하게 해요. 새 공식 Perl 릴리스는 대개 사전 릴리스 "임바고 기간" 동안 사설 시스템에서 제작·테스트돼요.
수정과 알림 릴리스 (Release of fixes and announcements) — 보안 수정이 Perl 공개 git 저장소에 커밋되면 "임바고 기간"이 끝나요. perl5-porters와 oss-security 메일링 리스트로 알림이 보내져요. 공식 Perl 릴리스가 준비됐다면 그 시점에 발표되고 perl5-porters에서 공지돼요. 팀은 릴리스가 끝나면 사전 릴리스 "임바고 기간"에 참여한 모든 사람에게 후속 알림을 보내요. 취약점 보고자와 Perl 재패키저는 팀의 릴리스가 완료될 때까지 자기만의 알림이나 수정을 발표하면 안 돼요.

공개적으로 알려진 제로데이 보안 이슈

보안 팀의 워크플로는 이슈가 사적으로 보고되고 해결될 때까지 비밀로 유지된다고 가정해요. 항상 그런 건 아니고, 수정이 준비되기 전 정보가 새어나가기도 해요. 이런 상황에서 팀은 비밀로 운영하는 것이 Perl 사용자의 위험을 줄이는지 늘리는지 판단해야 해요. 어떤 경우에는 보안 이슈가 만드는 위험에 대해 개방적인 것이 사용자가 방어하게 해주고, 다른 경우에는 해결 안 된 보안 이슈에 주목을 끄는 것이 오용 가능성을 높여요.

제로데이 보안 이슈 (Zero-day security issues) — 해결되지 않은 심각한 Perl 보안 이슈가 시스템 공격에 적극적으로 악용되고 있다면, 팀은 가용한 완화 조치와 함께 가능한 한 빨리 알림을 보내요. Perl 공개 결함 트래커로 이슈를 처리해서 추가 정보·수정·CVE ID가 영향을 받는 사용자에게 가능한 한 빨리 보이게 해요.
다른 보안 이슈 정보 유출 (Other leaks) — 드러난 정보의 중요도와 제로데이 공격이 될 위험에 따라 팀은 정상 워크플로의 일부 또는 전체를 건너뛸 수 있어요. 공개 트래커에서 이슈가 식별·해결된 뒤에 팀이 중요한 보안 이슈를 알게 되면 CVE ID를 요청하고 사용자에게 알리는 알림을 보내요.

취약점 공로와 현상금 (Vulnerability credit and bounties)

Perl 프로젝트는 보안 연구자들이 Perl을 안전하게 만드는 데 투자한 노력을 고맙게 여겨요. 이 작업의 상당 부분이 공개에서 숨겨져 있으므로, 연구자를 공개적으로 공로로 인정하는 것이 취약점 대응 절차의 중요한 부분이에요.

취약점 알림에서의 공로 — 보안 이슈가 수정되면 알림에서 결함을 발견한 특정 연구자를 공로로 인정하려 해요. 연구자가 선호하는 전체 이름으로 발표해요. 기여가 특정 회사가 자금을 댔거나 조직적 취약점 연구 프로젝트의 일부라면, 연구자 요청에 따라 그 집단의 짧은 이름을 포함해요. Perl 알림은 다양한 형식으로 재현 가능하도록 7bit ASCII 문자 집합의 영어로 작성돼요. 이 인정에 하이퍼링크·도메인 이름·마케팅 자료는 포함하지 않아요. 발견 공로를 제대로 확립할 수 없거나 팀과 연구자 간에 합의가 안 되면 알림에서 생략돼요.
Perl 취약점 현상금 (Bounties) — Perl 프로젝트는 비영리 자원봉사 노력이에요. Perl 보안 이슈 보고에 금전적 보상은 제공하지 않아요.

임바고 기간 (Embargo Period)

Perl의 조정된 취약점 공개 절차에서 "임바고"란 보고된 취약점에 대한 정보가 기밀로 유지되는 기간을 뜻해요. 보안 이슈가 Perl 보안 팀에 보고될 때 시작해, 수정이 개발되고 공개 위치에 수정이 제공될 때까지 지속돼요.

임바고의 목적은 팀이 취약점이 조기에 악용·공개될 위험 없이 수정을 만들고 조정된 릴리스를 준비하게 하는 거예요. 이는 보안 이슈가 처리되는 동안 Perl과 모듈 사용자가 잠재 공격으로부터 보호되게 해줘요.

임바고 길이는 이슈 복잡도와 수정 개발 시간에 따라 달라져요. 팀은 보고자와 관련 당사자에게 예상 임바고 기간을 알려줘요.

목표로 총 임바고 기간을 60일 미만으로 유지하려 해요. 다음 요인 때문에 연장될 수 있어요:

이슈의 복잡성
수정 개발에 필요한 시간
추가 테스트·검증의 필요
이슈 해결에 사용할 수 있는 자원
최종 사용자가 수정을 적용하는 능력에 영향을 줄 수 있는 공휴일

이 기간 동안:

취약점 세부사항은 신뢰할 수 있는 소수 기여자(코어 유지보수자·툴체인 유지보수자·패키저 등)에게만, 수정 준비·테스트 목적으로만 공유돼요.
보고자는 임바고가 해제될 때까지 이슈를 공개적으로 밝히거나 제3자와 공유하지 않도록 요청받아요.
임바고 기간은 이슈의 심각도와 복잡도에 따라 달라질 수 있지만, 대개 관련 보안 패치가 릴리스·공지될 때까지 지속돼요.
임바고를 깨는 것(조기 공개)은 조정된 공개 절차를 훼손하고 사용자를 효과적으로 보호하려는 공동 노력을 방해할 수 있어요.

Perl 보안 팀은 취약점을 신속히 해결하려 하고, 사용자와 하류 배포판을 보호하기 위해 모든 당사자가 임바고 기간을 존중하도록 권장해요.

릴리스 절차 예시 (Example Release Process)

제3자가 보고한 보안 이슈가 초기 보고부터 최종 릴리스까지 어떻게 처리될 수 있는지 예시로 보여드릴게요.

취약점 보고 (Reporting) — 보안 연구자가 특정 조건에서 서비스 거부를 일으키게 하는 Perl 인터프리터 취약점을 발견해요. 개념 증명 스크립트와 영향 설명을 포함해 [email protected]로 보내요.
초기 응답 (Initial Response) — 72시간 안에 팀이 보고 수신을 확인하고 이슈가 조사 중임을 알려줘요. 트리아지 예상 일정도 알려줘요.
초기 트리아지 (Initial Triage) — 팀이 개념 증명으로 이슈를 재현하고, 보안 이슈 기준에 맞는다고 판단해요. CPAN Security Group CNA와 조정해 CVE를 하나 이상 예약해요. 팀이 CVE ID를 참조하며 보고자에게 알려요.
수정 개발 (Development of a Fix) — 팀이 영향을 받는 코드를 분석하고 취약점을 해결하는 패치를 개발해요. 회귀 없이 이슈를 해결하는지 다양한 시나리오로 테스트해요. 보고자가 사적으로 패치를 테스트하고 피드백하도록 초대해요.
사전 릴리스 알림 (Pre-Release Notification) — 팀이 취약점 세부사항·영향 버전·패치를 포함한 사전 릴리스 알림을 준비해요. 임바고 하에 Perl의 주요 재패키저에게 보내 자기 업데이트를 준비할 시간을 줘요.
사전 릴리스 테스트 (Pre-Release Testing) — 남은 임바고 동안 사전 통보된 재패키저들이 릴리스 패키지를 준비하고 패치를 시스템 호환성과 함께 테스트해요.
공개 릴리스 (Public Release) — 예정된 릴리스 날짜에 패치가 Perl 공개 git 저장소에 커밋돼요. perl5-porters와 oss-security 리스트로 공식 알림이 보내져요. 해당되면 수정이 든 새 Perl 릴리스가 발표돼요. 팀이 CPAN Security Group CNA에 CVE 발행을 알려요.
벤더·제3자 업데이트 (Vendor and Third-Party Updates) — 벤더와 제3자 유지보수자가 패치나 갱신된 Perl 릴리스를 배포판에 통합해요. 팀이 관련 당사자 모두에게 후속하여 이슈가 해결되고 사용자가 보호되는지 확인해요.

더 알아보기 (Learn more)

perlsec — Perl 보안 (taint 모드, 보안 메커니즘)
perlsecpolicy(원문) — Perl 보안 팀 운영·보고 정책 전체