Sự an toàn của phần mềm mã nguồn mở dựa trên việc sửa lỗi của cộng đồng - nhưng Heartbleed và các sự kiện khác gần đây cho thấy rằng điều đó không xảy ra.
Sự thất bại của OpenSSL Heartbleed chứng minh một cách chắc chắn những gì nhiều người đã nghi ngờ trong một thời gian dài: Mã nguồn mở chỉ có sẵn để kiểm tra nhưng không có nghĩa là nó thực sự được kiểm tra và an toàn.
Đây là một điểm quan trọng, vì sự an toàn của phần mềm mã nguồn mở dựa trên số lượng lớn các lập trình viên có kiến thức đầy đủ rà soát các mã để phát hiện tận và sửa lỗi kịp thời. Điều này được tóm tắt trong Luật của Linus: "Nếu có đủ nhân lực, tất cả các lỗi là chuyện nhỏ."
Nhưng nhìn vào những gì đã xảy ra với OpenSSL. Robin Seggelemann, một lập trình viên người Đức của trường Đại học Munster, cập nhật mã OpenSLL bằng cách thêm một chức năng để Heartbeat hoạt động. Thật không may, ông đã bỏ lỡ một hành động kiểm tra cần thiết trong mã của mình để kiểm tra xem một biến đặc biệt có giá trị thực tế. Các thành viên của nhóm phát triển OpenSSL đã kiểm tra mã trước khi cập nhật được phát hành cũng bỏ qua lỗi này. Điều này gây ra lỗi Heartbleed.
Một nhà phê bình, thậm chí một số ít người nhận xét, có thể dễ dàng bỏ lỡ một lỗi nhỏ như thế này nếu họ không biết có một lỗi được tìm thấy. Việc đáng lo ngại là, trong hai năm, các lỗi Heartbleed tồn tại trong OpenSLL, trong các trình duyệt và máy chủ web, nhưng không ai trong cộng đồng nguồn mở phát hiện nó. Không có đủ người xem xét kỹ lưỡng các mã.
Các nhà cung cấp thương mại không đánh giá mã nguồn mở
Cũng đáng báo động là OpenSSL đã được sử dụng như một thành phần trong các sản phẩm phần cứng được cung cấp bởi các nhà cung cấp thương mại như F5 Networks, Citrix Systems, Riverbed Technology và Barracuda Networks - tất cả đều thất bại trong việc rà soát mã đầy đủ trước khi sử dụng nó, theo Mamoon Yunus, Giám đốc điều hành của Forum Systems, một nhà cung cấp cổng điện toán đám mây an toàn.
"Bạn sẽ nghĩ rằng nó sẽ là trách nhiệm của tôi vì tôi là một nhà cung cấp, nếu tôi thương mại hóa OpenSSL, tôi sẽ xem xét kỹ nó", ông nói. "Bạn phải có một mức độ sở hữu mã nguồn nếu bạn xây dựng một công ty dựa trên một thành phần mã nguồn mở."
Thay vào đó, Yunus tin rằng các nhà cung cấp chỉ coi OpenSSL như một thành phần bổ sung hữu ích cho các sản phẩm phần cứng của họ - và, vì nó là mã nguồn mở, cho rằng những người khác đã kiểm tra mã nguồn. "Mọi người đều giả định những người khác đã xem xét kỹ nó. Họ cho rằng đó là trách nhiệm của hàng triệu người khác phải xem xét nó, vì vậy nó không phải là trách nhiệm của mình", ông nói. "Đó là sự cẩu thả đến từ một khía cạnh trong mã nguồn mở."
Yunus cho rằng các nhà cung cấp thương mại nên chạy các chương trình đánh giá tương tự có hiệu quả đối với bất kỳ mã nguồn mở mà họ sử dụng, chạy các công cụ phân tích tĩnh và động trên nó và "quét sạch" mã để đảm bảo nó không lỗi. "Những gì các công ty này đã làm cho 10 hoặc 15 năm trước? Nếu tôi là họ, tôi sẽ xem xét một quy trình bảo đảm chất lượng phức tạp và dài hơi."
Trong thực tế, Yunus hỏi, liệu OpenSSL đã được viết bằng một ngôn ngữ cấp thấp tương đối như C, chuyên gia bảo mật Bruce Schneier đáp lại bằng cách gợi ý nó có thể được coi là "sơ suất phạm tội" khi sử dụng một ngôn ngữ mà thiếu đi việc quản lý bộ nhớ cho một ứng dụng bảo mật nhạy cảm như vậy.
Jeffrey Hammond, một nhà phân tích an ninh tại Forrester Research, mâu thuẫn với quan điểm này. Ông chỉ ra rằng hiệu suất là một điểm quan trọng của OpenSSL vì nó có để xử lý khối lượng lớn các gói tin. "Nếu bạn có thể truy cập vào bộ nhớ bạn sẽ được mở ra một số loại tấn công, nhưng bạn sẽ có được hiệu suất," Hammond cho biết. "Tôi sẽ không nói rằng họ không bao giờ nên phát triển OpenSSL trong C, nhưng nó là sự thật hiệu suất đi cùng với trách nhiệm."
OpenSSL, Truecrypt lộ ra giới hạn của đánh giá mã nguồn mở
Một vấn đề mà rất nhiều dự án mã nguồn mở phải đối mặt với - và lý do thật khó để đổ lỗi cho Seggelemann hoặc phần còn lại của nhóm OpenSSL - là thực hiện một đánh giá an ninh nghiêm ngặt mã nguồn là việc tốn kém thời gian vô cùng và đòi hỏi một mức độ kỹ năng cao. Điều đó có nghĩa nó là rất tốn kém.
Điều này được minh họa bằng một dự án mã nguồn mở: Chương trình mã hóa TrueCrypt. Mã nguồn đã được mở cho bất cứ ai quan tâm để đánh giá nó từ khi dự án bắt đầu 10 năm trước đây - nhưng chỉ rất gần đây, sau các chiến dịch gây quỹ trên Indiegogo và Fundfill đó mang lại 60.000 USD, rằng mã nguồn đã trải qua một lần kiểm toán bảo mật thích hợp.
Một báo cáo ban đầu chỉ đánh giá vào bộ nạp khởi động và chương trình điều khiển lõi của Windows đã xác định được 11 lỗ hổng bảo mật, cho biết rằng chất lượng của các mã nguồn khá tệ và chỉ ra rằng việc biên dịch TrueCrypt từ mã nguồn yêu cầu sử dụng các công cụ xây dựng đã lỗi thời (trong một trường hợp, 21 năm) và không được ký số có thể được sửa đổi độc hại và rất khó để truy cập từ các nguồn đáng tin cậy.
Những iểm toán viên mã nguồn nói: "Nhìn chung, mã nguồn cho cả hai bộ nạp khởi động và trình điều khiển lõi Windows không đáp ứng các tiêu chuẩn dự kiến để bảo mật mã nguồn."
Điều đáng lo ngại là việc này chỉ đưa ra ánh sáng sau khi các quỹ thuê các nhân lực để đánh giá mã nguồn. Cộng đồng nguồn mở có khá nhiều cơ hội để làm điều này trong 10 năm qua - nhưng sự thật là cộng đồng không có thời gian, kỹ năng và nguồn lực (bao gồm cả tài chính) để làm công việc đúng cách.
Một vấn đề mới sẽ ảnh hưởng đến sự an toàn của OpenSSL cũng đang lộ ra: Mã nguồn đang được chia hai, nhờ một sáng kiến gọi là LibreSSL dẫn đầu bởi nhóm OpenBSD. LibreSSL được dự định là một phiên bản rút gọn của OpenSSL; trong tuần đầu tiên của dự án LibreSLL, hơn 90.000 dòng mã đã được gỡ bỏ, bao gồm cả những hệ điều hành hỗ trợ như VMS và OS/2.
Vấn đề chỉ đơn giản là: Bởi vì dễ dàng xem những gì được gỡ bỏ từ LibreSSL, và những bít được thay thế bởi vì chúng được xem là không an toàn, người sử dụng OpenSSL bị bỏ mặc tiếp xúc những tin tặc nguy hiểm có thể khai thác điểm yếu mà LibreSSL phát hiện và loại bỏ - đó là, trừ khi dự án OpenSSL không thể theo kịp với sự tiến bộ của LibreSSL.
Bảo mật bằng cách bí mật không bao giờ là một ý tưởng tốt, nhưng một khi các lỗ hổng được công bố, chúng cần phải được xử lý ngay lập tức. Không rõ nhóm OpenSSL đang ở một vị trí để làm điều đó - rằng dự án này chỉ có một nhóm duy trì toàn thời gian - hay các sản phẩm phần mềm và phần cứng mà sử dụng OpenSSL sẽ được cập nhật kịp thời ngay cả phần mềm OpenSSL.
Chú ý bảo mật mã nguồn mở nghiêm túc sau Heardbleed
Các tin tốt cho những ai quan tâm về sự an toàn của các dự án mã nguồn mở như OpenSSL là giúp đỡ có thể đúng hướng trong dự án của Sáng kiến Cơ sở hạ tầng Cốt lõi (Core Infrastructure Initiative - CII), một dự án mới được thành lập bởi Quỹ Linux để giải quyết Heartbleed. Mục đích của nó là cung cấp tài chính cần thiết vào các dự án phần mềm như OpenSSL, đó là việc quan trọng để Internet hoạt động.
"Nền kinh tế toàn cầu của chúng ta được xây dựng trên nhiều dự án mã nguồn mở," Jim Zemlin, Giám đốc điều hành Linux Foundation cho biết. "Bây giờ chúng ta sẽ có thể hỗ trợ các nhà phát triển và nhà bảo trì hơn nữa để làm việc toàn thời gian để hỗ trợ các dự án mã nguồn mở cần thiết khác."
Hỗ trợ của CII cũng có thể bao gồm kinh phí cho kiểm toán bảo mật, máy tính và kiểm tra cơ sở hạ tầng. Cho đến nay, khoảng 4 triệu USD đã được cam kết trong ba năm tới bởi các công ty như Google, Microsoft và Facebook.
Theo CIO
Thêm bình luận