OpenSSL에서 Heartbleed 버그 (CVE-2014-0160)를 패치하는 방법?

152

오늘 현재 OpenSSL 의 버그는 (포함) 및를 1.0.1통해 버전에 영향을주는 것으로 밝혀졌습니다 .1.0.1f1.0.2-beta

우분투 12.04부터이 버그에 모두 취약합니다. 이 취약점을 패치하려면 영향을받는 사용자가 OpenSSL로 업데이트해야합니다 1.0.1g.

영향을받는 모든 사용자가이 업데이트를 지금 어떻게 적용 할 수 있습니까?

security  openssl 
— 루시오
소스
영향을받는 버전의 openssl이 있습니까?
— Braiam
패치 버전 1.0.1-4ubuntu5.12가 있는데 아파치 서비스를 다시 시작했지만 내 사이트에서 filippo.io/Heartbleed 테스트가 여전히 취약하다고 말합니다.
1
@ 매트 그 사이트가 무엇을 테스트하는지 모르지만 이전 키를 사용하고 있음을 감지했을 수 있습니다. 키가 유출되었을 수 있으므로 키를 다시 생성해야합니다.
— Gilles
1
OpenSSL을 새 버전을 도매로 업데이트하기를 정말로 원하지 않습니다. 믿을 수없는 고통입니다. 문제를 패치하는 업데이트 된 패키지를 설치하는 것이 훨씬 쉽습니다. ubuntu.com/usn/usn-2165-1
— sarnold
업그레이드 후 서비스를 다시 시작 했습니까?
— Axel

답변:

141

12.04, 12.10, 13.10 및 14.04의 보안 업데이트는 Ubuntu 보안 공지 USN-2165-1을 참조하십시오 .

따라서 먼저 사용 가능한 보안 업데이트를 적용해야합니다 (예 :

sudo apt-get update
sudo apt-get upgrade

명령 행에서.

영향을받는 OpenSSL 버전을 사용하는 서비스 (HTTP, SMTP 등) 를 다시 시작 해야합니다. 그렇지 않으면 여전히 취약합니다. Heartbleed : 정의 란 무엇이며이를 완화 할 수있는 옵션은 무엇입니까?를 참조하십시오 . Serverfault.com에서.

다음 명령은 (업그레이드 후) 다시 시작해야하는 모든 서비스를 보여줍니다.

sudo find /proc -maxdepth 2 -name maps -exec grep -HE '/libssl\.so.* \(deleted\)' {} \; | cut -d/ -f3 | sort -u | xargs --no-run-if-empty ps uwwp

그런 다음 모든 서버 SSL 키 를 다시 생성 한 다음 키 유출 여부를 평가해야합니다.이 경우 공격자가 서버에서 기밀 정보를 검색했을 수 있습니다.

— 플로리안 다이 쉬
소스
23
이것이 Ubuntu 12.04.4 LTS에서 작동하는지 확실하지 않습니다. 전체 업데이트 openssl version후을 제공합니다 OpenSSL 1.0.1 14 Mar 2012. 그것은 패치 된 버전이 아닙니다. 아니면 내가 잘못 읽고 있습니까?
— Paul Cantrell
7
Ubuntu 13.04와 어떻게해야합니까? 업그레이드 된 openssl을 사용할 수 없음 :-(
— Frodik
20
Ubuntu 12.04에서는 고정 OpenSSL도 버전을 표시합니다 1.0.1 14 Mar 2012. 설치에 수정 사항이 포함되어 있는지 확인하려면 crimi의 답변 을 읽으십시오 .
— dan
7
감사합니다, @dan! @crimi의 대답을 여기에 다시 요약하십시오 : 당신이 달리고 dpkg -l | grep ' openssl '도착 1.0.1-4ubuntu5.12하면 갈 수 있습니다.
— Paul Cantrell
20
패치 및 재시작만으로는 충분하지 않습니다. 키를 재생성하고 키가 누출되었는지 여부 및 기타 기밀 자료를 평가해야합니다. 예를 들어 Heartbleed는 모든 SSL 서버에 대한 새 인증서를 의미합니까?
— Gilles
71

이 버그는 Heartbleed라고 합니다.

내가 취약한가?

일반적으로 SSL 키를 생성 한 서버를 특정 시점에 실행하면 영향을받습니다. 대부분의 최종 사용자는 (직접적으로) 영향을받지 않습니다. 최소한 Firefox와 Chrome은 OpenSSL을 사용하지 않습니다. SSH는 영향을받지 않습니다. 우분투 패키지 배포는 영향을받지 않습니다 (GPG 서명에 의존).

OpenSSL 버전 1.0–1.0.1f (버그가 발견 된 이후 패치 된 코스 버전 제외)를 사용하는 모든 종류의 서버를 실행하면 취약합니다. 영향을받는 Ubuntu 버전은 11.10 oneiric에서 14.04의 신뢰할 수있는 시험판입니다. 프로토콜의 결함이 아니라 구현 버그이므로 OpenSSL 라이브러리를 사용하는 프로그램 만 영향을받습니다. 이전 0.9.x 버전의 OpenSSL에 연결된 프로그램이있는 경우 영향을받지 않습니다. SSL 프로토콜을 구현하기 위해 OpenSSL 라이브러리를 사용하는 프로그램 만 영향을받습니다. 다른 용도로 OpenSSL을 사용하는 프로그램은 영향을받지 않습니다.

인터넷에 노출 된 취약한 서버를 실행 한 경우 2014-04-07 발표 이후 로그에 연결이 표시되지 않는 한 서버가 손상되었다고 간주하십시오. 서버가 내부적으로 만 노출 된 경우 키를 변경해야하는지 여부는 다른 보안 조치에 따라 다릅니다.

영향은 무엇입니까?

이 버그로 SSL 서버에 연결할 수 있는 모든 클라이언트 가 서버에서 약 64kB의 메모리를 검색 할 수 있습니다. 클라이언트는 어떤 식 으로든 인증 할 필요가 없습니다. 공격을 반복함으로써 클라이언트는 메모리의 다른 부분을 연속적으로 덤프 할 수 있습니다.

공격자가 검색 할 수있는 중요한 데이터 중 하나는 서버의 SSL 개인 키입니다. 이 데이터를 통해 공격자는 서버를 가장 할 수 있습니다.

서버에서 어떻게 복구합니까?

  1. 영향을받는 모든 서버를 오프라인 상태로 만듭니다. 실행중인 한 중요한 데이터가 유출 될 수 있습니다.

  2. libssl1.0.0패키지를 업그레이드하고 영향을받는 모든 서버가 다시 시작되었는지 확인하십시오.
    영향을받는 프로세스가 여전히``grep 'libssl로 실행 중인지 확인할 수 있습니다. (삭제) '/ proc / / maps`

  3. 새 키를 생성하십시오 . 이는 버그로 인해 침입자가 이전 개인 키를 얻었을 수 있기 때문에 필요합니다. 처음에 사용한 것과 동일한 절차를 따릅니다.

    • 인증 기관에서 서명 한 인증서를 사용하는 경우 새 공개 키를 CA에 제출하십시오. 새 인증서를 받으면 서버에 설치하십시오.
    • 자체 서명 된 인증서를 사용하는 경우 서버에 설치하십시오.
    • 어느 쪽이든, 이전 키와 인증서를 방해하지 마십시오 (그러나 삭제하지 말고 더 이상 사용되지 않도록하십시오).

  4. 손상되지 않은 새로운 키가 생겼으므로 서버를 다시 온라인 상태로 만들 수 있습니다 .

  5. 이전 인증서를 해지 하십시오.

  6. 손상 평가 : SSL 연결을 제공하는 프로세스의 메모리에 있던 모든 데이터가 유출되었을 수 있습니다. 여기에는 사용자 비밀번호 및 기타 기밀 데이터가 포함될 수 있습니다. 이 데이터가 무엇인지 평가해야합니다.

    • 비밀번호 인증을 허용하는 서비스를 실행하는 경우 취약점이 발표되기 조금 전에 접속 한 사용자의 비밀번호는 손상된 것으로 간주해야합니다. (암호는 메모리에서 잠시 동안 사용되지 않은 상태로 남아있을 수 있습니다.) 로그를 확인하고 영향을받는 사용자의 암호를 변경하십시오.
    • 또한 모든 세션 쿠키가 손상되었을 수 있으므로 무효화하십시오.
    • 클라이언트 인증서가 손상되지 않았습니다.
    • 취약점이 발생하기 조금 전에 교환 된 모든 데이터는 서버의 메모리에 남아있어 공격자에게 유출되었을 수 있습니다.
    • 누군가 이전 SSL 연결을 기록하고 서버 키를 검색 한 경우 이제 대화 내용을 해독 할 수 있습니다. ( PFS 가 보장 되지 않는 한 – 모르는 경우에는 그렇지 않습니다.)

클라이언트에서 어떻게 복구합니까?

클라이언트 응용 프로그램이 영향을받는 상황은 거의 없습니다. 서버 쪽의 문제는 누구나 서버에 연결하여 버그를 악용 할 수 있다는 것입니다. 클라이언트를 이용하려면 다음 세 가지 조건을 충족해야합니다.

  • 클라이언트 프로그램은 버그 프로토콜 버전의 OpenSSL 라이브러리를 사용하여 SSL 프로토콜을 구현했습니다.
  • 클라이언트가 악성 서버에 연결되었습니다. (예를 들어, 이메일 제공 업체에 연결 한 경우에는 문제가되지 않습니다.) 이것은 서버 소유자가 취약점을 인식 한 후 (2014-04-07 이후)에 발생했습니다.
  • 클라이언트 프로세스는 서버와 공유되지 않은 기밀 데이터를 메모리에 저장했습니다. (따라서 wget파일을 다운로드하기 위해 실행 한 경우 유출 할 데이터가 없었습니다.)

2014 년 4 월 7 일 저녁 UTC와 OpenSSL 라이브러리를 업그레이드 한 경우 클라이언트 프로세스의 메모리에 있던 모든 데이터가 손상되는 것을 고려하십시오.

참고 문헌

— 질
소스
4
"SSL / TLS 연결의 서버 측만 영향을받습니다"는 사실이 아닙니다. openssl.org/news/secadv_20140407.txt에 따르면 클라이언트 또는 서버의 비밀을 밝힐 수 있습니다. ubuntu.com/usn/usn-2165-1이 동의합니다. 악의적 인 서버에 연결하는 동안 클라이언트 인증서를 사용할 가능성은 적지 만 가능성이 있습니다.
— armb
@armb 당신은 좋은 지적을합니다. 클라이언트 인증서 사용 여부와 상관없이 데이터 유출은 인증서 사용과 관련이 없습니다. 나는 한 전문가의 도움을 입대했다 .
— Gilles
클라이언트 인증서는 개인 키를 유출하는 경우이지만 암호, 인증 쿠키 등이 유출 될 수 있습니다. 그러나 curl 또는 wget과 같은 일반적인 사용법의 OpenSSL 기반 클라이언트를 사용하면 악의적 인 서버에 연결하는 동안 메모리의 다른 사이트에 대한 비밀이 없으므로 클라이언트 비밀을 부여하면 유일한 누출이라고 생각합니다. 인증서 확인을 통해 올바른 사이트에 연결되지 않은 것으로 드러나기 전에 핸드 셰이크 중에 Heartbleed에서 유출 한 것으로 의심됩니다.
— armb
1
@Gilles 어떤 클라이언트가 Heartbleed에 취약한 것으로 입증 되었습니까? 에 대한 답변에 관심이 있으 십니까? . 나는 nginx (프록시 모드), wget, 링크 및 기타에서 "흥미로운"메모리를 얻었습니다.
— Lekensteyn
1
@ MuhamedHuseinbašić 패키지 openssl에는 명령 행 도구가 포함되어 있습니다. OpenSSL 라이브러리를 사용하여 SSL 프로토콜 (예 : Apache)을 구현하는 응용 프로그램에서는 사용되지 않습니다. 그러나 배포판의 보안 업데이트 만 적용하면됩니다.
— Gilles
40

Ubuntu에 설치된 OpenSSL 버전을 확인하려면 다음을 실행하십시오.

dpkg -l | grep openssl

다음과 같은 버전의 출력이 표시되면 CVE-2014-0160 용 패치가 포함되어 있어야합니다.

ii  openssl      1.0.1-4ubuntu5.12      Secure Socket Layer (SSL)...

보면 https://launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12 , 그것은 버그의 종류가 고정되는 보여줍니다

...
 SECURITY UPDATE: memory disclosure in TLS heartbeat extension
    - debian/patches/CVE-2014-0160.patch: use correct lengths in
      ssl/d1_both.c, ssl/t1_lib.c.
    - CVE-2014-0160
 -- Marc Deslauriers <email address hidden>   Mon, 07 Apr 2014 15:45:14 -0400
...
— 크리미
소스
2
업그레이드하여 버전 5.12를 얻었지만이 도구를 사용하면 취약한 filippo.io/Heartbleed Thought ?
— toxaq
3
이쪽에서 업데이트 된 서버를 테스트했으며 영향을받지 않는다고 알려줍니다. 시스템을 재부트 했습니까? 아니면 필요한 모든 프로세스가 다시 시작 되었습니까?
— crimi
3
OPENSSL을 업데이트 한 후 아파치 서비스를 다시 시작하는 것이었지만 도움이되지 못했습니다 . 나는 사용하여 이동하고 다시 시작으로했다sudo service apache2 restart
— 톰 HERT
1
방금 취약점의 원인을 찾았습니다. mod-spdy-beta가 설치되었습니다. 그것을 제거하고 아파치를 다시 시작한 후 모든 테스트는 이제 녹색입니다.
— Andreas Roth
3
업데이트 openssl해도 Apache, Nginx 또는 postfix와 같은 응용 프로그램은 수정되지 않습니다. libssl1.0.0다른 게시물에 설명 된대로 업데이트 하고 다시 시작해야합니다.
— tnj
17

귀하의 경우 apt-get을 저장소가 되지 않은 미리 컴파일 포함 할 1.0.1g의에서 OpenSSL 버전을, 그래서 그냥 공식 웹 사이트에서 소스를 다운로드하여 컴파일합니다.

단일 openssl 아래에서 마지막 openssl 버전을 컴파일하고 설치하십시오.

curl https://www.openssl.org/source/openssl-1.0.1g.tar.gz | tar xz && cd openssl-1.0.1g && sudo ./config && sudo make && sudo make install

심볼릭 링크를 통해 이전 openssl 바이너리 파일을 새 파일로 교체하십시오.

sudo ln -sf /usr/local/ssl/bin/openssl `which openssl`

당신은 모두 좋다!

# openssl version should return
openssl version
OpenSSL 1.0.1g 7 Apr 2014

Cf이 블로그 게시물 .

NB : 블로그 게시물에 명시된 바와 같이,이 대안은 "1.0.1g openSSL 소스로 다시 컴파일해야하는 Nginx 및 Apache 서버"를 수정하지 않습니다.

— 쿠엔틴 루소
소스
2
일반적으로 Ubuntu는 새로운 업스트림 버전을 제공하지 않지만 변경 사항을 최소로 유지하기 위해 지원되는 모든 릴리스의 버전을 패치했습니다.
— Florian Diesch
1
참고 : OpenSSL을 업데이트 한 후 서버를 다시 시작하십시오. Apache와 Nginx가 새로운 lib를 선택하고 취약점이 해결되었습니다.
— dAngelov
6
Heh, 이제이 글의 내용 을 읽는 데 시간이 걸리기 때문에 인터넷에서 임의의 장소에서 tarball을 다운로드하고, 압축을 풀고, 루트로 루트의 일부를 실행하는 것은 무모한 행동입니다. tarball 서명을 다운로드하여 확인하면 약간 더 나을 것이지만 올바른 키로 서명이 서명되었는지 확인하는 것은 어려운 질문입니다. 배포판은 이미 tarball과 패치의 안전한 출처를 보장하기 위해 노력하고 있습니다. 감사.
— sarnold
2
지금은 소스에서 컴파일하고 어쨌든 내 두 센트 expectly 우분투의 이전 버전에없는 것보다 당신의 더 안전 그런 식으로, 나중에 APT에서 새로운 하나를 설치하는 것이 좋습니다 수 있습니다
— nwgat
2
@sarnold openssl.org 는 openssl의 소스를 다운로드하는 임의의 장소처럼 보이지 않습니다. Canonical은 이것을 불필요하게 해야 하지만 openssl.org 는 권위있는 업스트림 이어야 합니다.
— Rustavore
12

서버 전체 패키지 업그레이드를 원하지 않는 사람들을 위해. 오늘이 안내서를 많이 읽었으며 apt-get upgrade openssl=== apt-get upgrade이것은 컴퓨터에 필요한 모든 보안 수정 사항을 적용합니다. 어딘가에 이전 패키지 버전을 명시 적으로 기대하지 않는 한 훌륭합니다.

이것은 Apache 2를 실행하는 Ubuntu 12.04 LTS에 필요한 최소 조치입니다.

  • 이 주소로 이동 하여 취약점이 있음을 증명하십시오. 웹 서버의 직접 외부 주소를 사용해야합니다. 로드 밸런서 (예 : ELB)를 사용하는 경우 웹 서버에 직접 연결하지 않은 것일 수 있습니다.

  • 다음 1 라이너를 실행하여 패키지를 업그레이드하고 다시 시작하십시오. 예, 2014 년 4 월 4 일 이후에 타임 스탬프가 있어야한다고 말하는 모든 가이드를 보았습니다.

    apt-get 업데이트 && apt-get 설치 openssl libssl1.0.0 && /etc/init.d/apache2 다시 시작

  • 적절한 패키지 버전이 설치되어 있는지 확인하고 웹 서버에서 취약점을 다시 한 번 확인하십시오.

주요 패키지는 다음과 같습니다. 아래 명령을 사용하여이 정보를 확인한 후 쪼개짐을 편집했습니다 (내 컴퓨터의 상태에 대해 많이 알 필요는 없습니다). 

$ dpkg -l | grep ssl

ii  libssl-dev                       1.0.1-4ubuntu5.12          SSL development libraries, header files and documentation
ii  libssl1.0.0                      1.0.1-4ubuntu5.12          SSL shared libraries
ii  openssl                          1.0.1-4ubuntu5.12          Secure Socket Layer (SSL)* binary and related cryptographic tools

1.0.1-4ubuntu5.12취약점을 포함해서는 안됩니다. 아래 웹 사이트로 다시 이동하여 웹 서버를 테스트하여이 경우에 해당하는지 확인하십시오.

http://filippo.io/Heartbleed/

— 아드리안
소스
2
외부 사이트를 사용하여 서버의 취약성을 증명하는 것은 나에게 잘못된 접근 방법 인 것 같습니다.
— Rinzwind
요즘 외부 취약성 테스트 스크립트가 점점 일반화되고 있습니다. 내부 스크립트와 정확히 일치하며 연결은 외부 웹 서버에서 시작됩니다. 모든 연결을 원격으로 시작하는 프로그램의 예는 WhiteHatSecurity.com과 같은 사이트를 참조하십시오. 예를 들어 네트워크 취약성 테스트와 같이 순식간에 웹 서버 (일반적으로 SSL 서버가 될 것임)를 테스트하는 경우에는 이것이 이상적입니다.
— Adrian
패키지를 업그레이드하는 경우 왜 설치해야합니까?
— Braiam
1
apt-get install openssl libssl1.0.0나를 위해 그것을했다. 달리는 openssl version -a지금 보여줍니다 :built on: Mon Apr 7 20:33:29 UTC 2014
— topher
"외부 취약점 테스트 스크립트가 요즘 점점 더 일반화되고 있습니다."는 외부 사이트가 내 시스템을 악용 할 가능성을 열어줍니다. 패치하기 전에 시스템이 실패하고 시스템을 해킹해야한다는 것을 알아야합니다. 아니요 올바른 방법이 아닙니다. (예, 아파치와 openssl로 내 사이트를 호스팅합니다).
— Rinzwind
11

나는 여기에 긴급한 도움이 필요한 많은 주석가를 발견했습니다. 그들은 지침을 따르고, 업그레이드, 재부팅 및 일부 테스트 웹 사이트를 사용할 때 여전히 취약합니다.

libssl과 같은 보류중인 패키지가 없는지 확인해야합니다.

:~$ sudo apt-get upgrade -V
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
  libssl-dev (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  libssl1.0.0 (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  linux-image-virtual (3.2.0.31.34 => 3.2.0.60.71)
  linux-virtual (3.2.0.31.34 => 3.2.0.60.71)
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.

apt-mark unhold libssl1.0.0예를 들어 업그레이드하십시오 . 그런 다음 업그레이드하십시오 apt-get upgrade -V.. 그런 다음 영향을받는 서비스를 다시 시작하십시오.

— 각설탕
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.