Nếu tất cả các lỗi sẽ cạn, vì sao Heartbleed chỉ vừa mới được sửa?

Thứ ba - 15/04/2014 06:12
P { margin-bottom: 0.21cm; }A:link { }

If all bugs are shallow, why was Heartbleed only just fixed?

Posted on by Mark Johnson, Posted on April 10, 2014 by Mark Johnson

Theo: http://osswatch.jiscinvolve.org/wp/2014/04/10/if-all-bugs-are-shallow-why-was-heatbleed-only-just-fixed/

Bài được đưa lên Internet ngày: 10/04/2014

Lời người dịch: Đây là bài viết của Mark Johnson, Giám đốc Phát triển ở OSS Watch, cơ quan tư vấn về phần mềm tự do nguồn mở cho chính phủ Anh, giải thích về lỗi “Heartbleed” trong OpenSSL. Để biết nhiều hơn về an ninh trong phần mềm nguồn mở, hãy kiểm tra tóm tắt của OSS Watch về chủ đề này. Xem thêm hệ thống tư vấn của OSS Watch về nguồn mở cho chính phủ Anh.

Tuần này Internet nóng với tin tức về một lỗi an ninh khác trong một dự án nguồn mở được sử dụng rộng rãi. lần này lỗi đó trong OpenSSL có tên là “Heartbleed”.

Đây là vấn đề an ninh cao cấp thứ 3 trong nhiều tháng qua. Trong từng trường hợp mã từng không chỉ mở mà còn đang được hàng ngàn người sử dụng, bao gồm một số công ty công nghệ lớn nhất thế giới, và từng diễn ra ở chỗ cho một khoảng thời gian dài đáng kể.

Trong tiểu luận năm 1999 của mình Nhà thờ lớn và cái chợ, Eric Raymond đã nêu rằng “Đủ con mắt soi vào, tất cả các lỗi sẽ cạn”. Nếu qui tắc này (được gọi là Luật Linus của Raymond, đối với Linus Torvalds) vẫn còn đúng, thì làm thế nào các lỗi đó có thể tồn tại một thời gian dài như vậy trước khi được sửa?

Hãy bắt đầu bằng việc nhìn vào những gì chúng ta ngụ ý một “lỗi”. Nói chung khái niệm “lỗi” tham chiếu tới bất kỳ khiếm khuyết nào trong mã của một chương trình, khi mà nó không hoạt động theo yêu cầu. Định nghĩa đó chắc chắn áp dụng trong tất cả mọi trường hợp, nhưng đối với một lỗi sẽ được báo cáo, thì nó phải ảnh hưởng tới mọi người theo một cách có khả năng lưu ý được. Nhiều lỗi đặc biệt mà chúng ta đang nói tới ở đây, các lỗi an ninh trong các thư viện mã hóa, không ảnh hưởng tới đa số nói chung những người sử dụng, thậm chí ở những nơi chúng ta đang nói về những người sử dụng ở phạm vi mà chúng ta thấy ở đây. Chỉ khi mọi người cố gắng và sử dụng phần mềm theo một cách thức khác điều nó dự định, hoặc kiểm toán mã một cách đặc biệt khi tìm kiếm các vấn đề như vậy, thì các lỗi đó mới trở nên rõ ràng.

Khi Raymond nói về các lỗi đang cạn, ông thực sự đang nói về cách mà nhiều người xem xét một vấn đề được đưa ra sẽ thấy lý do và giải pháp nhanh hơn so với một người xem xét vấn đề đó. Trong tiểu luận đó, Raymond trích lời Torvalds nói “Tôi sẽ tiếp tục ghi lại khi nói rằng việc tìm kiếm [lổi] là thách thức lớn hơn”.

Nên vấn đề mà chúng ta đã và đang thấy ở đây không là các lỗi mất thời gian dài để chuẩn đoán và sửa, thay vào đó là sự thiếu tác động của chúng lên sử dụng có ý định của phần mềm nghĩa là chúng đã mất thời gian dài để được lưu ý thấy. Luật Linus vẫn là đúng, nhưng nó không là thuốc chữa bách bệnh cho an ninh. Các sự kiện gần đây khẳng định rằng mã nguồn mở hoặc đóng vốn dĩ không an ninh hơn nhau.

Để biết nhiều hơn về an ninh trong phần mềm nguồn mở, hãy kiểm tra tóm tắt của chúng tôi về chủ đề này.

This week the Internet’s been ablaze with news of another security flaw in a widely used open source project, this time a bug in OpenSSL dubbed “Heartbleed”.

This is the third high-profile security issue in as many months. In each case the code was not only open but being used by thousands of people including some of the world’s largest technology companies, and had been in place for a significant length of time.

In his 1999 essay The Cathedral and The Bazaar, Eric Raymond stated that “Given enough eyeballs, all bugs are shallow.” If this rule (dubbed Linus’s Law by Raymond, for Linus Torvalds) still holds true, then how can these flaws exist for such a long time before being fixed?

Let’s start by looking at what we mean by a “bug”.  Generally speaking the term “bug” refers to any defect in the code of a program, whe-reby it doesn’t function as required.  That definition certainly applies in all these cases, but for a bug to be reported, it has to affect people in a noticeable way. The particular variety of bugs we’re talking about here, security flaws in encryption libraries, don’t affect the general population of users, even whe-re we’re talking about users on the scale we see here.  It’s only when people try and use the software in a way other than it’s intended, or specifically audit code looking for such issues, that these bugs become apparent.

When Raymond talks about bugs being shallow, he’s really talking about how many people looking at a given problem will find the cause and solution more quickly than one person looking at that problem.  In the essay, Raymond quotes Torvalds saying “I’ll go on record as saying that finding [the bug] is the bigger challenge.”

So the problem we’ve been seeing here isn’t the the bugs took a long time to diagnose and fix, instead it’s that their lack of impact on the intended use of the software means they’ve taken a long time to be noticed.  Linus’s Law still holds true, but it’s not a panacea for security. The recent events affirm that neither open or closed code is inherently more secure.

For more about security in open source software, check out our briefing on the subject.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Tổng số điểm của bài viết là: 0 trong 0 đánh giá

Click để đánh giá bài viết

  Ý kiến bạn đọc

Những tin mới hơn

Những tin cũ hơn

Về Blog này

Blog này được chuyển đổi từ http://blog.yahoo.com/letrungnghia trên Yahoo Blog sang sử dụng NukeViet sau khi Yahoo Blog đóng cửa tại Việt Nam ngày 17/01/2013.Kể từ ngày 07/02/2013, thông tin trên Blog được cập nhật tiếp tục trở lại với sự hỗ trợ kỹ thuật và đặt chỗ hosting của nhóm phát triển...

Bài đọc nhiều nhất trong năm
Thăm dò ý kiến

Bạn quan tâm gì nhất ở mã nguồn mở?

Thống kê truy cập
  • Đang truy cập98
  • Máy chủ tìm kiếm2
  • Khách viếng thăm96
  • Hôm nay8,969
  • Tháng hiện tại581,831
  • Tổng lượt truy cập37,383,405
Bạn đã không sử dụng Site, Bấm vào đây để duy trì trạng thái đăng nhập. Thời gian chờ: 60 giây