취약점 업데이트! Redhat 업스트림(최신 패키지)을 사용해도 되는가? (feat. Upstream, Backporting)

<문제 사항>

KISA - !@#$%5 n이하 버전은 취약해!! 업그레이드 하십시오!!

나(보안인) - !@#$%^ 이런 취약점이 있으니 업그레이드 합시다!

개발자 - 못하겠는데요? 

나(보안인) - 네..?

 

openssl 로 예를 들어보자 os 별로 소스설치가 아닌 패키징 설치를 했다면

centos 5,6 는 0.9.8 

centos7 은 1.0.1 

centos8 은 1.1.1 

버전을 사용하고 있을 것이다. 

(centos 5,6 은 더이상 업데이트 지원 하지 않는다. centos7은 2024년 7월, centos8 은 2021년 12월 31에 지원이 끝난다.)  CentOS 지원종료에 관한 게시글 -> https://hello-sec.tistory.com/150

 

기존 서비스중인 서버를 모두 상위 동일 버전으로 업데이트 하기엔 무리가 있다.

(1.1.1e에서 1.1.1k 로 업데이트 되는건 보통 무리가 없지만

0.9.8 , 1.0.1 에서 1.1.1 로 업데이트 될 시 호환 문제나 각종 에러가 발생할 수 있기 때문이다..)

 

마음같아선 앞으로 소스설치로 통일합시다!!!!! 하고 싶지만.... (뭐 그럴 수 있나요?)

그래서 생각한 대안.. 바로 redhat 최신 패키지 사용이다.

 

 

레드햇에서는 제공하는 패키지에 보안 취약점이 발견되었을 때(CVE) 상위 버전에 해당 취약점을 제거하고 업데이트 해주는 서비스를 제공하고 있다.(업스트림 패키지)

그리고 최신 버전과 동일하게 그 하위 버전에도 취약점 패치를 하는것을 Backporting 이라고 한다.

 

 

 

https://access.redhat.com/security/updates/backporting

우리는 백포팅이라는 용어를 업스트림 소프트웨어 패키지의 최신 버전에서 보안 결함에 대한 수정 사항을 가져오고 해당 수정 사항을 배포하는 패키지의 이전 버전에 적용하는 작업을 설명합니다.

백포팅은 Red Hat과 같은 공급업체에서 일반적이며 최소한의 위험으로 고객에게 자동 업데이트를 배포할 수 있도록 하는 데 필수적입니다. 백포팅은 독점 소프트웨어 업데이트에 더 익숙한 사람들에게 새로운 개념일 수 있습니다.

다음은 보안 수정 사항을 백포트하는 이유의 예입니다.

Red Hat은 Red Hat Enterprise Linux 6에서 PHP 버전 5.3을 제공합니다. PHP 5.3의 업스트림 버전은 2014년 8월 14일에 수명이 종료되었습니다. 즉, 업스트림에서 이 버전에 대한 추가 수정 사항이나 개선 사항이 제공되지 않습니다. 그러나 2014년 10월 14일에 중요로 평가 된 버퍼 오버플로 결함 CVE-2014-3670 이 모든 PHP 버전에서 발견되어 원격 공격자가 PHP 응용 프로그램을 충돌시키거나 아마도 임의의 코드를 실행할 수 있습니다. 해당 PHP 애플리케이션을 실행하는 사용자의 권한.

PHP 버전 5.3이 업스트림에서 사용 중지되었기 때문에 이 문제에 대한 수정 사항은 PHP 5.3의 업스트림 릴리스에서 제공되지 않았습니다. 이 문제를 완화하는 유일한 방법은 CVE-2014-3670에 대한 수정 사항을 제공한 PHP 5.4로 업그레이드하는 것입니다. 그러나 PHP 5.3을 사용하는 Red Hat 고객은 버전 5.3과 5.4 간의 역호환성 문제로 인해 PHP 5.4로 마이그레이션하지 못할 수 있습니다. 마이그레이션 프로세스에는 시스템 관리자 또는 개발자의 수동 작업이 필요합니다. 이러한 이유로 Red Hat은 고객이 PHP 5.3을 계속 사용하면서 동시에 CVE-2014-3670을 완화할 수 있도록 Red Hat Enterprise Linux 6과 함께 제공되는 PHP 5.3 패키지에 이 문제에 대한 수정 사항을 제공(백포트)했습니다.

보안 수정 사항을 백포트할 때 다음을 수행합니다.

• 수정 사항을 식별하고 다른 변경 사항과 분리
• 수정 사항으로 인해 원치 않는 부작용이 발생하지 않는지 확인하십시오.
• 이전에 릴리스된 버전에 수정 사항 적용

대부분의 제품에서 기본 방식은 보안 수정 사항을 백포트하는 것이지만 신중한 테스트와 분석을 거쳐 일부 패키지에 대한 버전 업데이트를 제공하기도 합니다. 이들은 다른 사람과 상호 작용하지 않거나 웹 브라우저 및 인스턴트 메시징 클라이언트와 같이 최종 사용자가 사용하는 패키지일 가능성이 높습니다.

일반적인 릴리스 번호 지정 혼동 설명

백포팅은 고객에게 여러 가지 이점이 있지만 이해하지 못할 때 혼란을 일으킬 수 있습니다. 고객은 패키지의 버전 번호만 보고 취약한지 여부를 알 수 없음을 알아야 합니다. 예를 들어 언론의 기사에는 업스트림 버전 번호만 고려한 "문제를 해결하기 위해 Apache httpd 2.0.43으로 업그레이드"와 같은 문구가 포함될 수 있습니다. 이는 공급업체의 업데이트된 패키지를 설치한 후에도 고객이 최신 업스트림 버전을 사용하지 않을 가능성이 높기 때문에 혼동을 일으킬 수 있습니다. 대신 백포트된 패치가 적용된 이전 업스트림 버전이 있습니다.

또한 일부 보안 검색 및 감사 도구는 발견한 구성 요소의 버전 번호만을 기준으로 취약점에 대한 결정을 내립니다. 도구가 백포트된 보안 수정 사항을 고려하지 않기 때문에 오탐지가 발생합니다.

Red Hat Enterprise Linux가 도입된 이후로 우리는 보안 권고에서 새로운 업스트림 버전으로 이동하거나 기존 버전으로 패치를 백포팅하여 문제를 해결한 방법을 주의 깊게 설명했습니다. 우리는 2000년 1월부터 모든 권고 에 CVE 이름 을 첨부 하여 고객이 버전 번호와 상관없이 취약점을 쉽게 상호 참조하고 수정 방법과 시기를 찾을 수 있도록 했습니다.

또한 보안 수정 사항이 백포트된 경우에도 타사 취약점 도구가 취약점 상태를 확인하는 데 사용할 수 있는 OVAL 정의 (저희 권고의 기계 판독 가능 버전)를 제공합니다. 이를 통해 백포팅과 관련된 혼란을 일부 제거하고 고객이 항상 최신 보안 수정 사항을 쉽게 확인할 수 있기를 바랍니다.

https://access.redhat.com/solutions/4455511 패키지 EOL 에 관한 설명 - 기능적 업데이트는 이뤄지지 않지만 RHEL 패키지 업스트림 서비스에 따른 하위버전 백포트 서비스 (ex - python2 종료, openssl 1.0.2 종료)

 

(단점)

1. <- 보안인이라면  1년의 1번이상의 내부 취약점검사 를 할 것인데 

취약점 검사상 모든 패키지의 소스를 까보고 하지 않고 패키징 번호로 판단을 내릴 수 있다. (실제 공격 코드로 해당 취약점이 존재하는지 확인하지 않고 패키지 버전으로만 취약성을 평가할 수 있다)

현재시점에서 OPENSSL 1.1.1K 미만 버전은 취약버전이지만

현재 Redhat 에서 제공하는 openssl 최신 패키지는 1.1.1g.이다. 레드햇에서 취약점을 없애고 패키지를 업데이트를 했지만 외부에서 볼 때 패키징 네임 넘버로 해당 버전이 취약한지 안전한지 알 수 없다.

결론은 보안업데이트 등 보안입장에서 관리하기가 어렵다는 점이다. 

 

2. 취약점발견되고 취약점이 상쇄되는 패키지가 아무래도 소스보단 느리게 업데이트된다.

 

 

 

 

 

 

redhat 페이지에서 활용 방법

(1) Security\RedHat CVE Database 클릭

(2) CVE ID 입력

(3) OS 별 영향이 있는지 나와있고, 영향있는 버전의 Security 업데이트가 되면 Fixed 로 표기된다

 

 

(4) errata(정오표) 클릭하면 업데이트된 패키지명과 날짜가 나옴