Chúng ta có thể học được gì từ những sai hỏng về an ninh?

What can we learn f-rom security failures?

Posted on by Rowan Wilson, Posted on March 20, 2014

Theo: http://osswatch.jiscinvolve.org/wp/2014/03/20/what-can-we-learn-f-rom-security-failures/

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

Lời người dịch: Phần mềm nào cũng có lỗi, phần mềm tự do nguồn mở cũng vậy. Tuy nhiên điều đó không có nghĩa là không nên mở mã nguồn. “Chúng ta chỉ phải chấp nhận rằng tính sẵn sàng của mã nguồn bản thân nó không có hiệu ứng nào. Nó tạo thuận lợi cho rà soát lại và cải thiện mã, nếu có thiện chí để thực hiện công việc đó. Nó làm cho dễ dàng để chia sẻ chính xác những gì một lỗi từng là một khi nó được tìm ra, và tới lượt nó làm dễ dàng hơn cho những người duy trì các kho mã khác kiểm tra nguồn của riêng họ đối với các vấn đề tương tự. Cuối cùng nó cho phép bất kỳ ai thấy một vấn đề và tự họ sửa nó, và chia sẻ sửa lỗi đó”.

Sau khi tải bài lên về lỗi gotofail của Apple, là đáng tiếc để nói về một lỗi nghiêm trọng, chính trong phần mềm nguồn mở quá sớm. Lần này còn nghiêm trọng hơn, theo đó nó đã tồn tại hơn 10 năm, và nhiều mẩu phần mềm nguồn mở khác được triển khai theo một cách tiêu chuẩn dựa vào.

Lỗi này nghiêm trọng tương tự như của Apple, theo đó nó xảy ra như là kết quả của mã có ý định để đánh tín hiệu một lỗi nhưng thông qua một lỗi lập trình tinh quái trong thực tế không làm được điều đó. Lỗi này được thấy như là kết quả của một kiểm toán do nhà cung cấp Linux Red Hat ủy quyền, và lỗi đó được phát hiện và được tác giả của chính nó xuất bản. Những gì chúng ta học được từ 2 lỗi đó trong mã nguồn ở sống còn về an ninh? Trước hết, có thể dẫn chúng ta tới việc đặt câu hỏi cho cái gọi là 'Luật Linus', do Eric Raymond ghi lại:

Miễn là có đủ số lượng lớn những người kiểm thử bản beta và kho các lập trình viên, hầu hết mọi vấn đề sẽ được đặc trưng nhanh chóng và ai đó rõ ràng sẽ sửa lỗi.

Điều này đôi khi được tham chiếu tới như là nguyên tắc 'nhiều con mắt', và được một số người ủng hộ nguồn mở trích dẫn như một lý do vì sao nguồn mở sẽ an ninh hơn so với nguồn đóng. Tuy nhiên, kết luận này còn gây tranh cãi, và lỗi đặc biệt này chỉ ra một lý do vì sao. Trong thảo thuận các lý do vì sao lỗi này đã có 10 năm rà soát, mà người rà soát lại/tác giả nói như sau:

Vì mã này từng là về một phần sống còn của thư viện nên nó động chạm và vì thế rất hiếm khi được đọc.

Một quan điểm ngây thơ - và nhất định là quan điểm mà tôi đã đăng ký trong quá khứ - là mã sống còn phải chắc chắn được rà soát lại thường xuyên hơn so với mã không sống còn. Dù trong thực tế, nó có thể là chủ đề của nhiều giả định, ví dụ là nó phải được thấy, vì nó quan trọng, hoặc nó không nên được sửa đổi lại với nguyên nhân và vì thế không đáng rà soát lại.

Nên chúng ta phải bỏ qua ý tưởng rằng tính sẵn sàng của mã nguồn dẫn tới an ninh tốt hơn chăng? Như tôi nói trong bài viết trước, tôi nghĩ là không. Chúng ta chỉ phải chấp nhận rằng tính sẵn sàng của mã nguồn bản thân nó không có hiệu ứng nào. Nó tạo thuận lợi cho rà soát lại và cải thiện mã, nếu có thiện chí để thực hiện công việc đó.

Nó làm cho dễ dàng để chia sẻ chính xác những gì một lỗi từng là một khi nó được tìm ra, và tới lượt nó làm dễ dàng hơn cho những người duy trì các kho mã khác kiểm tra nguồn của riêng họ đối với các vấn đề tương tự. Cuối cùng nó cho phép bất kỳ ai thấy một vấn đề và tự họ sửa nó, và chia sẻ sửa lỗi đó. Những gì chúng ta phải không làm là giả thiết rằng vì nó là nguồn mở nên ai đó đã rà soát lại nó rồi, và – nếu tất cả sự cố này dạy bất kỳ điều gì - thì nó là chúng ta phải giải thiết rằng mã cũ kỹ, sống còn đó cần thiết là tự do khỏi các lỗi ngớ ngẩn.

After posting on the Apple goto fail bug, it is regrettable to have to talk about another serious, major bug in open source software so soon. This time it is more serious still, in that it has existed for over ten years, and is relied upon by many other pieces of standardly deployed open source software. The bug is strikingly similar to Apple’s, in that it happens as a result of code which is intended to signal an error but which through a subtle programming fault in fact fails to do so. This bug was found as a result of an audit commissioned by commercial Linux provider Red Hat, and the bug was discovered and publicised by its own author. What can we learn f-rom these two failures in security critical open source code? For a start, it might lead us to question the so-called ‘Linus’ Law‘, first recorded by Eric Raymond:

Given a large enough beta-tester and co-developer base, almost every problem will be c-haracterized quickly and the fix will be obvious to someone.

This is sometimes referred to as the ‘many eyes’ principle, and is cited by some open source proponents as a reason why open source should be more secure than closed source. This conclusion is, however, controversial, and this particular bug shows one reason why. In discussing the reasons why this bug slipped through ten years worth of review, the reviewer/author says the following:

As this code was on a critical part of the library it was touched and thus read, very rarely.

A naive view – and certainly one I’ve subscribed to in the past – is that critical code must surely get reviewed more frequently than non-critical code. In practice though, It can be the subject of a lot of assumptions, for example that it must be sound, given its importance, or that it should not be tinkered with idly and so is not worth reviewing.

So must we abandon the idea that source code availability leads to better security? As I said in the previous post, I think not. We just have to accept that source code availability in itself has no effect. It facilitates code review and improvement, if there’s a will to undertake that work. It makes it easy to share exactly what a bug was once it was found, and in turn it makes it easier for maintainers of other code bases to examine their own source for similar issues. Finally it allows anyone who finds a problem to fix it for themselves, and to share that fix. What we must not do is assume that because it is open source someone has already reviewed it, and – if this incident teaches anything at all – we must not assume that old, critical code is necessarily free of dumb errors.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com