Đây là một câu hỏi Canonical về sự hiểu biết và khắc phục vấn đề bảo mật Heartbleed.

Chính xác thì CVE-2014-0160 AKA "Heartbleed" là gì? Nguyên nhân là gì, hệ điều hành và phiên bản nào của OpenSSL dễ bị tổn thương, các triệu chứng là gì, có phương pháp nào để phát hiện khai thác thành công không?

Làm cách nào để kiểm tra xem hệ thống của tôi có bị ảnh hưởng không? Làm thế nào lỗ hổng này có thể được giảm nhẹ? Tôi có nên lo lắng rằng các khóa của tôi hoặc dữ liệu riêng tư khác đã bị xâm phạm? Những tác dụng phụ khác tôi nên quan tâm?

Đầu tiên , trước khi hoảng sợ, hãy chắc chắn rằng bạn hiểu liệu lỗ hổng này có thực sự áp dụng cho bạn hay không. Nếu bạn có một máy chủ, nhưng chưa bao giờ thực sự có bất kỳ ứng dụng nào sử dụng TLS, thì đây không phải là điều ưu tiên cao để bạn khắc phục. Mặt khác, nếu bạn đã từng có các ứng dụng hỗ trợ TLS, thì bạn sẽ được điều trị. Đọc tiếp:

Chính xác thì CVE-2014-0160 hay còn gọi là "Heartbleed" là gì?

Đó là một mớ hỗn độn lớn, đó là những gì nó được. Nói tóm lại, một lỗ hổng có thể khai thác từ xa đã được phát hiện trong các phiên bản OpenSSL từ 1.0.1 đến 1.0.1f, qua đó kẻ tấn công có thể đọc được một số phần nhất định của bộ nhớ hệ thống. Những phần chứa dữ liệu nhạy cảm như khóa riêng, khóa được chia sẻ trước, mật khẩu và dữ liệu công ty có giá trị cao trong số những thứ khác.

Lỗi được phát hiện độc lập bởi Neel Mehta của Google Security (ngày 21 tháng 3 năm 2014) và công ty kiểm tra bảo mật CNTT Phần Lan Codenomicon (ngày 2 tháng 4 năm 2014).

Nguyên nhân là gì?

Chà, mã sai lầm trong OpenSSL. Đây là cam kết giới thiệu lỗ hổng và đây là cam kết đã sửa lỗ hổng. Lỗi xuất hiện vào tháng 12 năm 2011 và được vá vào ngày hôm nay, 7 tháng 4 năm 2014.

Các lỗi cũng có thể được coi là một triệu chứng của một vấn đề lớn hơn. Hai vấn đề liên quan là (1) quá trình nào được thực hiện để đảm bảo mã errant không được đưa vào cơ sở mã và (2) tại sao các giao thức và phần mở rộng rất phức tạp và khó kiểm tra. Mục (1) là vấn đề về quản trị và quy trình với OpenSSL và nhiều dự án khác. Nhiều nhà phát triển chỉ đơn giản chống lại các thực hành như đánh giá mã, phân tích và quét. Mục (2) đang được thảo luận trên TLS WG của IETF. Xem độ phức tạp của Heartbleed / giao thức .

Là mã sai lầm được chèn độc hại?

Tôi sẽ không suy đoán liệu đây có thực sự là một sai lầm hay có thể là một chút mã bị thay mặt cho một diễn viên xấu. Tuy nhiên, người đã phát triển mã cho OpenSSL nói rằng nó là vô tình. Xem Người đàn ông đã giới thiệu lỗ hổng bảo mật 'Heartbleed' nghiêm trọng phủ nhận anh ta cố tình chèn nó .

Những hệ điều hành và phiên bản nào của OpenSSL dễ bị tổn thương?

Như đã đề cập ở trên, bất kỳ hệ điều hành nào đang sử dụng hoặc ứng dụng được liên kết với OpenSSL 1.0.1 đến 1.0.1f.

Các triệu chứng là gì, có phương pháp nào để phát hiện khai thác thành công không?

Đây là phần đáng sợ. Theo chúng tôi biết, không có cách nào để biết liệu lỗ hổng này có bị khai thác hay không. Về mặt lý thuyết có thể là chữ ký IDS sẽ sớm được phát hành có thể phát hiện khai thác này, nhưng đối với văn bản này, những chữ ký này không có sẵn.

Có bằng chứng cho thấy Heartbleed đã được khai thác tích cực trong tự nhiên vào đầu tháng 11 năm 2013. Xem EFF's Wild at Heart: Các cơ quan tình báo có sử dụng Heartbleed vào tháng 11 năm 2013 không? Và Bloomberg báo cáo NSA đã vũ khí hóa việc khai thác ngay sau khi lỗ hổng được đưa ra. Xem NSA nói để khai thác lỗi Heartbleed cho trí thông minh trong nhiều năm . Tuy nhiên, Cộng đồng Tình báo Hoa Kỳ phủ nhận tuyên bố của Bloomberg. Xem IC TRÊN GHI .

Làm cách nào để kiểm tra xem hệ thống của tôi có bị ảnh hưởng không?

Nếu bạn đang duy trì OpenSSL trên hệ thống của mình, thì bạn có thể chỉ cần phát hành openssl version:

$ openssl version
OpenSSL 1.0.1g 7 Apr 2014

Nếu phân phối được duy trì OpenSSL, thì có thể bạn không thể xác định phiên bản OpenSSL do trở lại vá bằng openssllệnh hoặc thông tin gói (ví dụ apt-get, dpkg, yumhoặc rpm). Quá trình vá lại được sử dụng bởi hầu hết các bản phân phối (tất cả?) Chỉ sử dụng số phiên bản cơ sở (ví dụ: "1.0.1e"); và không bao gồm phiên bản bảo mật hiệu quả (ví dụ: "1.0.1g").

Có một câu hỏi mở trên Super User để xác định phiên bản bảo mật hiệu quả cho OpenSSL và các gói khác khi các gói được gửi lại. Thật không may, không có câu trả lời hữu ích (ngoài việc kiểm tra trang web của distro). Xem Xác định phiên bản bảo mật hiệu quả khi đối mặt với Backpatching ?.

Theo nguyên tắc thông thường: nếu bạn đã từng cài đặt một trong những phiên bản bị ảnh hưởng và đã từng chạy các chương trình hoặc dịch vụ được liên kết với OpenSSL để hỗ trợ TLS, thì bạn dễ bị tấn công.

Tôi có thể tìm chương trình để kiểm tra lỗ hổng ở đâu?

Trong vài giờ sau thông báo Heartbleed, một số người trên internet đã công khai các ứng dụng web có thể truy cập công khai được cho là có thể được sử dụng để kiểm tra máy chủ xem có lỗ hổng này không. Theo văn bản này, tôi chưa xem xét bất kỳ, vì vậy tôi sẽ không công khai thêm các ứng dụng của họ. Chúng có thể được tìm thấy tương đối dễ dàng với sự trợ giúp của công cụ tìm kiếm ưa thích của bạn.

Lỗ hổng này được giảm nhẹ như thế nào?

Nâng cấp lên phiên bản không dễ bị tấn công và đặt lại hoặc bảo mật dữ liệu dễ bị tổn thương. Như đã lưu ý trên trang Heartbleed , các bước phản hồi phù hợp được phổ biến rộng rãi:

1. Vá các hệ thống dễ bị tổn thương.
2. Tạo lại khóa riêng mới.
3. Gửi CSR mới cho CA.
4. Lấy và cài đặt chứng chỉ đã ký mới.
5. Khóa phiên và cookie không hợp lệ
6. Đặt lại mật khẩu và bí mật được chia sẻ
7. Thu hồi giấy chứng nhận cũ.

Để có phân tích và trả lời chi tiết hơn, hãy xem Nhà điều hành trang web nên làm gì về khai thác HeartSSed OpenSSL? trên Sàn giao dịch bảo mật.

Tôi có nên lo lắng rằng các khóa của tôi hoặc dữ liệu riêng tư khác đã bị xâm phạm? Những tác dụng phụ khác tôi nên quan tâm?

Chắc chắn rồi. Quản trị viên hệ thống cần cho rằng các máy chủ của họ sử dụng các phiên bản OpenSSL dễ bị tổn thương thực sự bị xâm phạm và đáp ứng tương ứng.

Ngay sau khi lỗ hổng được tiết lộ, Cloudfare đã đưa ra một thách thức để xem liệu khóa riêng của máy chủ có thể được phục hồi trong thực tế hay không. Thử thách đã được Fedor Indutny và Ilkka Mattila giành chiến thắng một cách độc lập. Xem thử thách Heartbleed .

Tôi có thể tìm thêm thông tin ở đâu?

Liên kết kết xuất, cho những người tìm kiếm thêm chi tiết:

• OpenSSL SECADV 2014047
• CVE-2014-0160
• Đau lòng
• Thông báo Ubuntu
• Thông báo của RHEL
• Thông báo chính thức của OpenSSL

Một dòng thời gian khá chi tiết về các sự kiện tiết lộ có thể được tìm thấy tại dòng thời gian tiết lộ của Heartbleed: ai biết cái gì và khi nào .

Nếu bạn là một lập trình viên và quan tâm đến các thủ thuật lập trình khác nhau như phát hiện một cuộc tấn công Heartbleed thông qua msg_cbcuộc gọi lại của OpenSSL , thì hãy xem Tư vấn bảo mật của OpenSSL 2014047 .

Một lời giải thích đơn giản về lỗi này, bởi XKCD:

Ubuntu 12.04, 12.10 và 13.10

Ubuntu đã phát hành USN-2165-1 , trong đó tuyên bố rằng các gói cập nhật hiện có sẵn trong kho lưu trữ. Chạy hai lệnh sau để lấy bản sửa lỗi.

sudo apt-get update
sudo apt-get upgrade

Ubuntu 14.04

Tôi đã tải lên gói Debian chứa bản phát hành mới (1.0.1g) lên PPA mà tôi đã thiết lập cho mục đích này. Ba lệnh này sẽ thêm PPA của tôi vào hệ thống của bạn, cập nhật danh sách các gói có sẵn và nâng cấp mọi thứ:

sudo add-apt-repository ppa:george-edison55/openssl-heartbleed-fix
sudo apt-get update
sudo apt-get upgrade

_{Lưu ý: PPA cũng cung cấp các gói cho Ubuntu 12.04 và 13.10, chỉ trong trường hợp bạn thực sự muốn chạy phiên bản mới (1.0.1g) thay vì chỉ sử dụng các phiên bản vá trong kho lưu trữ.}

Ubuntu 10.04

Đây là phiên bản LTS, phiên bản máy chủ vẫn được hỗ trợ và nhận các bản cập nhật bảo mật. Nhưng lỗ hổng heartbleed không ảnh hưởng đến gói openssl của bản cài đặt chuẩn của ubfox 10.04, vì phiên bản dưới 1.0.1.

Phiên bản máy tính để bàn đã hết tuổi thọ và cần được nâng cấp / cài đặt lại.

Ubuntu 13.04 và các phiên bản lỗi thời khác

Ubuntu 13.04 có chu kỳ hỗ trợ rất ngắn mà bạn có thể không ngờ tới. Nó đã hết tuổi thọ và không nhận được cập nhật bảo mật nữa. Nó đã được nâng cấp từ lâu. Nếu vẫn có ai đó đang sử dụng nó, vui lòng nâng cấp ngay từ đầu hoặc có thể nâng cấp không phá hủy lên 13.10 theo quy trình đơn giản này: http://www.tecmint.com/upTHER-ub Ubuntu-13-04-rared-sytail -to-ubfox-13-10-saucy-salamander / Sau khi nâng cấp, hệ thống nhận được bản vá lỗi từ ngày 13.10.

Đối với tất cả các phiên bản Ubuntu đã lỗi thời khác, điều đó có nghĩa là về cơ bản cài đặt mới là cần thiết.

Xác nhận rằng bản vá đã được áp dụng

Về cơ bản, hãy chạy openssl version -avà đảm bảo rằng ngày xây dựng là ngày 7 tháng 4 năm 2014 trở đi, nhưng xem thêm tại đây .

Khởi động lại

Cách tốt nhất để đảm bảo tất cả các dịch vụ tùy thuộc vào OpenSSL được khởi động lại là khởi động lại .

RedHat 6.5 và CentOS 6.5

Đây là những dễ bị tổn thương. RedHat's erratum RHSA-2014-0376 nói rằng có sẵn các thư viện vá và bất kỳ ai bị ảnh hưởng nên nâng cấp trong cơ hội sớm nhất.

Tại thời điểm viết bài, CentOS chưa có phiên bản cố định, nhưng Karanbir Singh đăng lên CentOS-notify nói rằng họ đã tạo ra một phiên bản cập nhật của openssl ( openssl-1.0.1e-16.el6_5.4.0.1, lưu ý bốn chữ số cuối cùng quan trọng) có TLS có thể khai thác lệnh bị vô hiệu hóa và điều đó có thể được áp dụng một cách an toàn vì nó sẽ bị ghi đè bởi một phiên bản cố định khi cuối cùng nó được phát hành.

Phiên bản được sửa tạm thời dường như chưa xuất hiện trên tất cả các máy nhân bản, nhưng nằm trong kho chính tại http://mirror.centos.org/centos/6/updates/x86_64/Packages/ (và tương tự cho i686).

Chỉnh sửa : như Iain nói, hiện tại dường như có một phiên bản được vá hoàn toàn cho C6.5, và nó dường như đã được đẩy xung quanh các gương một cách vội vàng. Một thẳng yum updateđã nhận nó cho các máy chủ của tôi; nó openssl-1.0.1e-16.el6_5.7.

Các phiên bản của RH6 và C6 trước 6.5

Đây không phải là dễ bị tổn thương. Theo lời khuyên này từ Red Hat ,

Vấn đề này không ảnh hưởng đến các phiên bản openssl như được vận chuyển với Red Hat Enterprise Linux 5 và Red Hat Enterprise Linux 6.4 trở về trước.

Việc đăng bài của Karanbir Singh lên CentOS-thông báo cũng rõ ràng không kém về phiên bản:

Trước đó một ngày hôm nay, chúng tôi đã nhận thức được một vấn đề nghiêm trọng trong openssl khi được vận chuyển trong CentOS-6.5

Debian khò khè

Debian đã có DSA-2896-1 và các thư viện vá có sẵn ở đây . Một kịch bản shell có sẵn ở đây .

1. Bản vá

Kho chứa Apt-get đã được cập nhật nên giờ đây các thư viện đã vá có sẵn thông qua apt-get update && apt-get upgrade

apt-get upgrade libssl1.0.0 openssl

Ngoài ra (không khuyến nghị) các gói có thể được nâng cấp bằng tay:

wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/openssl_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_1.0.1e-2+deb7u5_amd64.deb

dpkg -i openssl_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl-dev_1.0.1e-2+deb7u5_amd64.deb

2. Khởi động lại máy chủ / dịch vụ

Để bảo vệ tốt nhất, hãy khởi động lại toàn bộ máy chủ hoặc nếu máy chủ không thể ngoại tuyến thì hãy khởi động lại các dịch vụ cần thiết.

3. Kiểm tra phiên bản OpenSSL

love@server:~$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
love@server:~$ dpkg -l libssl1.0.0
||/ Name                    Version          Architecture     Description
+++-=======================-================-================-====================================================
ii  libssl1.0.0                 1.0.1e-2+deb7u6  amd64            SSL shared libraries

Tôi muốn chỉ ra rằng khóa riêng không phải là tài sản duy nhất cần được xem xét bị xâm phạm. Lỗi này có khả năng rò rỉ bất kỳ bộ nhớ nào chạy trong cùng một không gian địa chỉ (nghĩa là cùng một quy trình) như OpenSSL. Do đó, nếu bạn đang chạy một quy trình máy chủ trong đó phiên bản OpenSSL dễ bị tổn thương được liên kết tĩnh hoặc động, mọi thông tin mà quy trình đó đã từng xử lý , bao gồm mật khẩu, số thẻ tín dụng và dữ liệu cá nhân khác, nên được xem là có khả năng bị xâm phạm.

FreeBSD 10.0 hoặc openssl từ các cổng

Nhóm bảo mật FreeBSD đã đưa ra một lời khuyên về CVE-2014-0160 (còn gọi là "Heartbleed") và: FreeBSD-SA-14: 06.openssl

1. Cập nhật FreeBSD

   • Cập nhật FreeBSD thông qua bản vá nhị phân

     Các hệ thống chạy phiên bản RELEASE của FreeBSD trên nền tảng i386 hoặc amd64 có thể được cập nhật thông qua tiện ích freebsd-update (8):

     # freebsd-update fetch
     # freebsd-update install
     

   • Cập nhật FreeBSD từ các nguồn

     1. Tải xuống bản vá có liên quan từ vị trí bên dưới và xác minh chữ ký PGP tách rời bằng tiện ích PGP của bạn.

        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch
        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch.asc
        # gpg --verify openssl-10.patch.asc
        

     2. Thực hiện các lệnh sau dưới dạng root:

        # cd /usr/src
        # patch < /path/to/patch
        

     3. Biên dịch lại hệ điều hành

        sử dụng buildworld và installworld như được mô tả trong cẩm nang FreeBSD .

2. Cập nhật cổng openssl với phiên bản tối thiểu 1.0.1_10

3. Khởi động lại tất cả các trình tiện ích bằng thư viện hoặc khởi động lại hệ thống

4. Hành động như thể hệ thống của bạn đã bị xâm phạm, cấp lại tất cả các khóa ssl và / hoặc chứng chỉ và thông tin có khả năng bị rò rỉ (xem EEAA trả lời chung hơn).

FreeBSD 9.x và FreeBSD 8.x

Các hệ thống này không dễ bị ảnh hưởng bởi sự cố Heartbleed theo mặc định, vì dựa vào phiên bản 0.9.x cũ hơn của thư viện openssl , trừ khi bạn cài đặt openssl từ các cổng (xem trên lầu).

Nếu các hệ thống này không dễ bị ảnh hưởng bởi vấn đề Heartbleed , có thể nên nâng cấp hệ thống của bạn sớm hơn sau đó do một lỗ hổng cục bộ khác (xem FreeBSD-SA-14: 06.openssl và phần "FreeBSD 10.0" ở tầng trên):

Kẻ tấn công cục bộ có thể có thể rình mò quá trình ký và có thể khôi phục khóa ký từ nó. [CVE-2014-0076]

Lưu ý :

Tư vấn ban đầu của Heartbleed liệt kê FreeBSD 8.4 và 9.1 là có khả năng bị tổn thương. Điều này không đúng do thiếu phần mở rộng Heartbeat (thư viện opensl FreeBSD mặc định là phiên bản 0.9.x).

Tôi thấy nó bên cạnh không thể xác định các phiên bản SSL được sử dụng trên một số thiết bị tôi làm việc cùng. Mặc dù về mặt kỹ thuật, việc giảm thiểu khả năng ID hiện tại của các máy chủ dễ bị tổn thương nằm ở đầu danh sách của tôi.

Tôi kết hợp một VM nhỏ sẽ thực hiện kiểm tra đối với các máy chủ và cổng tùy ý bằng cách sử dụng mô đun thử nghiệm của FiloSottile . Trên sơ bộ mã nhìn có vẻ âm thanh.

Việc phát hành VM hoàn thành là ở đây . Nó ở định dạng VMX.

Lời cảnh báo

Tập lệnh và VM này sẽ chỉ hiển thị trạng thái hiện tại của hệ thống của bạn. Hoàn toàn có khả năng tại một số thời điểm trong quá khứ hệ thống của bạn ở trạng thái dễ bị tổn thương và có thể đã bị lạm dụng.

Một cái gì đó hiển thị ở đây chắc chắn là một ưu tiên cao để khắc phục nhưng nó không giúp bạn thoát khỏi việc áp dụng các bản cập nhật và thay đổi tất cả các khóa của bạn.

Amazon Linux (bản phân phối Linux được sử dụng trong Amazon EC2)

https://aws.amazon.com/amazon-linux-ami/security-bONSins/ALAS-2014-320/

Tổng quan về vấn đề: Kiểm tra giới hạn bị thiếu đã được tìm thấy theo cách OpenSSL xử lý các gói mở rộng nhịp tim TLS. Lỗ hổng này có thể được sử dụng để tiết lộ tới 64k bộ nhớ từ máy khách hoặc máy chủ được kết nối.

Các phiên bản bị ảnh hưởng: Bất kỳ Amazon Linux AMI nào được cài đặt openssl 1.0.1, bất kỳ Amazon Linux AMI 2013.03 trở lên và bất kỳ Amazon Linux AMI nào đã nâng cấp lên 2013.03 trở lên. OpenSSL được cài đặt theo mặc định trên Amazon Linux AMI.

Gói bị ảnh hưởng: openssl

Khắc phục sự cố: Chạy yum update openssl để cập nhật hệ thống của bạn. Sau khi gói mới được cài đặt, bạn phải tự khởi động lại tất cả các dịch vụ đang sử dụng openssl hoặc bạn khởi động lại phiên bản của mình. Mặc dù gói mới vẫn có tên openssl-1.0.1e, nhưng nó có chứa bản sửa lỗi cho CVE-2014-0160.

Gói mới: i686:

openssl-1.0.1e-37.66.amzn1.i686

openssl-static-1.0.1e-37.66.amzn1.i686

openssl-perl-1.0.1e-37.66.amzn1.i686

openssl-devel-1.0.1e-37.66.amzn1.i686

openssl-debuginfo-1.0.1e-37.66.amzn1.i686

x86_64:

openssl-devel-1.0.1e-37.66.amzn1.x86_64

openssl-1.0.1e-37.66.amzn1.x86_64

openssl-debuginfo-1.0.1e-37.66.amzn1.x86_64

openssl-perl-1.0.1e-37.66.amzn1.x86_64

openssl-static-1.0.1e-37.66.amzn1.x86_64