Có bạn dễ bị tổn thương về mặt kỹ thuật . Vì vậy, nếu bạn cảm thấy muốn hoảng loạn hoặc thanh toán cho một khách hàng hoảng loạn trong vài giờ làm việc hoảng loạn, hãy đi cho nó!
Nhưng thực tế là trừ khi bạn cho phép truy cập SSH từ các kết nối từ xa hoặc máy chủ web chạy kịch bản phía máy chủ, bạn sẽ không gặp rủi ro. Bạn chỉ thực sự dễ bị tổn thương nếu ai đó mà bạn không biết có thể truy cập từ xa vào máy của bạn và thực hiện theo cách mà lệnh Bash có thể được thực thi.
Có nghĩa là máy Mac để bàn của bạn mà thực sự không chạy các ứng dụng máy chủ thuộc bất kỳ loại nào thì không có rủi ro nghiêm trọng. Tôi sẵn sàng ăn một số câu tục ngữ khiêm tốn ở đây, nhưng tôi không nghĩ rằng phần lớn người dùng Mac sẽ gặp rủi ro vào cuối ngày.
Vì vậy, vấn đề này chủ yếu liên quan đến các quản trị viên hệ thống trên các máy chủ Mac OS X & Unix / Linux tiếp xúc với thế giới, không phải người dùng máy tính để bàn không kích hoạt chia sẻ SSH.
Có lẽ có nguy cơ cạnh tranh về phần mềm độc hại hoặc vi-rút Mac được tạo ra để khai thác rủi ro này, nhưng tôi nghi ngờ về điều đó.
EDIT: Và chỉ để giải thích vấn đề này như thế nào theo quan điểm khiêm tốn của tôi. Không thực sự là vấn đề đối với hầu hết người dùng trung bình, vâng tôi có thể chạy lệnh sau từ bashtrên Mac OS X 10.9.5:
env x='() { :;}; echo vulnerable' bash -c 'echo hello'
Và tôi thấy điều này:
vulnerable
hello
Đoán xem cái gì? Điều đó chỉ đáng sợ nếu bạn không nghĩ ra điều này một cách hợp lý. Tôi đã phải đăng nhập vào máy Mac của mình để mở Terminal. Và để phủ nhận những gì tôi đã nói về SSH ở trên, thậm chí đến mức tôi có thể chạy thử nghiệm này ngay cả khi SSH được bật, tôi vẫn sẽ phải đăng nhập để bắt đầu. Và sau đó, hãy để tôi nói rằng tôi có quyền truy cập thông qua SSH, lệnh không cho phép tôi thực hiện BẤT CỨ điều gì qua các quyền người dùng thông thường của mình như thế này:
env x='() { :;}; echo vulnerable' bash -c 'cat /etc/ssh_host_rsa_key'
Có nghĩa là nếu bạn thực sự dễ bị khai thác bởi vụ hack này, bảo mật cốt lõi của bạn trên hệ thống sẽ phải bị tổn hại đến mức thực tế bashcó một lỗ hổng thực sự là vấn đề tối thiểu của bạn.
Đây là một mối quan tâm từ một vấn đề kiểm soát và quyền tổng thể vì nó có khả năng cho phép truy cập ngoài ý muốn vì hành vi mở rộng ra ngoài các quy tắc dự kiến. Nhưng theo quan điểm khiêm tốn của tôi, đó không phải là rủi ro ngang với OpenSSL hay giống vườn khác, hãy để tôi để lại mật khẩu của mình trên một ghi chú được ghi vào rủi ro trên màn hình của tôi.
Cuối cùng, tôi vẫn đang vá tất cả các máy chủ Linux / Unix mà tôi chạy như một quy trình chuẩn. Và sẽ vui vẻ vá các máy Mac mà tôi quản lý sau khi đã khắc phục xong. Nhưng để sử dụng hàng ngày thực tế, tôi cảm thấy ổn khi không lo lắng về điều này vì tôi không hiểu làm thế nào một lỗ hổng không cho phép các đặc quyền người dùng nâng cao thêm vào bất cứ điều gì.
CẬP NHẬT: Từ chính thức từ Apple được đăng ở đây ; nhấn mạnh của tôi:
Một phần lớn người dùng OS X không gặp rủi ro với các lỗ hổng bash được báo cáo gần đây ", một phát ngôn viên của Apple nói với iMore. kiểm soát các hệ thống dễ bị tổn thương. Với OS X, các hệ thống được an toàn theo mặc định và không bị khai thác từ xa bash trừ khi người dùng định cấu hình các dịch vụ UNIX tiên tiến.
Chúng tôi đang nỗ lực để nhanh chóng cung cấp bản cập nhật phần mềm cho người dùng UNIX tiên tiến của mình.
Dịch: Những gì tôi đã nói ở trên về việc đây là sự cố máy chủ & không phải là sự cố máy khách? Chính xác.
MỘT UDPATE CUỐI CÙNG: Đối với bất kỳ ai gặp khó khăn trong việc biên dịch từ nguồn, kể từ ngày 29 tháng 9, Apple đã chính thức phát hành bản vá cho Mac OS X 10.9.5, 10.8.5 cũng như 10.7.5:
CẬP NHẬT CUỐI CÙNG KHÁC: Và bây giờ, Apple vừa phát hành bản cập nhật bảo mật kết hợp hôm nay bao gồm cả bashbản cập nhật !
Lưu ý: Cập nhật bảo mật 2014-005 bao gồm nội dung bảo mật của OS X bash Update 1.0