OVHcloud가 대대적인 재부팅을 시작하기 전, KernelCare가 Januscape에 어떻게 패치를 적용했는지

주요 요점:

• OVHcloud는 11일 동안 수만 대의 호스트를 재부팅하여 Januscape에 대한 패치를 적용했으며, 이 과정에서 실제 서비스 중단, 하드웨어 장애가 발생했고 전 세계적 위기 대응 태스크포스가 가동되었습니다.
• KernelCare는 7월 8일 OVH의 첫 번째 재부팅 단계가 시작되기 전인 7월 7일부터 메인 피드를 통해, 필요한 두 가지 Januscape 수정 사항을 ‘라이브 패치’라고도 불리는 재부팅이 필요 없는 패치 형태로 제공했습니다.
• 재부팅 기반 패치 적용 방식은 해당 호스트가 재부팅 슬롯에 도달할 때까지 취약한 상태로 남아 있는 반면, 재부팅 없이 적용되는 패치 방식은 패치가 적용되는 즉시 취약점이 노출되는 기간을 차단합니다.

OVHcloud는 호스팅 업계에서 수년 만에 볼 수 있는 가장 솔직한 인프라 사후 분석 보고서 중 하나를 발표했습니다.

CVE-2026-53359로 추적된 ‘Januscape’ 취약점을 해결하기 위해, 해당 기업은 약 100만 대의 가상 머신을 지원하는 수만 대의 KVM 호스트에 패치를 적용하고 시스템을 재부팅했습니다. 이 작업은 전 대륙에 걸쳐 진행되었으며, 연중무휴 24시간 위기 대응이 필요했고, 완료하는 데 11일이 소요되었습니다.

더 레지스터(The Register) 가 이 캠페인을 보도했습니다. 대규모 가상화 인프라를 관리하는 담당자라면 OVHcloud가 발표한 전체 사후 분석 보고서를 꼭 읽어볼 가치가 있습니다.

운영 측면에서 볼 때, 이 사례는 정말 인상적입니다. OVHcloud 팀은 신속하게 대응하고, 압박 속에서도 장애를 잘 처리했으며, 그 결과를 유례없이 투명하게 기록해 두었습니다.

인프라 관련 사안으로서, 이는 더 어려운 문제를 제기한다.

커널 수정 사항 하나를 적용하는 데 왜 전 시스템 재부팅 작업이 필요했나요?

반면, KernelCare가 지원하는 플랫폼의 경우, OVH가 첫 번째 호스트를 재시작하기 전부터 재부팅이 필요 없는 Januscape 수정 사항이 이미 메인 패치 피드에 반영되어 있었습니다. 구독 중인 플릿은 일반적인 업데이트 주기에 따라 이를 적용받았습니다. 재부팅도, 서비스 중단도, 별도의 캠페인도 필요하지 않았습니다.

두 문장으로 보는 자누스케이프

Januscape는 KVM의 x86 섀도 메모리 관리 코드에 존재하는 ‘use-after-free’ 취약점입니다. 게스트 가상 머신 내에서 루트 권한을 가진 공격자는 이 취약점을 악용하여 호스트를 다운시키고, 잠재적으로 호스트 수준의 권한으로 코드를 실행할 수 있습니다.

이 취약점은 인텔 및 AMD 시스템에 영향을 미치며, 약 16년 동안 리눅스 커널에 존재해 왔습니다. 이를 수정하려면 CVE-2026-53359 및 CVE-2026-46113과 관련된 두 가지 상호 연관된 업스트림 수정 사항이 필요합니다.

당사의 기술적 Januscape 분석은 취약점, 악용 경로 및 필요한 수정 사항을 상세히 다룹니다.

또한, 이 CVE에 대해 더 자세히 읽어보는 것보다 두 전문가가 이를 논의하는 내용을 직접 들어보시는 것을 선호하신다면, 해당 취약점을 상세히 분석하는 라이브 스트리밍도 진행했습니다. .

지금 읽고 계신 기사는 운영 법안에 관한 내용입니다.

재부팅을 필요로 하는 패치 작업

아래의 모든 내용은 OVH의 사후 분석 보고서와 더 레지스터(The Register)의 기사에서 발췌한 것입니다. 이 중 어느 것도 추측이 아닙니다.

OVHcloud는 시드니에서 먼저 배포 절차를 테스트했습니다. 이 지역은 상대적으로 작은 규모를 갖추고 있었으며, 야간 수요가 적고, 유럽 팀의 근무 시간 내에 지원이 가능했습니다. 운영 매뉴얼이 검증된 후, ‘follow-the-sun’ 운영 방식을 통해 전 세계적으로 재부팅 작업이 순차적으로 진행되었습니다.

이 과정은 단순히 커널 패키지를 설치하고 서버를 재시작하는 것보다 훨씬 더 복잡한 작업이었습니다. 재부팅 파도는 중단 기준에 따라 제어되었습니다. OVHcloud는 고밀도 리전에서 15대의 호스트가 동시에 다운되거나, 그 외 지역에서 5대가 다운될 경우 해당 파도를 일시 중지했습니다.

여러 호스트에 분산된 고객 프로젝트의 경우, 오케스트레이터가 공동 배치 그래프를 계산했습니다. 이는 동일한 프로젝트를 지원하는 두 호스트가 동일한 시간대 내에 재부팅되는 것을 방지하기 위함이었습니다.

또한 각 팀은 지역별 출시를 앞두고 내부 서비스 간의 종속 관계를 파악했습니다. 재부팅 과정 중에도 데이터베이스, API, 모니터링 시스템 및 기타 운영 서비스가 계속 가동될 수 있도록, 일부 핵심 가상 머신을 먼저 라이브 마이그레이션해야 했습니다.

인스턴스가 모두 단일 호스트에 배치되어 있던 고객들은 서비스 중단을 겪었습니다. 해당 고객들에게는 사전 공지된 처리 기간이 안내되었으나, 보안 대응의 시급성으로 인해 이를 거부하는 것은 현실적으로 불가능했습니다.

그러자 하드웨어 문제가 드러났습니다. 첫날 밤, 6,000대의 호스트 중 약 20~30대가 스스로 재부팅되지 않았습니다. 메모리 모듈 고장, BIOS 문제, 네트워크 인터페이스 고장 등이 원인이었습니다.

미국의 일부 시스템은 전원을 켜기 전에 CMOS 배터리를 분리하고 전원을 방전시켜야 했습니다. 이 기간 동안 데이터센터 기술자들은 모든 현장에 배치되어 부품을 교체하고, 어떤 오케스트레이터도 자동화할 수 없는 랙 내 직접 작업을 수행했습니다.

소프트웨어 쪽에서도 문제가 발생했습니다. 호스트 재부팅 후 가상 머신이 재시작되지 않는 현상이 발생했으나, libvirt-guests 충돌이 발견되어 이를 우회 처리한 후에야 해결되었습니다. 강제 종료로 인해 세 개의 클러스터에 걸쳐 가상 머신의 데이터가 손상되었습니다. 파리 OpenStack API는 교착 상태에 빠져 2시간 동안 HTTP 503 오류가 발생했고, 이로 인해 한 차례의 트래픽 급증이 지연되었습니다. 캐나다 사이트에서는 트래픽이 평소 피크 시간대의 10배에 달해 지원팀이 업무에 매몰되었습니다.

공로를 인정해야 할 점은, OVH의 위기 대응팀이 상황을 훌륭하게 처리했으며, 이러한 실패 사례를 공개하는 데는 대부분의 업체가 갖지 못한 용기가 필요하다는 점입니다.

실행 자체는 문제가 아니었다. 문제가 된 것은 이를 필요로 했던 패치 모델이었다.

KernelCare로 보호된 시스템들은 대신 어떤 조치를 취했는가

KernelCare를 사용하는 차량 함대는 앞서 설명한 운영 절차 없이도 동일한 취약점을 처리했습니다. 재부팅 작업도, 유지보수 시간대도, 단계별 기술자 투입도 필요하지 않았습니다.

TuxCare는 로컬 권한 상승 및 제로데이 취약점에 대해 공개된 지 48시간 이내에 라이브 패치를 제공하는 것을 현재 목표로 삼고 있습니다. 이번 사례는 그보다 더 빠르게 처리되었습니다. 7월 6일에 공개 금지 조치가 해제되었고, KernelCare는 7월 7일(약 24시간 후)에 ‘라이브 패칭’이라고도 불리는 일반적인 재부팅 없이 적용되는 패치 프로세스를 통해 필요한 두 가지 수정 사항을 함께 제공하기 시작했습니다.

Januscape 기술 분석 보고서에 명시된 바와 같이, 7월 7일 기준으로 일반적으로 이용 가능한 서비스 범위는 다음과 같았습니다:

• Enterprise Linux 10 제품군
• Ubuntu 22.04(클라우드 버전 포함)
• 데비안 13
• Jammy 하드웨어 지원 커널을 사용하는 Ubuntu Focal 시스템
• Proxmox VE 7 및 8

그 후, 추가적인 커널 계열들이 개발, 테스트 및 단계적 배포 과정을 거쳤습니다.

OVHcloud는 다음 날인 7월 8일, 시드니에서 첫 번째 재시작 단계를 시작했습니다.

따라서 한 팀의 운영 담당자들이 여전히 가동 중단 일정을 수립하고 있는 동안, 패치가 적용된 서버 군은 이미 보호된 상태였습니다. 다만, 이는 7월 7일 패치가 OVHcloud 자체의 프로덕션용 데비안 커널에 적용 가능했을 것이라는 점을 입증하지는 못한다는 점은 여전히 유보해야 합니다. OVHcloud는 이를 확인하기에 충분한 버전 정보를 공개하지 않았기 때문입니다.

이는 지원되는 커널을 실행하는 호스팅 제공업체가 선택할 수 있는 운영상의 대안을 보여줍니다.

해당 재부팅 불필요 패치가 시스템에 적용되면, 호스트를 재시작하지 않고도 취약한 코드를 교체할 수 있었습니다. 재부팅 일정을 잡을 필요가 없었고, 전원 재시작을 위해 고객의 워크로드를 조정할 필요도 없었으며, 재부팅과 관련된 고객 공지 사항도 없었습니다.

또한 비상 재시작 중에 표면화될 수 있는 잠재적인 하드웨어 문제도 없었습니다.

관리자는 보장 범위를 직접 확인할 수 있습니다:

kcarectl --patch-info | grep -E 'CVE-2026-53359|CVE-2026-46113'

차이는 한 그룹은 야누스케이프를 진지하게 받아들였고 다른 그룹은 그렇지 않았다는 데 있는 것이 아니다. 양쪽 모두 진지하게 받아들였다.

OVH의 접근 방식은 문제 해결을 대규모 인프라 사건으로 만들었지만, KernelCare를 활용한 재부팅 없는 패치 적용을 했다면 이는 일상적인 패치 배포로 처리되었을 것입니다.

노출 기간은 눈에 띄지 않는 비용이다

패치된 커널 패키지를 설치한다고 해서 현재 실행 중인 커널이 보호되는 것은 아닙니다. 해당 취약점은 시스템이 재부팅되어 업데이트된 버전으로 전환될 때까지 계속 존재합니다.

이로 인해 아직 차례를 기다리고 있는 모든 호스트에 걸쳐 노출 창이 생성됩니다.

OVHcloud는 이 문제를 명확히 인지하고 있었습니다. 고객을 개별적으로 대응했다면 캠페인 기간이 길어졌을 뿐만 아니라, 수주 동안 서버 군의 상당 부분이 취약한 상태에 놓였을 것입니다. 또한 이 회사는 배포가 진행되는 동안 고객들이 공개된 크래시 익스플로잇을 실제 운영 인프라에 시도할까 봐 우려하여 대외적인 소통을 제한했습니다.

재부팅 없이 패치를 적용하는 방식에서는, 해당 패치가 성공적으로 적용되면 창이 닫힙니다. 따라서 기존의 커널 업데이트 및 재부팅은 보안 비상 상황 도중이 아니라, 나중에 예정된 유지보수 주기 중에 수행할 수 있습니다.

부팅 없이 패치 적용하는 방식은 너무 불안정할까?

OVHcloud는 중단 없는 패치 적용 방안을 검토했으나 이를 거부했습니다. 사후 분석 보고서에 따르면, 실행 중인 커널을 수정하면 보안 강화 수준이 저하될 수 있으며, 전체 인프라에 걸쳐 불안정성이 발생할 가능성이 있다고 지적하고 있습니다.

그 우려에 대해서는 직접적인 답변이 필요합니다. 다음 세 가지 측면에서 하나씩 살펴보겠습니다:

먼저, 이러한 패치가 실제로 배포되는 방식에 대해 설명하겠습니다. 모든 KernelCare 패치는 대상 커널 버전에 맞춰 빌드 및 테스트를 거친 후, 내부 검증과 단계별 테스트를 통과해야만 프로덕션 피드에 반영됩니다. 추가 검증 단계를 원하는 플릿은 KernelCare ePortal을 통해 자체 승인 단계와 배포 정책을 설정할 수 있습니다. 이는 성숙한 배포 파이프라인입니다.

둘째, 이 특정 버그입니다. Januscape 수정 사항은 재부팅 없이 적용 가능한 패치의 전형적인 사례입니다. KVM MMU 오류 경로 내에서 국한된 수정이며, 마이그레이션해야 할 영구적인 상태도 없고 변환해야 할 데이터 구조도 없습니다. 재부팅 없이 패치를 적용하는 것이 어떤 용도인지 보여주기 위해 CVE를 설계한다면, 바로 이 사례와 같을 것입니다.

셋째, 이 부분은 특히 깊이 생각해 볼 가치가 있습니다. OVH가 직접 작성한 사후 분석 보고서에 따르면 재부팅 경로의 불안정성이 기록되어 있습니다. 다시 복구되지 못한 수십 대의 호스트. 강제 종료로 인해 손상된 디스크. 지역별 API 교착 상태. 서비스 충돌로 인해 오프라인 상태에 머물게 된 VM들. 선택의 여지는 결코 ‘위험한 재부팅 없는 패치’와 ‘위험 없는 재부팅’ 사이가 아니었습니다. 이는 서로 다른 위험 프로필을 가진 두 가지 방법 사이의 선택이었으며, 대규모 인프라 환경에서는 재부팅 방식의 위험이 크고, 실질적이며, 문서화되어 있습니다. 안정성은 패치 메커니즘 자체만의 속성이 아니라, 전체 문제 해결 경로의 속성입니다.

만약 귀사의 인프라가 고객에게 아무런 영향을 주지 않고 24시간 이내에 완전히 재부팅될 수 있다면, 귀사의 경우 상황 판단이 실제로 달라질 수 있습니다. 커널 CVE가 수 주간에 걸친 대응 작업, 위기 대응팀 구성, 그리고 모든 데이터센터에 기술자 투입을 의미한다면, 문제는 귀사의 팀이 아니라 해당 대응 모델 자체에 있는 것입니다.

재부팅이 필요한 패치와 재부팅이 필요 없는 패치의 비교

이런 일은 아마 또 일어날 것이다

야누스케이프는 단발성 사건이 아니었다.

CopyFail, DirtyFrag, GhostLock 등 심각한 커널 취약점들로 인해 인프라 팀들은 노출, 가동 중단 및 대응 조치에 대해 긴급한 결정을 내려야만 했습니다.

OVHcloud의 CISO는 커널 관련 정보가 추가로 유출될 경우 비상 절차를 다시 수행해야 할 수도 있음을 인정했다. 이 회사의 당면 과제는 다음 번에 해당 절차를 더 안전하고 예측 가능하게 만드는 것이다.

다른 호스팅 업체들은 또 다른 옵션을 제공합니다.

이를 통해 커널 취약점이 애초에 고객에게 영향을 미치는 인프라 사고로 이어지는 빈도를 줄일 수 있습니다.

OVHcloud는 압박 속에서도 대규모 재부팅 캠페인을 얼마나 원활하게 수행할 수 있는지 보여주었습니다. KernelCare는 지원 대상 시스템의 경우, 해당 캠페인을 시작하지 않고도 실행 중인 커널에서 동일한 취약점을 제거할 수 있음을 입증했습니다.

Januscape 사건에서 얻은 지속적인 교훈은 호스팅 제공업체들이 더 나은 재부팅 운영 매뉴얼이 필요하다는 것이 아닙니다.

중대한 커널 취약점이 발생할 때마다 매번 이를 활성화할 필요가 없어야 한다는 점입니다.

KernelCare로 재부팅 없이 패치 적용하기 →