요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
Stable release fix를 기준으로 자동 배정
cve.rst:27-64정상 stable release 과정에서 CVE team이 security 영향 가능성이 있는 fix를 식별해 번호를 자동 배정하고 자주 announcement한다. Kernel은 system의 낮은 layer에 있어 평범해 보이는 bug도 exploit 가능성이 나중에 드러날 수 있으므로 team은 보수적으로 많은 bugfix에 번호를 붙인다.
이미 released stable tree에 들어간 fix가 누락됐다고 판단하면 cve@kernel.org에 요청한다. 이 주소는 미수정 취약점 보고용이 아니다. Unfixed issue는 security bug reporting 절차를 따른다.
자동 배정은 fix가 stable tree에 적용되고 original fix commit ID로 추적 가능해진 뒤에만 한다. Fix 전에 reserved identifier가 꼭 필요하면 CVE team에 별도로 요청할 수 있다. Stable/LTS team이 현재 지원하지 않는 kernel version의 issue에는 kernel team이 CVE를 배정하지 않는다.
배정 이의와 수정 권한
cve.rst:66-77특정 kernel 변경에 배정된 CVE의 범위와 타당성을 다투거나 수정할 권한은 영향받는 subsystem maintainer에게 있다. 해당 code의 실제 reachability와 configuration, fix 범위를 깊이 아는 maintainer가 판단해야 잘못된 축소나 확대를 막을 수 있다.
Distribution 전용 issue와 잘못된 CVE
cve.rst:79-93Distribution이 자체 변경으로 만든 issue 또는 kernel.org 지원이 끝난 version을 distribution만 유지하면서 생긴 issue는 해당 distribution에 CVE를 요청한다. Kernel CVE team의 범위가 아니다.
현재 지원 kernel에 대해 kernel assignment team 이외의 조직이 배정한 kernel CVE는 valid한 kernel CVE로 취급하지 말고 cve@kernel.org에 알려 CNA remediation 절차로 정리한다.
내 system에 해당하는지는 사용자가 판단한다
cve.rst:95-120Linux는 configuration, hardware, external access와 enabled subsystem이 system마다 달라 CVE team이 특정 제품에 해당하는지 판단할 수 없다. 전체 source 중 실제 build·실행되는 부분은 일부이므로 많은 CVE가 개별 system에는 무관할 수 있다.
그렇더라도 개별 CVE fix만 골라 cherry-pick하기보다 함께 test된 released kernel update 전체를 적용하는 것이 최선이다. 하나의 문제를 여러 연속 fix가 완성할 수 있고 CVE가 붙지 않은 관련 변경도 있을 수 있다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
====
CVEs
====
Common Vulnerabilities and Exposure (CVE®) numbers were developed as an
unambiguous way to identify, define, and catalog publicly disclosed
security vulnerabilities. Over time, their usefulness has declined with
regards to the kernel project, and CVE numbers were very often assigned
in inappropriate ways and for inappropriate reasons. Because of this,
the kernel development community has tended to avoid them. However, the
combination of continuing pressure to assign CVEs and other forms of
security identifiers, and ongoing abuses by individuals and companies
outside of the kernel community has made it clear that the kernel
community should have control over those assignments.
The Linux kernel developer team does have the ability to assign CVEs for
potential Linux kernel security issues. This assignment is independent
of the :doc:`normal Linux kernel security bug reporting
process<../process/security-bugs>`.
A list of all assigned CVEs for the Linux kernel can be found in the
archives of the linux-cve mailing list, as seen on
https://lore.kernel.org/linux-cve-announce/. To get notice of the
assigned CVEs, please `subscribe
<https://subspace.kernel.org/subscribing.html>`_ to that mailing list.
Process
=======
As part of the normal stable release process, kernel changes that are
potentially security issues are identified by the developers responsible
for CVE number assignments and have CVE numbers automatically assigned
to them. These assignments are published on the linux-cve-announce
mailing list as announcements on a frequent basis.
Note, due to the layer at which the Linux kernel is in a system, almost
any bug might be exploitable to compromise the security of the kernel,
but the possibility of exploitation is often not evident when the bug is
fixed. Because of this, the CVE assignment team is overly cautious and
assign CVE numbers to any bugfix that they identify. This
explains the seemingly large number of CVEs that are issued by the Linux
kernel team.
If the CVE assignment team misses a specific fix that any user feels
should have a CVE assigned to it, please email them at <cve@kernel.org>
and the team there will work with you on it. Note that no potential
security issues should be sent to this alias, it is ONLY for assignment
of CVEs for fixes that are already in released kernel trees. If you
feel you have found an unfixed security issue, please follow the
:doc:`normal Linux kernel security bug reporting
process<../process/security-bugs>`.
No CVEs will be automatically assigned for unfixed security issues in
the Linux kernel; assignment will only automatically happen after a fix
is available and applied to a stable kernel tree, and it will be tracked
that way by the git commit id of the original fix. If anyone wishes to
have a CVE assigned before an issue is resolved with a commit, please
contact the kernel CVE assignment team at <cve@kernel.org> to get an
identifier assigned from their batch of reserved identifiers.
No CVEs will be assigned for any issue found in a version of the kernel
that is not currently being actively supported by the Stable/LTS kernel
team. A list of the currently supported kernel branches can be found at
https://kernel.org/releases.html
Disputes of assigned CVEs
=========================
The authority to dispute or modify an assigned CVE for a specific kernel
change lies solely with the maintainers of the relevant subsystem
affected. This principle ensures a high degree of accuracy and
accountability in vulnerability reporting. Only those individuals with
deep expertise and intimate knowledge of the subsystem can effectively
assess the validity and scope of a reported vulnerability and determine
its appropriate CVE designation. Any attempt to modify or dispute a CVE
outside of this designated authority could lead to confusion, inaccurate
reporting, and ultimately, compromised systems.
Invalid CVEs
============
If a security issue is found in a Linux kernel that is only supported by
a Linux distribution due to the changes that have been made by that
distribution, or due to the distribution supporting a kernel version
that is no longer one of the kernel.org supported releases, then a CVE
can not be assigned by the Linux kernel CVE team, and must be asked for
from that Linux distribution itself.
Any CVE that is assigned against the Linux kernel for an actively
supported kernel version, by any group other than the kernel assignment
CVE team should not be treated as a valid CVE. Please notify the
kernel CVE assignment team at <cve@kernel.org> so that they can work to
invalidate such entries through the CNA remediation process.
Applicability of specific CVEs
==============================
As the Linux kernel can be used in many different ways, with many
different ways of accessing it by external users, or no access at all,
the applicability of any specific CVE is up to the user of Linux to
determine, it is not up to the CVE assignment team. Please do not
contact us to attempt to determine the applicability of any specific
CVE.
Also, as the source tree is so large, and any one system only uses a
small subset of the source tree, any users of Linux should be aware that
large numbers of assigned CVEs are not relevant for their systems.
In short, we do not know your use case, and we do not know what portions
of the kernel that you use, so there is no way for us to determine if a
specific CVE is relevant for your system.
As always, it is best to take all released kernel changes, as they are
tested together in a unified whole by many community members, and not as
individual cherry-picked changes. Also note that for many bugs, the
solution to the overall problem is not found in a single change, but by
the sum of many fixes on top of each other. Ideally CVEs will be
assigned to all fixes for all issues, but sometimes we will fail to
notice fixes, therefore assume that some changes without a CVE assigned
might be relevant to take.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Linux kernel과 CVE 번호
1-25Common Vulnerabilities and Exposures(CVE®) 번호는 공개된 보안 취약점을 모호함 없이 식별하고 정의해 목록화하기 위해 만들어졌다. 그러나 kernel project에서는 부적절한 방식이나 이유로 CVE가 할당되는 일이 잦아지면서 시간이 지날수록 유용성이 떨어졌다. 이 때문에 kernel 개발 community는 CVE 사용을 피하는 경향이 있었다.
그럼에도 CVE와 다른 보안 식별자를 할당하라는 압력은 계속되었고, kernel community 밖의 개인과 회사가 제도를 오용하는 일도 이어졌다. 그 결과 kernel community가 Linux kernel 관련 CVE 할당을 직접 통제해야 한다는 점이 분명해졌다.
Linux kernel developer team은 잠재적인 Linux kernel 보안 문제에 CVE를 할당할 수 있다. 이 할당 절차는 Documentation/process/security-bugs.rst에 설명된 일반 보안 버그 보고 절차와 독립적이다.
Linux kernel에 할당된 모든 CVE 목록은 https://lore.kernel.org/linux-cve-announce/ 의 linux-cve mailing list archive에서 확인할 수 있다. 새 할당 통지를 받으려면 https://subspace.kernel.org/subscribing.html 안내에 따라 해당 list를 구독한다.
CVE 할당 절차
27-59일반 stable release 절차 중 CVE 번호 할당 담당 developer가 잠재적인 보안 문제와 관련된 kernel 변경을 식별하고 CVE 번호를 자동으로 할당한다. 할당 결과는 linux-cve-announce mailing list에 수시로 공지된다.
Linux kernel은 시스템의 낮은 계층에 있으므로 거의 모든 버그가 kernel 보안을 침해하는 데 악용될 가능성이 있다. 하지만 버그를 수정하는 시점에는 그 악용 가능성이 분명하지 않은 경우가 많다. 이 때문에 CVE assignment team은 의도적으로 보수적인 기준을 적용하고 식별한 bugfix에 CVE를 할당한다. Linux kernel team이 발행하는 CVE 수가 겉보기에 매우 많은 이유가 여기에 있다.
CVE assignment team이 특정 fix를 놓쳤고 사용자가 그 fix에 CVE가 필요하다고 판단한다면 cve@kernel.org로 연락한다. 이 주소는 이미 release된 kernel tree에 포함된 fix의 CVE 할당만을 위한 곳이다. 아직 수정되지 않은 잠재적 보안 문제를 이 주소로 보내서는 안 되며, 그런 문제는 일반 Linux kernel 보안 버그 보고 절차를 따라야 한다.
수정되지 않은 Linux kernel 보안 문제에는 CVE를 자동으로 할당하지 않는다. 자동 할당은 fix가 준비되어 stable kernel tree에 적용된 뒤에만 이루어지며 original fix의 git commit ID를 기준으로 추적한다. Commit으로 해결되기 전에 CVE가 필요하다면 cve@kernel.org에 연락해 assignment team이 보유한 예약 identifier 중 하나를 요청할 수 있다.
지원 중인 kernel과 이의 제기 권한
61-77Stable/LTS kernel team이 현재 적극적으로 지원하지 않는 kernel version에서 발견된 문제에는 Linux kernel CVE team이 CVE를 할당하지 않는다. 현재 지원 중인 kernel branch 목록은 https://kernel.org/releases.html 에서 확인할 수 있다.
특정 kernel 변경에 할당된 CVE에 이의를 제기하거나 내용을 수정할 권한은 영향받는 subsystem의 maintainer에게만 있다. 해당 subsystem에 관한 깊은 전문 지식과 내부 동작에 대한 이해가 있어야 보고된 취약점의 유효성과 범위를 평가하고 적절한 CVE 지정을 결정할 수 있기 때문이다.
지정된 권한 밖에서 CVE를 수정하거나 다투면 혼란과 부정확한 보고가 생기고, 결과적으로 실제 시스템의 보안을 약화시킬 수 있다.
유효하지 않은 CVE
79-93Distribution이 자체적으로 가한 변경 때문에 발생했거나 kernel.org가 더 이상 지원하지 않는 version을 distribution이 계속 지원하기 때문에 발생한 문제라면 Linux kernel CVE team은 CVE를 할당할 수 없다. 이 경우 해당 Linux distribution에 직접 요청해야 한다.
현재 적극적으로 지원되는 Linux kernel version에 대해 kernel CVE assignment team이 아닌 다른 조직이 할당한 CVE는 유효한 것으로 취급해서는 안 된다. 이런 항목을 발견하면 cve@kernel.org로 알린다. Kernel team은 CNA remediation 절차를 통해 해당 항목을 무효화하는 작업을 진행한다.
특정 CVE가 시스템에 적용되는지 판단하기
95-120Linux kernel은 외부 사용자의 접근 방식이 서로 다른 매우 다양한 시스템에서 사용되며, 외부 접근이 전혀 없는 시스템도 있다. 따라서 특정 CVE가 실제 시스템에 적용되는지는 Linux 사용자가 판단해야 하며 CVE assignment team이 판단할 일이 아니다. 특정 CVE의 적용 여부를 판정해 달라는 요청을 team에 보내서는 안 된다.
Kernel source tree는 매우 크지만 하나의 시스템은 그중 작은 일부만 사용한다. 따라서 할당된 CVE가 많더라도 상당수는 해당 시스템과 관련이 없을 수 있다. Assignment team은 개별 사용 사례와 실제로 사용하는 kernel 부분을 알지 못하므로 특정 CVE의 관련성을 대신 판정할 수 없다.
항상 개별 변경을 cherry-pick하기보다 release된 kernel 변경 전체를 적용하는 것이 가장 좋다. Release 전체는 많은 community 구성원이 하나의 통합된 결과물로 함께 시험하기 때문이다. 또한 여러 버그의 완전한 해결책은 단일 변경이 아니라 서로 쌓이는 여러 fix의 합으로 이루어진다.
이상적으로는 모든 문제의 모든 fix에 CVE가 할당되어야 하지만 team이 일부 fix를 놓칠 수 있다. 따라서 CVE가 없는 변경 중에도 시스템에 적용해야 할 중요한 변경이 있을 수 있다고 가정해야 한다.
Kernel community가 CVE를 직접 배정하는 이유
cve.rst:2-25CVE는 공개된 취약점을 명확히 식별하기 위해 만들어졌지만 kernel에는 부적절한 이유와 범위로 번호가 배정되는 일이 반복됐다. 외부 개인과 회사의 오용을 줄이고 실제 source history와 맞추기 위해 Linux kernel developer team이 잠재적 kernel security issue의 CVE를 직접 배정한다.
CVE 배정은 unfixed security bug를 비공개로 고치는 security@kernel.org 절차와 별개다. 배정 결과는 linux-cve-announce archive에 게시된다.