🇰🇷 한글 설명
리눅스 커널의 netfilter conntrack DCCP 구현에서 스택 버퍼 오버플로우 취약점이 발견되었습니다. DCCP 패킷 헤더를 처리할 때 기본 헤더 크기만 고려하여 버퍼를 할당함으로써, 추가적인 시퀀스 번호나 확장 헤더를 읽을 때 스택 범위를 벗어나는 메모리 읽기 오류가 발생합니다.
💡 쉬운 설명
네트워크 패킷을 처리하는 과정에서 데이터의 크기를 잘못 계산하여, 허용된 메모리 범위를 넘어선 데이터를 읽어들이는 보안 결함입니다. 이를 통해 시스템의 중요한 정보가 유출되거나 프로그램이 비정상적으로 종료될 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: dccp: copy entire header to stack buffer, not just basic one
Eric Dumazet says:
nf_conntrack_dccp_packet() has an unique:
dh = skb_header_pointer(skb, dataoff, sizeof(_dh), &_dh);
And nothing more is 'pulled' from the packet, depending on the content.
dh->dccph_doff, and/or dh->dccph_x ...)
So dccp_ack_seq() is happily reading stuff past the _dh buffer.
BUG: KASAN: stack-out-of-bounds in nf_conntrack_dccp_packet+0x1134/0x11c0
Read of size 4 at addr ffff000128f66e0c by task syz-executor.2/29371
[..]
Fix this by increasing the stack buffer to also include room for
the extra sequence numbers and all the known dccp packet type headers,
then pull again after the initial validation of the basic header.
While at it, mark packets invalid that lack 48bit sequence bit but
where RFC says the type MUST use them.
Compile tested only.
v2: first skb_header_pointer() now needs to adjust the size to
only pull the generic header. (Eric)
Heads-up: I intend to remove dccp conntrack support later this year.
📍 영향받는 시스템
DCCP 프로토콜을 사용하는 DCCP conntrack 기능이 활성화된 리눅스 커널 버전
⚔️ 공격 벡터
조작된 DCCP 패킷을 전송하여 커널의 nf_conntrack_dccp_packet 함수에서 스택 범위를 벗어난 메모리 읽기를 유도
🛡️ 대응 방법
DCCP 관련 커널 패치를 적용하거나, 커널 설정에서 DCCP conntrack 지원을 비활성화함
🔧 검증 코드
현재 실행 중인 커널 버전을 확인하여 취약점이 해결된 최신 보안 패치 버전인지 확인합니다.