Câu hỏi Làm thế nào để vá lỗi Heartbleed (CVE-2014-0160) trong OpenSSL?


Tính đến hôm nay, một lỗi trong OpenSSL đã được tìm thấy ảnh hưởng đến các phiên bản 1.0.1 xuyên qua 1.0.1f (bao gồm) và 1.0.2-beta.

Kể từ Ubuntu 12.04, tất cả chúng ta đều dễ bị lỗi này. Để vá lỗ hổng này, người dùng bị ảnh hưởng nên cập nhật lên OpenSSL 1.0.1g.

Mỗi người dùng bị ảnh hưởng có thể áp dụng bản cập nhật này như thế nào hiện nay?


152
2018-04-07 22:17


gốc


Bạn có phiên bản openssl bị ảnh hưởng không? - Braiam
Tôi đã có phiên bản vá lỗi 1.0.1-4ubuntu5.12 và tôi đã khởi động lại dịch vụ apache nhưng filippo.io/Heartbleed thử nghiệm trên trang web của tôi vẫn nói rằng tôi dễ bị tổn thương Bất kỳ ý tưởng nào tại sao?
@ Tôi không biết những gì trang web đó kiểm tra, nhưng có thể nó phát hiện rằng bạn đang sử dụng một khóa cũ. Vì khóa có thể đã bị rò rỉ, bạn cần phải tạo lại khóa. - Gilles
Bạn thực sự không muốn cập nhật OpenSSL để bán các phiên bản mới, đó là một nỗi đau không thể tin được. Dễ dàng hơn là chỉ cần cài đặt gói cập nhật vá lỗi vấn đề: ubuntu.com/usn/usn-2165-1 - sarnold
bạn đã khởi động lại dịch vụ của mình sau khi nâng cấp chưa? - Axel


Các câu trả lời:


Bản cập nhật bảo mật có sẵn cho 12.04, 12.10, 13.10 và 14.04 xem Thông báo bảo mật của Ubuntu USN-2165-1.

Trước tiên, bạn cần áp dụng các bản cập nhật bảo mật có sẵn, ví dụ bằng cách chạy

sudo apt-get update
sudo apt-get upgrade

từ dòng lệnh.

Đừng quên khởi động lại các dịch vụ (HTTP, SMTP, v.v.) sử dụng phiên bản OpenSSL bị ảnh hưởng, nếu không bạn vẫn dễ bị tổn thương. Xem thêm Heartbleed: Nó là gì và các tùy chọn để giảm thiểu nó là gì? trên Serverfault.com.

Lệnh sau đây cho thấy (sau khi nâng cấp) tất cả các dịch vụ cần được khởi động lại:

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

Sau đó, bạn cần phải tạo lại tất cả các khóa SSL của máy chủ, sau đó đánh giá xem các khóa của bạn có bị rò rỉ hay không, trong trường hợp đó, kẻ tấn công có thể đã truy xuất thông tin bí mật từ máy chủ của bạn.


141
2018-04-07 22:46



Không chắc chắn điều này hoạt động trên Ubuntu 12.04.4 LTS. Sau khi cập nhật đầy đủ, openssl version cho OpenSSL 1.0.1 14 Mar 2012. Đó không phải là phiên bản vá, phải không? Hay tôi đang hiểu sai nó? - Paul Cantrell
Làm gì với Ubuntu 13.04? Không có nâng cấp openssl :-( - Frodik
Trên Ubuntu 12.04 ngay cả phiên bản OpenSSL cố định 1.0.1 14 Mar 2012. Đọc câu trả lời của crimi để tìm hiểu xem cài đặt của bạn có bao gồm bản sửa lỗi hay không. - dan
Cảm ơn, @dan! Resummarizing @ crimi của câu trả lời ở đây: nếu bạn chạy dpkg -l | grep ' openssl ' và bạn nhận được 1.0.1-4ubuntu5.12 thì bạn nên đi. - Paul Cantrell
Vá và khởi động lại không đủ. Bạn cần phải tạo lại khóa và đánh giá xem khóa của bạn đã bị rò rỉ cũng như các tài liệu bí mật khác hay chưa. Xem ví dụ Heartbleed có nghĩa là chứng chỉ mới cho mỗi máy chủ SSL không? - Gilles


Lỗi này được gọi là Heartbleed.

Tôi có dễ bị tổn thương không?

Nói chung, bạn bị ảnh hưởng nếu bạn chạy một số máy chủ mà bạn đã tạo khóa SSL cho một số thời điểm. Hầu hết người dùng cuối không bị ảnh hưởng trực tiếp; ít nhất Firefox và Chrome không sử dụng OpenSSL. SSH không bị ảnh hưởng. Việc phân phối các gói Ubuntu không bị ảnh hưởng (nó dựa trên các chữ ký GPG).

Bạn dễ bị tấn công nếu bạn chạy bất kỳ loại máy chủ nào sử dụng các phiên bản OpenSSL 1.0–1.0.1f (ngoại trừ các phiên bản khóa học đã được vá kể từ khi phát hiện ra lỗi). Các phiên bản Ubuntu bị ảnh hưởng là 11,10 oneiric thông qua 14.04 trước khi phát hành đáng tin cậy. Đó là một lỗi thực hiện, không phải là một lỗ hổng trong giao thức, do đó chỉ các chương trình sử dụng thư viện OpenSSL mới bị ảnh hưởng. Nếu bạn có một chương trình liên kết với phiên bản OpenSSL 0.9.x cũ, nó không bị ảnh hưởng. Chỉ các chương trình sử dụng thư viện OpenSSL để triển khai giao thức SSL bị ảnh hưởng; các chương trình sử dụng OpenSSL cho những thứ khác không bị ảnh hưởng.

Nếu bạn điều hành một máy chủ dễ bị tổn thương bị phơi nhiễm với Internet, hãy xem xét nó bị xâm phạm trừ khi nhật ký của bạn không hiển thị kết nối nào kể từ khi thông báo vào ngày 2014-04-07. (Điều này giả định rằng lỗ hổng không được khai thác trước khi thông báo của nó.) Nếu máy chủ của bạn chỉ được tiếp xúc trong nội bộ, cho dù bạn cần phải thay đổi các phím sẽ phụ thuộc vào những gì các biện pháp an ninh khác được đặt ra.

Tác động là gì?

Lỗi này cho phép bất kỳ khách hàng nào người có thể kết nối với máy chủ SSL của bạn để lấy khoảng 64kB bộ nhớ từ máy chủ. Khách hàng không cần phải được xác thực bằng bất kỳ cách nào. Bằng cách lặp lại các cuộc tấn công, khách hàng có thể đổ các phần khác nhau của bộ nhớ trong các nỗ lực liên tiếp.

Một trong những phần dữ liệu quan trọng mà kẻ tấn công có thể truy xuất là khóa riêng SSL của máy chủ. Với dữ liệu này, kẻ tấn công có thể mạo danh máy chủ của bạn.

Làm cách nào để khôi phục trên máy chủ?

  1. Thực hiện tất cả các máy chủ bị ảnh hưởng ngoại tuyến. Miễn là họ đang chạy, họ có khả năng bị rò rỉ dữ liệu quan trọng.

  2. Nâng cấp libssl1.0.0 góivà đảm bảo rằng tất cả các máy chủ bị ảnh hưởng đều được khởi động lại.
    Bạn có thể kiểm tra xem các quá trình bị ảnh hưởng vẫn đang chạy với `` grep 'libssl.(đã xóa) '/ proc // maps`

  3. Tạo khóa mới. Điều này là cần thiết vì lỗi có thể đã cho phép kẻ tấn công lấy khóa riêng tư cũ. Thực hiện theo cùng quy trình bạn đã sử dụng ban đầu.

    • Nếu bạn sử dụng chứng chỉ được ký bởi cơ quan cấp chứng chỉ, hãy gửi khóa công khai mới của bạn cho CA. Khi bạn nhận được chứng chỉ mới, hãy cài đặt nó trên máy chủ của bạn.
    • Nếu bạn sử dụng chứng chỉ tự ký, hãy cài đặt nó trên máy chủ của bạn.
    • Dù bằng cách nào, di chuyển các khóa cũ và chứng chỉ ra khỏi con đường (nhưng không xóa chúng, chỉ cần đảm bảo chúng không được sử dụng nữa).
  4. Bây giờ bạn đã có các khóa mới, bạn có thể đưa máy chủ của bạn trở lại trực tuyến.

  5. Thu hồi các chứng chỉ cũ.

  6. Đánh giá thiệt hại: bất kỳ dữ liệu nào đã có trong bộ nhớ của một quá trình phân phát các kết nối SSL có thể đã bị rò rỉ. Điều này có thể bao gồm mật khẩu người dùng và dữ liệu bí mật khác. Bạn cần phải đánh giá những gì dữ liệu này có thể có được.

    • Nếu bạn đang chạy dịch vụ cho phép xác thực mật khẩu thì mật khẩu của người dùng đã kết nối từ trước khi lỗ hổng được thông báo sẽ bị coi là bị xâm phạm. (Một chút trước, vì mật khẩu có thể vẫn không được sử dụng trong bộ nhớ trong một thời gian.) Kiểm tra nhật ký của bạn và thay đổi mật khẩu của bất kỳ người dùng bị ảnh hưởng nào.
    • Cũng làm mất hiệu lực tất cả cookie phiên vì chúng có thể đã bị xâm phạm.
    • Chứng chỉ ứng dụng khách không bị xâm phạm.
    • Bất kỳ dữ liệu nào đã được trao đổi một chút trước khi lỗ hổng có thể vẫn còn trong bộ nhớ của máy chủ và do đó có thể đã bị rò rỉ cho kẻ tấn công.
    • Nếu ai đó đã ghi lại kết nối SSL cũ và truy xuất khóa máy chủ của bạn, họ có thể giải mã bảng điểm của họ. (Trừ khi PFS đã được đảm bảo - nếu bạn không biết, nó không phải.)

Làm thế nào để tôi phục hồi trên một khách hàng?

Chỉ có vài tình huống trong đó ứng dụng khách bị ảnh hưởng. Vấn đề ở phía máy chủ là bất kỳ ai cũng có thể kết nối với máy chủ và khai thác lỗi. Để khai thác khách hàng, phải đáp ứng ba điều kiện:

  • Chương trình khách hàng đã sử dụng một phiên bản lỗi thư viện OpenSSL để thực hiện giao thức SSL.
  • Máy khách đã kết nối với máy chủ độc hại. (Vì vậy, ví dụ, nếu bạn kết nối với một nhà cung cấp email, đây không phải là một mối quan tâm.) Điều này đã xảy ra sau khi chủ sở hữu máy chủ nhận thức được lỗ hổng, vì vậy có lẽ sau 2014-04-07.
  • Quy trình khách hàng có dữ liệu bí mật trong bộ nhớ không được chia sẻ với máy chủ. (Vì vậy, nếu bạn chỉ cần chạy wget để tải xuống tệp, không có dữ liệu nào bị rò rỉ.)

Nếu bạn đã làm điều đó từ 2014-04-07 buổi tối UTC và nâng cấp thư viện OpenSSL của bạn, hãy xem xét bất kỳ dữ liệu nào trong bộ nhớ của quá trình khách hàng bị xâm phạm.

Tài liệu tham khảo


71
2018-04-08 10:02



Tôi không tin rằng "Chỉ phía máy chủ của các kết nối SSL / TLS bị ảnh hưởng" là đúng. openssl.org/news/secadv_20140407.txt nói rằng nó có thể tiết lộ bí mật từ khách hàng hoặc máy chủ. ubuntu.com/usn/usn-2165-1 đồng ý. Cơ hội bạn đang sử dụng chứng chỉ ứng dụng khách trong khi kết nối với máy chủ độc hại là nhỏ nhưng khả năng tồn tại. - armb
@armb Bạn thực hiện một điểm tốt. Nó thậm chí không quan trọng cho dù giấy chứng nhận khách hàng được sử dụng, rò rỉ dữ liệu không liên quan đến việc sử dụng các chứng chỉ. tôi có tranh thủ sự giúp đỡ của các chuyên gia. - Gilles
Chứng chỉ ứng dụng khách là trường hợp bạn sẽ rò rỉ khóa riêng tư, nhưng có, mật khẩu, cookie ủy quyền, vv có thể bị rò rỉ. Tuy nhiên, với một client dựa trên OpenSSL như curl hoặc wget trong cách sử dụng điển hình, bạn sẽ không có bí mật cho các trang web khác trong bộ nhớ khi kết nối với một máy chủ độc hại, vì vậy trong trường hợp đó tôi nghĩ rằng sự rò rỉ duy nhất sẽ là nếu bạn cung cấp cho khách hàng bí mật dự đoán sẽ đưa họ đến một trang web hợp pháp và Heartbleed đã rò rỉ chúng trong khi bắt tay trước khi xác minh chứng chỉ cho thấy bạn không được kết nối với đúng trang web. - armb
@Gilles Bạn có thể quan tâm đến câu trả lời cho Những khách hàng nào được chứng minh là dễ bị tổn thương bởi Heartbleed?. Tôi quản lý để đạt được "thú vị" bộ nhớ trên nginx (chế độ proxy), wget, liên kết và những người khác. - Lekensteyn
@ MuhamedHuseinbašić Gói openssl chứa các công cụ dòng lệnh. Nó không được sử dụng bởi các ứng dụng sử dụng thư viện OpenSSL để thực hiện giao thức SSL (như Apache). Nhưng bạn chỉ nên áp dụng các bản cập nhật bảo mật của bản phân phối. - Gilles


Để xem phiên bản OpenSSL nào được cài đặt trên Ubuntu chạy:

dpkg -l | grep openssl

Nếu bạn thấy kết quả đầu ra của phiên bản sau, cần bao gồm bản vá cho CVE-2014-0160.

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

Nhìn https://launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12, nó cho thấy loại lỗi nào được sửa:

...
 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
...

40
2018-04-08 06:40



Tôi đã nâng cấp và nhận phiên bản 5.12 nhưng công cụ này vẫn cho tôi biết rằng tôi dễ bị tổn thương filippo.io/Heartbleed Suy nghĩ? - toxaq
Tôi đã thử nghiệm các máy chủ cập nhật của chúng tôi ở phía bên này và nó nói với tôi rằng tôi không bị ảnh hưởng. Bạn đã khởi động lại hệ thống của mình hay ít nhất bạn có chắc chắn rằng tất cả các quy trình cần thiết đã được khởi động lại chưa? - crimi
Sau khi cập nhật OPENSSL, tất cả những gì tôi phải làm là khởi động lại dịch vụ apache, nhưng duyên dáng đã không giúp. Tôi phải đi và khởi động lại bằng cách sử dụng sudo service apache2 restart - Tom Hert
Tôi chỉ tìm thấy nguyên nhân gây tổn thương của tôi: tôi đã cài đặt mod-spdy-beta. Sau khi gỡ bỏ nó và khởi động lại apache, tất cả các thử nghiệm đều có màu xanh lá cây. - Andreas Roth
Đang cập nhật openssl không sửa các ứng dụng như Apache, Nginx hoặc postfix. Bạn phải cập nhật libssl1.0.0 và khởi động lại chúng như được giải thích trong các bài viết khác. - tnj


Nếu là của bạn kho lưu trữ apt-get không chứa bất kỳ phần mềm nào được biên dịch trước 1.0.1g OpenSSL phiên bản, vì vậy chỉ cần tải xuống các nguồn từ trang web chính thức và biên dịch nó.

Bên dưới dòng lệnh đơn để biên dịch và cài đặt phiên bản openssl cuối cùng.

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

Thay thế tệp nhị phân openssl cũ bằng tệp mới thông qua liên kết tượng trưng.

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

Bạn là tất cả tốt!

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

Cf cái này bài viết trên blog.

NB: Như đã nêu trong bài đăng trên blog, cách giải quyết này sẽ không khắc phục được "Nginx và máy chủ Apache phải biên dịch lại với các nguồn openSSL 1.0.1g".


17
2018-04-08 02:18



Như thường thì Ubuntu không cung cấp phiên bản ngược dòng mới nhưng đã vá các phiên bản cho tất cả các bản phát hành được hỗ trợ để giữ các thay đổi ở mức tối thiểu. - Florian Diesch
Lưu ý: Đảm bảo bạn khởi động lại máy chủ của mình sau khi cập nhật OpenSSL. Apache và Nginx đã chọn thư viện mới và lỗ hổng đã bị đóng. - dAngelov
Heh, bây giờ tôi dành thời gian để đọc chi tiết của bài đăng này, tôi thậm chí còn kinh khủng hơn - tải xuống một tarball từ một số địa điểm ngẫu nhiên ngoài Internet, giải nén và thực thi các phần của nó như là root chỉ là hành vi liều lĩnh. Nó sẽ tốt hơn một chút nếu chữ ký tarball được tải xuống và kiểm tra, nhưng chắc chắn rằng bạn xác nhận chữ ký đã được ký bằng phím bên phải là một câu hỏi khó. Các bản phân phối đã đi đến nỗ lực để đảm bảo xuất xứ an toàn của tarballs và các bản vá lỗi. Cảm ơn. - sarnold
nó có thể là một ý tưởng tốt để biên dịch từ NGAY BÂY GIỜ, và cài đặt một phiên bản mới hơn sau này từ apt, theo cách đó của bạn an toàn hơn không mong đợi trên các phiên bản cũ của ubuntu dù sao chỉ là hai xu của tôi - nwgat
@sarnold openssl.org dường như không phải là một nơi ngẫu nhiên để tải xuống mã nguồn cho openssl. Canonical nên thực hiện điều này không cần thiết, nhưng openssl.org Nên là thượng nguồn có thẩm quyền để làm việc. - Rustavore


Đối với những người không muốn nâng cấp gói máy chủ. Tôi đọc một loạt các hướng dẫn này ngày hôm nay và apt-get upgrade openssl === apt-get upgrade điều này sẽ áp dụng tất cả các bản sửa lỗi bảo mật do máy của bạn yêu cầu. Tuyệt vời, trừ khi bạn đang nghiêng một cách rõ ràng trên một phiên bản gói cũ ở đâu đó.

Đây là hành động tối thiểu cần thiết trên Ubuntu 12.04 LTS chạy Apache 2:

  • Đi đến Địa chỉ này và chứng minh bạn có lỗ hổng. Bạn nên sử dụng ĐỊA CHỈ BÊN NGOÀI TRỰC TIẾP TRỰC TIẾP CỦA BẠN. Nếu bạn sử dụng loadbalancer (ví dụ như ELB), bạn có thể không liên lạc trực tiếp với máy chủ web của bạn.

  • Chạy lớp lót 1 sau để nâng cấp các gói và khởi động lại. Có, tôi đã thấy tất cả các hướng dẫn nói rằng bạn nên có một dấu thời gian muộn hơn ngày 4 tháng 4 năm 2014, điều này dường như không đúng với tôi.

    apt-get update && apt-get cài đặt openssl libssl1.0.0 && /etc/init.d/apache2 khởi động lại

  • Đảm bảo bạn đã cài đặt các phiên bản gói thích hợp và kiểm tra máy chủ web của bạn để biết lỗ hổng một lần nữa.

Các gói chính như sau, tôi xác định thông tin này bằng cách sử dụng lệnh dưới đây sau đó chỉnh sửa đi các cruft (bạn không cần phải biết nhiều về trạng thái của máy của tôi).

$ 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 KHÔNG nên chứa lỗ hổng. Đảm bảo đây là trường hợp của một lần nữa đi đến trang web dưới đây, và thử nghiệm máy chủ web của bạn.

http://filippo.io/Heartbleed/


12
2018-04-08 21:56



Sử dụng một trang web bên ngoài để chứng minh một lỗ hổng trong máy chủ có vẻ là cách tiếp cận sai với tôi. - Rinzwind
Các kịch bản kiểm tra lỗ hổng bên ngoài ngày càng trở nên phổ biến hơn trong những ngày này. Nó thực hiện chính xác nội dung của một tập lệnh nội bộ, kết nối chỉ được khởi tạo từ máy chủ web bên ngoài. Bạn có thể xem các trang như WhiteHatSecurity.com để biết ví dụ về chương trình khởi tạo tất cả các kết nối từ xa. Có những trường hợp mà điều này sẽ không bay, ví dụ như kiểm tra lỗ hổng mạng nhưng để thử nghiệm một máy chủ web quay mặt về phía trước (nói chung một máy chủ SSL sẽ), điều này gần như là lý tưởng. - Adrian
Tại sao cài đặt gói nếu nó đang được nâng cấp? - Braiam
apt-get install openssl libssl1.0.0 đã làm điều đó cho tôi. Đang chạy openssl version -a bây giờ cho thấy: built on: Mon Apr 7 20:33:29 UTC 2014 - topher
"Các kịch bản kiểm tra lỗ hổng bên ngoài ngày càng trở nên phổ biến hơn trong những ngày này". Điều đó mở ra khả năng trang web bên ngoài đó lạm dụng hệ thống của tôi: tất cả những gì họ cần biết là không thành công và hack hệ thống của tôi trước khi tôi vá nó. Không, đây không phải là cách chính xác. (và có tôi lưu trữ các trang web của riêng tôi với apache và openssl). - Rinzwind


Tôi nhận thấy nhiều người bình luận ở đây cần được giúp đỡ khẩn trương. Họ đang làm theo các hướng dẫn, và nâng cấp, và khởi động lại, và vẫn còn dễ bị tổn thương khi sử dụng một số trang web thử nghiệm.

Bạn phải kiểm tra để chắc chắn rằng bạn không có các gói bị giữ như 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.

Để nâng cấp những apt-mark unhold libssl1.0.0 (ví dụ). Sau đó nâng cấp: apt-get upgrade -V. Sau đó, khởi động lại dịch vụ bị ảnh hưởng.


11
2018-04-08 17:51