Nói chuyện bảo mật với Mark Cox của Red Hat
Sunday, 13. May 2007, 14:04:23
(Quantrimang) - 13/5/2007 12h:50
Các chuyên gia IT thường mất rất nhiều thời gian để suy nghĩ về bảo mật. Họ cố gắng tìm ra những cách nhanh nhất có thể để đảm bảo cho hệ thống của mình được vá và update kịp thời nhất. Tuy nhiên những gì diễn ra trước khi các quản trị viên này nghe nói đến lỗ hổng hầu như vẫn là bức màn bí ẩn. Để có được bức tranh rõ ràng hơn, chúng ta hãy lắng nghe ý kiến của Mark Cox, đội trưởng đội phản ứng bảo mật của Red Hat về xu hướng trong bảo mật Linux, những ai thường khám phá ra các lỗ hổng bảo mật, tốc độ phát triển của chúng và những biện pháp tối thiểu vấn đề gặp phải có thể thực hiện.
Trước tiên là đôi chút về Mark Cox, chuyên gia bảo mật hàng đầu của Red Hat. Thú vui bảo mật bắt đầu làm Cox hứng thú từ 12 năm trước đây, khi anh phát hiện ra một số vấn đề bảo mật ở Web Server HTTPd của National Center for Supercomputing Aplications (NCSA) - Trung tâm quốc gia về các ứng dụng siêu máy tính. “Nhanh chóng sau đó tôi thấy rằng tổ chức hoạt động C2Net châu Âu, nơi tôi phát triển sever Web Stronghold đặc biệt nằm bên ngoài nước Mỹ. Bởi vậy chúng tôi có thể phân phối cơ chế mã hoá SSL mạnh nhất ra toàn thế giới. Red Hat mua lại C2Net và giờ thì tôi ở đây”, Mark Cox tâm sự. Ngoài thời gian chính làm việc cho Red Hat, Cox còn tham gia đội bảo mật của Apache Software Foundation và nhóm OpenSSL những lúc rảnh rỗi.
Vậy, công việc của một thành viên đội phản ứng bảo mật là gì? Theo Cox, đội của anh chịu trách nhiệm đảm bảo cho các lỗ hổng bảo mật phải được xử lý. “Đó là quá trình bao gồm rất nhiều công đoạn, từ làm việc với các nhà nghiên cứu đến giám sát để tìm ra vấn đề tác động, thông qua chọn lựa xử lý và thanh tra để giám sát quá trình phát hành”.
Ngoài ra, mỗi thành viên của đội còn phải tư vấn, trả lời câu hỏi của khách hàng về lỗ hổng. “Trong năm ngoái, chúng tôi đã đáp ứng được 98% nhu cầu hỏi đáp mỗi ngày của khách hàng”, theo Mark.
Một thắc mắc thường đến với những người quan tâm là có bao nhiêu người làm việc trong lĩnh vực bảo mật ở các hãng lớn như Red Hat? Con số chính xác không được tiết lộ nhưng vị đội trưởng này bật mí là số lượng kỹ sư được phân bổ tuỳ thuộc vào từng lỗ hổng.
“Số lượng kỹ sư hoạt động full-time phân bổ trên khắp thế giới cho phép chúng tôi kiểm soát tốt dịch vụ bao quát trên khắp các vùng, bất chấp sự sai khác về múi giờ, và chúng tôi luôn không ngừng tìm kiếm thêm các kỹ sư tài năng. Khi gặp sự cố, chuyên viên ở mỗi vùng sẽ nhanh chóng được cử đến để xử lý giải quyết vấn đề. Vì thế, số lượng nhân viên Red Hat làm việc trong lĩnh vực bảo mật thay đổi theo mỗi tuần”.
Thành viên của đội bảo mật thường truy cập và biết về thông tin lỗ hổng trước khi chúng được công bố ra ngoài. Nhưng đó mới chỉ là “một nửa”, tức là Red Hat có thời gian xử lý vấn đề nếu một lỗ hổng phát sinh trước khi nó trở thành kiến thức chung cho mọi người. Nhưng điều đó không phải lúc nào cũng đúng. “Phát hiện được vấn đề nhanh chóng giúp chúng tôi có khả năng làm việc với đối tác để cung cấp bản vá kịp thời, tìm kiếm các vấn đề tương tự ở những vùng mã tương tự, thực hiện thêm các kiểm tra và phối hợp với các phân phối bị tác động khác”.
Ngay từ khi lỗ hổng chưa được công bố, đội bảo mật đã phải luôn tìm cách xử lý càng nhanh càng tốt. Hai năm trở lại đây, thời gian từ lúc bắt đầu phát hiện lỗ hổng đến khi đưa ra biện pháp xử lý ở Red Hat được quy định trong vòng 7 ngày. Đối với những vấn đề cực kỳ nghiêm trọng, thành viên của đội bảo mật phải làm việc liên tục để tìm ra giải pháp trong vòng 2 ngày.
“Cha ơi, lỗ hổng đến từ đâu?”
Đứa bé ngây thơ hỏi cha mình, một chuyên gia bảo mật. Và chúng ta cũng vậy, những người dùng nghiệp dư, chỉ như một đứa trẻ bi bô trước thế giới bảo mật bí hiểm. Chính xác, lỗ hổng bảo mật được khám phá như thế nào? Trên website của mình, Mark Cox phân tích nguồn thông tin bảo mật của Red Hat từ tháng 3 năm 2005 đến tháng 3 năm 2007. Điểm anh đặc biệt nhấn mạnh là liệu Red Hat có nhận được thông tin trước khi lỗ hổng trở nên phổ biến hay không.
Nguồn thông tin hàng đầu lại đến từ các hãng FLOSS khác, như nhiều báo cáo của hãng đối thủ FireFox. Trong nhiều trường hợp, Red Hat biết đến vấn đề từ phía các hãng FLOSS khác, hay từ những dự án phân tích ngược trước khi chúng trở nên phổ biến.
Nhưng ai là những người thường tìm ra lỗ hổng khi chúng bắt đầu xuất hiện và tìm ra như thế nào? Với Red Hat thì có một số cách, có thể là kiểm tra ngay khi mới phát hành sản phẩm và đôi khi lại là tìm ra từ kết quả của các bản báo cáo lỗi về vấn đề khác. “Các dự án phân tích ngược và các phân phối đôi khi thực hiện kiểm định hoặc chạy công cụ phân tích mã. Một số vấn đề bảo mật được phát hiện từ đó, và nhiều khi chính khách hàng là người ghi nhận và thông báo cho chúng tôi các lỗi bất cập để cuối cùng chúng tôi có kết quả bảo mật hoàn chỉnh”.
Hãy ngăn chặn vấn đề trước khi để nó xảy ra
Sửa chữa các vấn đề bảo mật sau khi đã diễn ra được ví như việc dập tắt ngọn lửa sau khi nó đã thiêu rụi căn nhà, chỉ là sự xác nhận tổn thất chứ không phải cách giải quyết vấn đề hiệu quả. Đó là lý do vì sao Red Hat và các hãng Linux khác sử dụng nhiều công nghệ “phòng hơn chống” nhằm giảm thiểu các vấn đề bảo mật. Ví dụ như SELinux và Exec-Shield, có thể bảo vệ hệ thống bằng cách ngăn chặn một số kiểu cụ thể.
Trong bài viết đưa lên hồi tháng 4, Cox mô tả một số thành phần bảo mật khác nhau trong phiên bản Red Hat Enterprise Linux (RHEL) 3 và 4 và các kiểu lỗ hổng chúng có thể xử lý.
Ví dụ như về “double-free”, là lỗ hổng trong đó hàm free() được gọi tới hai lần cho cùng một địa chỉ bộ nhớ, có thể dẫn đến lỗi tràn bộ đệm. Theo bài báo, lỗi này là nguyên nhân dẫn đến “những lỗ hổng cao hơn của các dịch vụ như wu-ftpd và CVS pserver” trong năm 2003, trước khi các đội bảo mật có thể xử lý được vấn đề.
Năm 2004, một lỗi double-free đã được tìm thấy và công bố ở Trung tâm Phân phối MIT Kerberos 5 Key Distribution Center. Tuy nhiên, RHEL 4 đã tích hợp được khả năng chống lại lỗ hổng nên “chúng tôi giảm được đáng kể tính nguy hiểm của vấn đề vì kỹ thuật glibc hardening đã hoàn toàn ngăn chặn được các hoạt động khai thác lỗ hổng double-free”.
Không phải tất cả các lỗ hổng đều giống nhau
Khi Red Hat thông báo về một lỗ hổng, bao giờ hãng cũng đính kèm mức độ nguy hiểm mà nó có thể gây ra. Chúng được đánh giá dựa trên nguyên tắc bốn điểm, từ những lỗ hổng nghiêm trọng cho phép một kẻ tấn công từ xa xâm nhập hệ thống mà không cần bất kỳ tương tác người dùng nào (mức nghiêm trọng) cho đến một số kiểu tác động bảo mật nguy hiểm nhưng rất khó thực thi hoạt động khai thác trên một hệ thống hay những lỗ hổng không để lại hậu quả nguy hiểm gì (mức thấp).
Red Hat không thay đổi kiểu phân loại bảo mật dựa trên khả năng kiểm soát nó. Mà thay vào đó: “Chúng tôi định nghĩa mức độ nguy hiểm đối với người dùng dựa trên khả năng của cả lỗ hổng và mức độ đe doạ. Tỷ lệ chúng tôi cung cấp cho các tư vấn viên chỉ hoàn toàn dựa trên lỗ hổng và được điều chỉnh để khớp với các hãng khác như Microsoft và Apache. Do mức độ đe doạ thay đổi theo thời gian và dựa chủ yếu trên cấu hình, sự sử dụng của người dùng cuối, chúng tôi không thông báo về nó nữa”.
Linux đang ngày càng có nhiều lỗ hổng hơn?
Vài năm trở lại đây, Linux ngày càng trở nên phổ biến. Và danh sách những lỗ hổng đặc biệt chỉ có ở Linux cũng dài thêm. Đội trưởng Mark cho hay Red Hat vừa mới ngừng quá trình tìm kiếm lỗi có thể khai thác ở RHEL 4 trong hai năm đầu phát hành nhưng mọi sự dường như không chỉ có vậy. “Có nhiều cách khai thác phổ biến cho 37 lỗ hổng được phát hiện. Nhiều trong số chúng được tìm thấy theo những sáng kiến bảo mật khác nhau, nhưng một số là do cấu hình không phù hợp và số khác thì hoạt động không như mong đợi. Với một lỗ hổng ở nhân kernel, người dùng cục bộ có thể giành được đặc quyền root trên một máy chưa được update bản vá kịp thời. Và một số lỗ hổng còn hoạt động chống lại các trình duyệt Web không được vá lỗi”.
“Ngoài các lỗi trình duyệt Web, thực ra ngày nay không có nhiều lỗ hổng từ xa cho kẻ tấn công có thể khai thác. Ví dụ như trường hợp cài đặt mặc định Enterprise Linux 4 AS chỉ gây ra ba vấn đề bảo mật nghiêm trọng trong hai năm đầu tiên phát hành”.
T.Thu (Theo Linux)
Các chuyên gia IT thường mất rất nhiều thời gian để suy nghĩ về bảo mật. Họ cố gắng tìm ra những cách nhanh nhất có thể để đảm bảo cho hệ thống của mình được vá và update kịp thời nhất. Tuy nhiên những gì diễn ra trước khi các quản trị viên này nghe nói đến lỗ hổng hầu như vẫn là bức màn bí ẩn. Để có được bức tranh rõ ràng hơn, chúng ta hãy lắng nghe ý kiến của Mark Cox, đội trưởng đội phản ứng bảo mật của Red Hat về xu hướng trong bảo mật Linux, những ai thường khám phá ra các lỗ hổng bảo mật, tốc độ phát triển của chúng và những biện pháp tối thiểu vấn đề gặp phải có thể thực hiện.
Trước tiên là đôi chút về Mark Cox, chuyên gia bảo mật hàng đầu của Red Hat. Thú vui bảo mật bắt đầu làm Cox hứng thú từ 12 năm trước đây, khi anh phát hiện ra một số vấn đề bảo mật ở Web Server HTTPd của National Center for Supercomputing Aplications (NCSA) - Trung tâm quốc gia về các ứng dụng siêu máy tính. “Nhanh chóng sau đó tôi thấy rằng tổ chức hoạt động C2Net châu Âu, nơi tôi phát triển sever Web Stronghold đặc biệt nằm bên ngoài nước Mỹ. Bởi vậy chúng tôi có thể phân phối cơ chế mã hoá SSL mạnh nhất ra toàn thế giới. Red Hat mua lại C2Net và giờ thì tôi ở đây”, Mark Cox tâm sự. Ngoài thời gian chính làm việc cho Red Hat, Cox còn tham gia đội bảo mật của Apache Software Foundation và nhóm OpenSSL những lúc rảnh rỗi.
Vậy, công việc của một thành viên đội phản ứng bảo mật là gì? Theo Cox, đội của anh chịu trách nhiệm đảm bảo cho các lỗ hổng bảo mật phải được xử lý. “Đó là quá trình bao gồm rất nhiều công đoạn, từ làm việc với các nhà nghiên cứu đến giám sát để tìm ra vấn đề tác động, thông qua chọn lựa xử lý và thanh tra để giám sát quá trình phát hành”.
Ngoài ra, mỗi thành viên của đội còn phải tư vấn, trả lời câu hỏi của khách hàng về lỗ hổng. “Trong năm ngoái, chúng tôi đã đáp ứng được 98% nhu cầu hỏi đáp mỗi ngày của khách hàng”, theo Mark.
Một thắc mắc thường đến với những người quan tâm là có bao nhiêu người làm việc trong lĩnh vực bảo mật ở các hãng lớn như Red Hat? Con số chính xác không được tiết lộ nhưng vị đội trưởng này bật mí là số lượng kỹ sư được phân bổ tuỳ thuộc vào từng lỗ hổng.
“Số lượng kỹ sư hoạt động full-time phân bổ trên khắp thế giới cho phép chúng tôi kiểm soát tốt dịch vụ bao quát trên khắp các vùng, bất chấp sự sai khác về múi giờ, và chúng tôi luôn không ngừng tìm kiếm thêm các kỹ sư tài năng. Khi gặp sự cố, chuyên viên ở mỗi vùng sẽ nhanh chóng được cử đến để xử lý giải quyết vấn đề. Vì thế, số lượng nhân viên Red Hat làm việc trong lĩnh vực bảo mật thay đổi theo mỗi tuần”.
Thành viên của đội bảo mật thường truy cập và biết về thông tin lỗ hổng trước khi chúng được công bố ra ngoài. Nhưng đó mới chỉ là “một nửa”, tức là Red Hat có thời gian xử lý vấn đề nếu một lỗ hổng phát sinh trước khi nó trở thành kiến thức chung cho mọi người. Nhưng điều đó không phải lúc nào cũng đúng. “Phát hiện được vấn đề nhanh chóng giúp chúng tôi có khả năng làm việc với đối tác để cung cấp bản vá kịp thời, tìm kiếm các vấn đề tương tự ở những vùng mã tương tự, thực hiện thêm các kiểm tra và phối hợp với các phân phối bị tác động khác”.
Ngay từ khi lỗ hổng chưa được công bố, đội bảo mật đã phải luôn tìm cách xử lý càng nhanh càng tốt. Hai năm trở lại đây, thời gian từ lúc bắt đầu phát hiện lỗ hổng đến khi đưa ra biện pháp xử lý ở Red Hat được quy định trong vòng 7 ngày. Đối với những vấn đề cực kỳ nghiêm trọng, thành viên của đội bảo mật phải làm việc liên tục để tìm ra giải pháp trong vòng 2 ngày.
“Cha ơi, lỗ hổng đến từ đâu?”
Đứa bé ngây thơ hỏi cha mình, một chuyên gia bảo mật. Và chúng ta cũng vậy, những người dùng nghiệp dư, chỉ như một đứa trẻ bi bô trước thế giới bảo mật bí hiểm. Chính xác, lỗ hổng bảo mật được khám phá như thế nào? Trên website của mình, Mark Cox phân tích nguồn thông tin bảo mật của Red Hat từ tháng 3 năm 2005 đến tháng 3 năm 2007. Điểm anh đặc biệt nhấn mạnh là liệu Red Hat có nhận được thông tin trước khi lỗ hổng trở nên phổ biến hay không.
Nguồn thông tin hàng đầu lại đến từ các hãng FLOSS khác, như nhiều báo cáo của hãng đối thủ FireFox. Trong nhiều trường hợp, Red Hat biết đến vấn đề từ phía các hãng FLOSS khác, hay từ những dự án phân tích ngược trước khi chúng trở nên phổ biến.
Nhưng ai là những người thường tìm ra lỗ hổng khi chúng bắt đầu xuất hiện và tìm ra như thế nào? Với Red Hat thì có một số cách, có thể là kiểm tra ngay khi mới phát hành sản phẩm và đôi khi lại là tìm ra từ kết quả của các bản báo cáo lỗi về vấn đề khác. “Các dự án phân tích ngược và các phân phối đôi khi thực hiện kiểm định hoặc chạy công cụ phân tích mã. Một số vấn đề bảo mật được phát hiện từ đó, và nhiều khi chính khách hàng là người ghi nhận và thông báo cho chúng tôi các lỗi bất cập để cuối cùng chúng tôi có kết quả bảo mật hoàn chỉnh”.
Hãy ngăn chặn vấn đề trước khi để nó xảy ra
Sửa chữa các vấn đề bảo mật sau khi đã diễn ra được ví như việc dập tắt ngọn lửa sau khi nó đã thiêu rụi căn nhà, chỉ là sự xác nhận tổn thất chứ không phải cách giải quyết vấn đề hiệu quả. Đó là lý do vì sao Red Hat và các hãng Linux khác sử dụng nhiều công nghệ “phòng hơn chống” nhằm giảm thiểu các vấn đề bảo mật. Ví dụ như SELinux và Exec-Shield, có thể bảo vệ hệ thống bằng cách ngăn chặn một số kiểu cụ thể.
Trong bài viết đưa lên hồi tháng 4, Cox mô tả một số thành phần bảo mật khác nhau trong phiên bản Red Hat Enterprise Linux (RHEL) 3 và 4 và các kiểu lỗ hổng chúng có thể xử lý.
Ví dụ như về “double-free”, là lỗ hổng trong đó hàm free() được gọi tới hai lần cho cùng một địa chỉ bộ nhớ, có thể dẫn đến lỗi tràn bộ đệm. Theo bài báo, lỗi này là nguyên nhân dẫn đến “những lỗ hổng cao hơn của các dịch vụ như wu-ftpd và CVS pserver” trong năm 2003, trước khi các đội bảo mật có thể xử lý được vấn đề.
Năm 2004, một lỗi double-free đã được tìm thấy và công bố ở Trung tâm Phân phối MIT Kerberos 5 Key Distribution Center. Tuy nhiên, RHEL 4 đã tích hợp được khả năng chống lại lỗ hổng nên “chúng tôi giảm được đáng kể tính nguy hiểm của vấn đề vì kỹ thuật glibc hardening đã hoàn toàn ngăn chặn được các hoạt động khai thác lỗ hổng double-free”.
Không phải tất cả các lỗ hổng đều giống nhau
Khi Red Hat thông báo về một lỗ hổng, bao giờ hãng cũng đính kèm mức độ nguy hiểm mà nó có thể gây ra. Chúng được đánh giá dựa trên nguyên tắc bốn điểm, từ những lỗ hổng nghiêm trọng cho phép một kẻ tấn công từ xa xâm nhập hệ thống mà không cần bất kỳ tương tác người dùng nào (mức nghiêm trọng) cho đến một số kiểu tác động bảo mật nguy hiểm nhưng rất khó thực thi hoạt động khai thác trên một hệ thống hay những lỗ hổng không để lại hậu quả nguy hiểm gì (mức thấp).
Red Hat không thay đổi kiểu phân loại bảo mật dựa trên khả năng kiểm soát nó. Mà thay vào đó: “Chúng tôi định nghĩa mức độ nguy hiểm đối với người dùng dựa trên khả năng của cả lỗ hổng và mức độ đe doạ. Tỷ lệ chúng tôi cung cấp cho các tư vấn viên chỉ hoàn toàn dựa trên lỗ hổng và được điều chỉnh để khớp với các hãng khác như Microsoft và Apache. Do mức độ đe doạ thay đổi theo thời gian và dựa chủ yếu trên cấu hình, sự sử dụng của người dùng cuối, chúng tôi không thông báo về nó nữa”.
Linux đang ngày càng có nhiều lỗ hổng hơn?
Vài năm trở lại đây, Linux ngày càng trở nên phổ biến. Và danh sách những lỗ hổng đặc biệt chỉ có ở Linux cũng dài thêm. Đội trưởng Mark cho hay Red Hat vừa mới ngừng quá trình tìm kiếm lỗi có thể khai thác ở RHEL 4 trong hai năm đầu phát hành nhưng mọi sự dường như không chỉ có vậy. “Có nhiều cách khai thác phổ biến cho 37 lỗ hổng được phát hiện. Nhiều trong số chúng được tìm thấy theo những sáng kiến bảo mật khác nhau, nhưng một số là do cấu hình không phù hợp và số khác thì hoạt động không như mong đợi. Với một lỗ hổng ở nhân kernel, người dùng cục bộ có thể giành được đặc quyền root trên một máy chưa được update bản vá kịp thời. Và một số lỗ hổng còn hoạt động chống lại các trình duyệt Web không được vá lỗi”.
“Ngoài các lỗi trình duyệt Web, thực ra ngày nay không có nhiều lỗ hổng từ xa cho kẻ tấn công có thể khai thác. Ví dụ như trường hợp cài đặt mặc định Enterprise Linux 4 AS chỉ gây ra ba vấn đề bảo mật nghiêm trọng trong hai năm đầu tiên phát hành”.
T.Thu (Theo Linux)
WIDGETIZE