Ghost 취약점 - C/C++ 프로그램을 다시 컴파일합니까?

Linux 애플리케이션은 거의 항상 C 라이브러리에 대한 동적 링크를 사용합니다. 즉, C 라이브러리로 컴파일되지 않고 런타임에 링크됩니다. 이는 이미 C 라이브러리를 업그레이드한 경우 다른 작업을 수행할 필요가 없음을 의미합니다.

그러나 이것이 드문 일이기는 하지만 정적으로 연결된 glibc를 사용하여 무언가를 만드는 것이 불가능하지는 않습니다. 가장 좋은 방법은 관련 애플리케이션에 대한 문서를 확인하는 것입니다. 이것이 관례라면 거의 확실히 명백합니다.

check 실행 파일을 사용할 수 있습니다 file. 출력에 "동적 연결"이라고 표시되어야 합니다. 나생각하다이러한 바이너리가 정적 glibc를 통합하는 것은 여전히 ​​가능하지만 이는 매우 모호합니다. 다시 확인하는 방법은 다음과 같습니다.

ldd whatever | grep libc.so

whatever확인하려는 바이너리 파일은 어디에 있습니까? 어느 정도 출력을 얻어야 합니다. 그렇지 않다면 여기에 댓글을 남겨주세요. 그러면 제가 모자라게 먹을 수 있을 것입니다. 왜냐하면 저는 누구도 이런 것을 만들 것이라고 믿지 않기 때문입니다.

실제 정적 바이너리를 찾았다고 해서 반드시 glibc를 사용한다는 의미는 아닙니다. 소스 트리, 문서 또는 개발자에게 문의하여 이를 확인해야 합니다.

어떤 사람들은 애플리케이션의 세그폴트 때문에 업데이트를 되돌려야 한다는 이야기를 읽었습니다.

저도 두 번째, 세 번째로 본 적이 있어요. 그러나 나는 실제로 이 상황에 대한 구체적인 설명을 본 적이 없습니다. 솔직히 말해서 그럴 것 같지 않습니다.

첫째, Red Hat Enterprise Linux는 패키지 기반을 보존하고 가능한 한 오랫동안 엄격한 바이너리 호환성을 유지합니다. 2.12-1.7.el6.x86_64와 2.12-1.149.el6_6.5의 버전을 분석하면 glibc(여기서 .x86_64가 누락된 것으로 가정함) 둘 다 업스트림 버전 2.12이고 로컬(RHEL) 버전은 1.7과 RHEL 버전임을 알 수 있습니다. 1.149(즉, 약 142개의 패치 세트) 하나는 el6(예: RHEL 6)용이고 다른 하나는 el6_6.5(예: RHEL 6 "새 버전"에 번들로 제공되는 다섯 번째 업데이트 라운드)용입니다. 사용자가 눈에 띄는 차이점이 없어 매우 유사해야 합니다(당연한 버그 수정 제외).

대부분의 프로그램은 라이브러리에 동적으로 연결되어 있습니다(디스크와 메모리에는 라이브러리 복사본이 하나만 있으며 모든 사람이 공통 기호를 사용할 수 있으므로 더 나은 성능을 제공합니다). 라이브러리 업데이트 후 프로그램 시작. 드문 경우지만 프로그램 자체를 다시 컴파일해야 할 수도 있습니다(예를 들어 헤더의 인라인 함수나 매크로가 파괴적인 방식으로 잘못된 것으로 판명된 경우).

정적 링커에는 라이브러리의 코드가 포함되어 있습니다(이것은 점점 더 드물어지고 있습니다!)할 수 있다취약해지다깨진 코드를 사용하는 경우도서관에서.