it-swarm-vi.com

Làm thế nào để tiết lộ một lỗ hổng bảo mật trong một cách có đạo đức?

Làm thế nào để tiết lộ một lỗ hổng bảo mật một cách có đạo đức? Tôi đã nghe nói có nhiều trường phái khác nhau về chủ đề này. Tôi muốn biết những ưu/nhược điểm của từng loại.

75
Olivier Lalonde

Bạn nên cho (các) nhà phát triển biết riêng tư để họ có cơ hội sửa nó. Sau đó, nếu và khi bạn công khai với lỗ hổng, bạn nên cho phép nhà phát triển có đủ thời gian để khắc phục sự cố và bất cứ ai tiếp xúc với nó đủ thời gian để nâng cấp hệ thống của họ. Cá nhân, tôi sẽ cho phép nhà phát triển đưa ra thông báo trong một bản tin bảo mật trong hầu hết các trường hợp thay vì tự thông báo. Ít nhất, tôi sẽ chờ xác nhận rằng lỗ hổng đã được sửa. Nếu bạn có thời gian và có quyền truy cập vào mã nguồn, bạn cũng có thể cung cấp một bản vá.

43
VirtuosiMedia

Cá nhân tôi nghĩ Tiết lộ có trách nhiệm dường như là cách tốt nhất để đi từ điểm đạo đức và làm việc tốt cho Dan Kaminsky tiết lộ chi tiết về lỗ hổng ngộ độc bộ đệm DNS. Nhưng tất cả phụ thuộc rất lớn vào công ty hoặc nhóm bạn đang làm việc và cả cơ sở người dùng mà nó sẽ ảnh hưởng.

27
Mark Davidson

@VirtuosiMedia thực hiện một công việc tuyệt vời là phác thảo "Tiết lộ có trách nhiệm".

Tôi sẽ thêm hai điểm:

  • Làm việc với nhà cung cấp (nếu bạn có thể), để đảm bảo họ hiểu đầy đủ về nó và không đưa ra một bản vá nửa nướng.
  • Nếu nhà cung cấp coi thường bạn hoặc bỏ qua bạn, hãy tiếp tục cố gắng. Tuy nhiên, nếu họ cho rằng đó không phải là một lỗ hổng, hãy tiếp tục và xuất bản. Càng to càng tốt. Nếu họ hứa sẽ sửa, nhưng đừng, hãy cố gắng nhận được câu trả lời từ họ, cùng với một mốc thời gian rõ ràng mà họ cam kết. Tại một số điểm, nếu họ tiếp tục hoãn, cuối cùng bạn có thể muốn nói với họ rằng bạn sẽ xuất bản bằng mọi cách - và sau đó cho họ một chút thời gian để thực sự sửa nó (nhưng ngắn và hạn chế.)
18
AviD

Đây là một trong những chủ đề phức tạp. Tôi đã tham gia vào việc tiết lộ lỗi đàm phán lại TLS vài năm trước, và tin tôi đi, chúng tôi đã rất cố gắng để "chịu trách nhiệm", nhưng cuối cùng, chúng tôi đã thành công trong việc chọc giận mọi người xung quanh và (có lẽ) trì hoãn bản phát hành thực tế của bản sửa lỗi. Không phải nói rằng thông báo của nhà cung cấp nhất thiết là xấu, chỉ có điều nó thực sự dễ bị đánh đòn và gây ra nhiều tác hại như tốt, hoặc tệ hơn.

Trong trường hợp của chúng tôi, đã có một hành động của IETF ( RFC 5746 ) để giải quyết vấn đề, và mặc dù chúng tôi đã có một bản thảo internet sẵn sàng vào ngày nó bị rò rỉ, công việc thực tế là tranh luận và quyết định giải pháp mất khoảng ba tháng nữa và không thực sự bắt đầu một cách nghiêm túc cho đến khi việc tiết lộ diễn ra.

Dù sao, đây không phải là một câu trả lời cho câu hỏi của bạn, nhưng nó là một trong những câu chuyện tiết lộ thú vị hơn mà tôi biết. Thêm thông tin về câu chuyện đó trong 2010 bài phát biểu của ShmooCon Tôi đã làm với Marsh Ray, người đã phát hiện ra vấn đề.

11
Steve Dispensa

Nói chung, nó phụ thuộc vào phản ứng của nhà cung cấp. Thực hành tốt là khi nhà nghiên cứu bảo mật thông báo cho nhà cung cấp về lỗ hổng, sau đó trong cuộc trò chuyện, bạn nói về các điều khoản xuất bản của poc/khai thác lỗ hổng này. Trên thực tế, nhà nghiên cứu chọn làm gì với lỗ hổng này - xuất bản sau hay không. Sau đó, nhà cung cấp phát hành bản vá hoặc phiên bản sản phẩm mới. Có lẽ. Nhưng, làm thế nào kinh nghiệm cho thấy - không phải tất cả các nhà cung cấp là rất tốt đẹp. Một số trong số họ sửa lỗi âm thầm, mà không thông báo cho người dùng cuối và nhà nghiên cứu, một số thích bỏ qua nhà nghiên cứu. Những người khác thậm chí cố gắng kiện. Đó là lý do tại sao đôi khi ẩn danh là cách tốt nhất để giao tiếp ban đầu với nhà cung cấp không xác định.

Ngoài ra, tôi muốn thừa nhận rằng có các chương trình phần thưởng tiền thưởng lỗi - những chương trình được cung cấp bởi Google, Mozilla. Bên cạnh đó, những người khác mua lỗ hổng - ZDI , iDefense , SNOsoft , sắp tới "khai thác trung tâm" và vv Vì vậy, có ít nhất ba cách để thông báo cho nhà cung cấp - trực tiếp, bằng cách xuất bản thông tin lỗ hổng trên một số danh sách hoặc thông qua các công ty bên thứ ba.

8
anonymous

Nếu họ có trình theo dõi sự cố công khai, hãy xem liệu bạn có thể gửi lỗi với nhãn "riêng tư" hoặc "bảo mật" không.

Bất kể họ có trình theo dõi sự cố hay không, email [email protected] tên công ty và cho họ biết.

Nếu họ không trả lời khá kịp thời (xem "Cửa sổ tiết lộ" trong bài viết của Schneier bên dưới) thì bạn cần suy nghĩ về việc tiết lộ rộng rãi hơn. Tìm kiếm danh sách gửi thư mà các học giả/chuyên gia bảo mật ẩn giấu và hỏi họ làm thế nào họ báo cáo vấn đề với nhà cung cấp trong câu hỏi. Họ có thể có thể giới thiệu đến đúng nơi trong tổ chức.

Nếu tất cả điều đó không thành công, hãy đọc bit Schneier và suy nghĩ xem liệu công bố đầy đủ sẽ là một phần của vấn đề hay là một phần của giải pháp.

Bruce Schneier đưa ra một lập luận cho công bố đầy đủ trong một số trường hợp nhất định dựa trên tiêu chuẩn "là một phần của giải pháp, không phải là một phần của vấn đề". Nó chắc chắn đáng để đọc.

Đây là cuộc tranh luận "bảo mật lỗi so với công bố đầy đủ" cổ điển. Tôi đã viết về nó trước đây bằng Crypto-Gram; những người khác đã viết về nó là tốt. Đây là một vấn đề phức tạp với những hàm ý tinh vi trên toàn bộ bảo mật máy tính và đó là một vấn đề đáng để thảo luận lại.

...

Luồng thông tin miễn phí này, cả mã mô tả và mã bằng chứng, cũng rất quan trọng đối với nghiên cứu bảo mật. Nghiên cứu và phát triển về bảo mật máy tính đã nở rộ trong thập kỷ qua, và phần lớn trong số đó có thể được quy cho phong trào công bố đầy đủ. Khả năng công bố kết quả nghiên cứu - cả tốt và xấu - dẫn đến bảo mật tốt hơn cho mọi người. Không có công bố, cộng đồng bảo mật không thể học hỏi từ những sai lầm của nhau. Mọi người phải hoạt động với người mù trên, lặp đi lặp lại những sai lầm tương tự. Tiết lộ đầy đủ là điều cần thiết nếu chúng ta tiếp tục cải thiện tính bảo mật của máy tính và mạng.

...

Thứ hai, tôi tin vào việc thông báo trước cho nhà cung cấp. CERT đã đưa điều này đến mức cực đoan, đôi khi khiến nhà cung cấp mất nhiều năm để khắc phục vấn đề.

...

Tôi thích số liệu "là một phần của giải pháp, không phải là một phần của vấn đề". Nghiên cứu bảo mật là một phần của giải pháp. Thuyết phục các nhà cung cấp để khắc phục vấn đề là một phần của giải pháp. Gieo nỗi sợ là một phần của vấn đề. Bàn giao các công cụ tấn công cho thanh thiếu niên không biết gì là một phần của vấn đề.

6
Mike Samuel