Red Hat Security Reporting: Experiences and Tools Overview

Red Hat의 CVE 팀은 CVE 번호를 직접 할당하고 취약점 추적 투명성을 개선하여 보안을 강화합니다.

### Red Hat의 취약성 보고 프로세스 및 Bugzilla에서 얻은 인사이트
* 🔒 레드햇의 기여자로서 **취약성 보고 프로세스와 레드햇 버그질라**를 사용하면서 얻은 경험과 교훈을 공유하고 있습니다.
* 📜 레드햇은 올해 **CVE 번호 지정 기관(CNA)** 이 되어 패치가 릴리스된 후에만 할당되는 **CVE 번호를 CVE 팀이 직접 할당**할 수 있게 되었습니다.
* 🔍 취약점 추적은 **전용 Git 리포지토리**를 통해 관리되어 모든 Linux 사용자에게 투명한 보안 정보를 제공하며, **저명한 관리자**가 검토 프로세스에 적극적으로 참여합니다.
* 📧 CVE 팀의 문서화된 프로세스에는 **제안된 CVE 공지와 함께 검토 및 완료를 위해 패치를 섹션별로 정리**한 다음 메일링 리스트를 통해 전달합니다.
* 🛠 저는 첫 번째와 두 번째 CVE를 보고하는 동안 **IBM GRENUX 시스템을 다운시킬 수 있는 사용자 권한 취약점** 등 여러 가지 문제에 직면했고, 유지 관리자로부터 건설적인 피드백을 받았습니다.
* 🔄 또한 IBM s390 아키텍처의 충돌 문제와 관련된 또 다른 CVE를 발견했는데, 이는 **유지 관리자의 협업 노력과 상세한 패치 메시지**를 통해 해결되었습니다.
* 💻 코드 커버리지 정보 및 충돌 분석 기능과 같은 기능을 강조하면서 **Red Hat 취약점을 찾는 데 중요한 역할**을 해온 **cicolor Bugzilla 도구**를 소개했습니다.
* 📊 마지막으로 일반적인 함정을 피하기 위해 취약점을 보고할 때 **철저한 문서화와 하위 시스템의 더 넓은 맥락**을 이해하는 것이 중요하다고 강조했습니다.

Head First Reporting of Linux Kernel CVEs  Practical Use of the Kernel Fuzzer  Yunseong Kim, Open Up

How To Be a Contributor

소개 및 레드햇의 CVE 번호 지정 기관(CNA) 현황

발표자 소개 및 주제 개요 Red Hat 취약성 보고 프로세스, Bugzilla 및 CNA 경험.

Red Hat이 CNA가 된 과정과 그 의미에 대해 설명합니다.

패치 릴리스 후 CVE 할당 프로세스 및 신중한 검토.

전용 Git 리포지토리 및 해당 주소를 통한 취약점 추적.

저명한 관리자가 참여하는 보안 패치에 대한 적극적인 검토 프로세스.

Red Hat의 CVE 프로세스 및 취약성 보고

주요 프로세스: 제안된 CVE 발표, 취약점 패치 검토 및 추적.

패치 구성(제안 및 완료) 및 메일링 리스트에 게시합니다.

공식 Red Hat 보안 점검을 통해 취약점을 찾아 보고합니다.

포괄적인 취약점 세부 정보가 필요한 표준 패치 제출.

발표자의 두 가지 Red Hat 보안 버그 보고 경험.

레드햇 보안 버그에 대한 개인 경험 보고

첫 번째 CVE: IBM s390 아키텍처의 충돌 문제, 사용자 권한으로 완화되었습니다.

Lonus의 피드백: 오해에 대한 정정 및 일반적인 설명 제공.

IBM 유지 관리자인 Gerald의 자세한 분석 및 완화 패치.

패치 테스트, 추가 설명 및 다른 관리자의 참여.

CVE 발표 및 다양한 배포판으로의 백포팅.

두 번째 CVE: 점검 누락으로 인한 IBM s390 아키텍처의 또 다른 충돌 문제입니다.

이 버그를 프로그래밍상의 문제라고 설명하는 Lonus의 피드백.

문제를 수정하는 패치 및 후속 CVE 발표.

취약점 발견을 위한 C-color 도구 소개

C-color에 대한 설명: 사용자와 커널 공간을 연결하고 디바이스 통신을 처리하는 시스템입니다.

기능: 코드 커버리지 정보, 디버깅 기능, 메모리 버그에 대한 살균제.

지속적인 테스트, 테스트 케이스 관리 및 충돌 분석을 위한 자동화된 시스템입니다.

C컬러 작업 개요: 관리 머신 및 대상 찾기 프로세스.

구성 파일, QEMU 가상 머신 및 프로세스 찾기.

다양한 옵션(사용자 모드, 권한 수준)을 사용하여 라즈베리 파이 5에서 C-color를 실행합니다.

C-color의 이점: 요구 사항 준수, 제품 안정성 및 버그 수정.

진행하기 전에 기존 패치에 대한 메일링 리스트 확인의 중요성.

특정 하드웨어 구성이 있는 격리된 시스템에서 C컬러 사용.

Google의 C-color 사용: 대시보드, 메일링 리스트 및 다양한 아키텍처.

아키텍처, 가상 머신 설정(QEMU KVM) 및 OS 이미지(Ubuntu, Fedora).

SSH 키 설정, 구성 파일 및 개발 환경.

C컬러 대시보드: 말뭉치 커버리지, 지원 아키텍처, 충돌 재현.

재현 가능한 버그 분석: 프로세스 ID, 코드 스니펫 및 패치 정보.

C-컬러 로그 분석: 시스템 호출, 임의 입력, 재생산 단계.

특정 시스템 호출이나 파일에 초점을 맞춰 C-컬러를 사용하여 버그를 재현합니다.

C-color 사용 팁: 세션 활성도, QEMU 옵션, 디스크 크기 등

구성 파일 필터링, 낮은 P 테이블 파일 이름 지정, C 색상 확장.

특정 하위 시스템에 대한 사용자 지정 C컬러 모듈 만들기(예: KMBd).

핵심 사항을 검토하고 추가 논의를 위한 초대를 보냅니다.

보안 버그 보고에서 얻은 교훈과 실수

초기 보안 버그 보고 시도 중 발생한 실수.

초기 보안 보고서의 문제: 보안 메일과 CVE 보고서의 결합, 고정 태그 누락, 루트 권한 필요.

이중 무료 메모리 버그 보고서에 대한 피드백: 보안 보고서와 CVE 보고서를 분리하세요.

보안 취약점으로 간주되지 않는 경우: 진행 중인 패치, 블루투스 문제, 복잡한 재생산 조건, 상승된 권한이 필요한 제어 버그.

보안 문제를 보고할 때 하위 시스템의 더 넓은 맥락을 고려하기 위한 요약 및 권장 사항입니다.