Hello, I am K, and as a Red Hat contributor in my hobby, um I'm working on some security things in my office. I'd like to share my experiences and lessons learned from the Red Hat vulnerability reporting process and Red Hat Bugzilla. I will explain what it means for the

Red Hat to become a CNA and what I have experienced after CNA. Also, I will introduce the cicolor Bugzilla tool that has been extremely helpful in finding Red Hat vulnerabilities. Now, shall we talk about Red Hat CNA and CVE?

The Red Hat project became a CVE Numbering Authority (CNA) this year. Now, Red Hat's CVE team can directly assign CVE numbers. CVEs are assigned only after patches are released. The Red Hat CVE team has been assigning CVEs to bug fixes with careful

review. Vulnerability tracking is managed through a dedicated Git repository. This works to ensure more transparent security information for all Linux users. This is the repository address. Now, this is the redhat.com repository that manages Red Hat vulnerabilities, which I just explained in the previous slide, for those

interested in Red Hat development. We can see the names of notable Red Hat maintainers, Greg and Shash Rine, and their collaborative works in here. Looking at these common logs, you can see the review process for applied potential security patches is really

active. While observing the Red Hat CVE team's work, I noticed they follow this main process: proposed CVE announcement. The CVE team's documented process shows how vulnerability patches are reviewed and tracked for each version. Patches are organized into two sections: proposed patch under review

and complete patches in the dawn directory once the CB team completes their review they publish the patch and each assigned CB number to the mailing list the Rux Con CB announcements are published on the following mailing list address r.con.org Linux CB announ the right image

shows the mailing list filtered for s390 architecture you can see the two series I discovered I will explain this in more detail later slide this is some subscribing mailing list address let's explore how to find and Report Rux Conner vulnerabilities through the official Rux Conner security check

s the Conor security documentation explain the reporting process with this highlighted word it follows standard Pat submission but needs comprehensive details about the vulnerabilities I've learned a lot from two excellent resources created by respected Conor security researchers the and Google security team that offers valuable guidance of

this process I will share my journey of reporting my CB first and second Conor security bug including the challenges I faced while using a corner fer actually un Corner security um more related to user privilege in the context not the privilege context in the control playe

bug more us the plane bug this is first CB I've received this year late to the ud FD with UD FD poison when we utilizing this feature we can crash the ibmg renux system former mitigated version with user privileges this is my security report I

included as much detail as possible in my analysis but then lonus replied correcting my misunderstanding and providing a more general explanation in fact this is the first email I've received from lus cheers lonus refer to C color as a reproducer which we can discuss follow

further in the S color chapter he also shared a patch that prevents this crash issue.  Lus encouraged the involvement of people who are maintaining the subsystem s390 x390 architecture.  And then IBM maintainer Gerard replied with a detailed analysis with mitigation patch he had.

some brench code so I tested it with the same scenario and Gerald's patch successfully prevented this corner crash. I also asked questions about what I didn't understand.  Gerald provided more detailed explanations and directly questioned Lus and Greg as part of the normal B fix.

process. PR then GRE mentioned that this normal BG will receive a CB CBE cheers. So this is the CB announcement for this issue. The patch was applied but there was a gap of what two weeks before the announcement. This delay allowed for the back-porting to various

distributions. This is another CV that I discovered. This is also a crashy issue that a normal user can trigger in the IBM s390 architecture. The cornal code has trouble with an assumption that is not possible, but certain corner options can break this

assumption. This is the cor stch and there was a missing check for the memory page flag in the IBJ architectures memory management subsystem. Lonus also replied regarding this patch. He described it as a regular bug which refers to a programmatic oversight. This

is not a difficult bug that requires re-writing a subsystem. So the IBM s390 M maintainer fixed this code with a detailed patch message. Thank you, Heyo. So I tested it again with m a patch applied and this patch successfully prevented the crash. I

discovered finally the CV has been announced cheers I will introduce the L Corner folder let's get started what is Corner for the Corner uses system CES to connect user and Corner space and handle device communication through Network and Hardware protocols KOB provides code coverage information

for forging for each system core or collecting remote coverage information from Corner threads or soft IRQ context this feature maximizes testing effectiveness and Corner debugging features provide powerful tools for finding operations offering detailed bug detection with analyzable crash data Additionally Corner sanitizer uses

compiler features to detect runtime memory bugs and race conditions this is uh what is this Corner this is an automated system continuously testing the Corner while managing an efficient collection of the test cases from main code coverage you can refer to the link provided later for hands-on practice

this has this tool has a key Point interface based test generation smart Corpus management comprehensive crash analysis this is a bird's eye view of how Corner operates when C manager is executed on the management machine it runs finding processes on the target machine the folder management system collects the

and manages all the information generated during the finding process so this is the management process from the management machine and this is the target finding process this is the configuration files is read by C manager to control and manage the target machine this target machine a QEMU virtual

machine on 64 bit Linux runs three finding processes specifically testing SMB file system code by filtering coverage to fs/smv files and KMD functions restricting finding to only to CIS here is one CIS right in enable code coverage tracking for better finding

efficiency uses a single fing Target BM instance with four CPU cores and 4 GB of memory enable kbm acceleration and use host CPU model. This runs on my Raspberry Pi 5 in my home. We can fing Target with user mode with this

options here is the option about privilege and semi mode running as user, no body names space mode requiring configuration on the user ends in corner configuration. Corner folding helps companies comply with compliance requirements while avoiding penalty and reputation risk. As you know, SH has

some penalty fees. This is some this is a big deal, right? So this contributes to the company's product stabilities. Setting the sandbox to know allows operation with root privileges. This helps find many bugs, double for corner contribution. Bug fixing is meaningful work in itself as an open-source

contribution, right? And it's essential for becoming a ruxtype plumber. It is important to thoroughly check the mailing list for any existing related patching in the specific subsystem tree before proceeding. Corner folding using S color can be performed on isolated, immediate

systems with specific hardware configuration with P store. How is Google using it? Let's see Google's usage of C color through their dashboard and C color mailing list which show how they manage corner testing and bug reporting. This is the address of C Upstream dashboard and this is the

mailing list. Some of the development next bridge R stable BPF and some Google related branch. And this is open issue. So many bugs in here, right? We can see there are many corners on this dashboard, such as x86 risk 5, AR 64 with Google computer engine.

configuration oh there are so many new things right this is now and just a minute right so how can we for it these are the architectures I've worked with but there are still many architectures I haven't explored yet so I checked this sanitizer option can

enable in this architecture so we need to build some corner with the configuration and we need to some virtual machine QEMU KVM enabled or host CPU preferred because it's fast and prepare root file system I tested Yoko framark and also some Ubuntu Fedora image

within and we need some SSH key file so Google tested it with configuration so this is the first Dev configuration we we need Dev configuration right so there's some Dev configuration in Fedora and SSH dashboard with .config this is the dashboard of C-color

we can find corpus coverage supported the sces and crash this is reproduced bug SNP process ID in printable code in event function C this is patched last ring corner version so this is some generated reproducible bug this is a COR log from

this page this page Rog report this corner B that crash occurred we can we can see the parf event this is the C length log from each corpus made uh C-color makes some mutate some input this is the each system call and pH color make some arbitrary input for

this S system call how can we reproduce it we can reproduce in the Target motion with see exact Pro and scenario R made from the corpus with this previous slide additionally we can make source code from the previous C Lang log filtering testing to focus on

specific system core or device files. This is some tips when we're learning Cal t-marks, using t-marks for session liveness, and we prefer some best options in QMU. And this is some tip: sufficient disk size, etc. We can find information with col

source code, some filtering on the configuration file, make effective finding the Reus Corner PES, specify low P table file name. Each line of the file should be this format. We can have the C col to make more foring other corner programs or brand new corner

module. This is important: physical color needs some physical descriptions and pseudo system code. So I made it for the finding the KMBd subsystem, so C KMBd S W and S color will mutate this input in here, and this pseudo system code that input

the mutated argument from the C color. This is the C code that mapping with this, and I added the P system code in Lis score. Go file in S color. Let's review what I said first time, do you a little bit more clear about security reporting in this session?

If you didn't talk with me in other channels, and let's discuss more on this. I prepared some of my mistakes I encountered, encountered during my first attempt at security BG reporting. This patch has had several problems when we reproduce all this bug. We need root

privileges. This is an app Trace related bug according to Greg's feedback. There's a several issues with this security report: security mail and CB report should not be combined. The patch needs a fixed tag. The reported bug requires root privileges and are control plane issues.

that don't directly impact the system security and other try and error. I reported this bug through the following patches. The issue involves a double-free memory bug caused by a synchronization problem. According to Greg's feedback, security and CM should be kept separate, so secur.corner.org is a private mail

that's not publicly opened. Additionally, the following cases are unlikely to be considered security vulnerabilities: patches still in progress, Bluetooth issues that are in R-next, bugs requiring complex conditions that are difficult for regular users to reproduce, control bugs requiring elevated

privileges like root. That don't directly impact system security, fixing Corner warnings is good, but I recommend looking at the broader context of the subsystem. Simply focusing on the specific code for the security purpose without considering the context can be shortsighted. This is the summary in my session.

Thanks again for joining my session. Thank you.

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 보고서를 분리하세요.

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

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

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

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

스크립트