1 bình luận

 
GN⁺ 2024-07-22
Ý kiến trên Hacker News
  • Ý kiến thứ nhất

    • Sự cố BSOD là do sự kết hợp giữa dữ liệu nhị phân sai và một trình phân tích cú pháp được viết lỗi
    • Theo kinh nghiệm trong 10 năm qua, phần lớn CVE, sự cố sập, bug và vấn đề chậm đều phát sinh trong quá trình giải tuần tự dữ liệu nhị phân thành cấu trúc dữ liệu mà máy có thể đọc được
    • Điều này xảy ra ở nhiều lĩnh vực như thuật toán nén, trình đọc đường viền phông chữ, trình phân tích ảnh/video/âm thanh, trình phân tích dữ liệu trò chơi điện tử, trình phân tích XML/HTML, cũng như trình phân tích chứng chỉ/chữ ký/khóa của OpenSSL
    • Trình phân tích nội dung của chương trình EDR của CrowdStrike cũng không phải ngoại lệ
  • Ý kiến thứ hai

    • Giải pháp mã nguồn mở có thể mang tính đạo đức hơn so với phần mềm giám sát endpoint dựa trên rootkit
    • Công cụ mã nguồn mở hoạt động minh bạch và có thể bảo đảm không có backdoor hoặc lỗi nghiêm trọng
    • Chúng có thể được kiểm toán công khai, và có thể vận hành theo mô hình kinh doanh trong đó đội ngũ bảo mật cung cấp chữ ký malware
  • Ý kiến thứ ba

    • Microsoft có phần trách nhiệm trong sự cố gián đoạn của CrowdStrike
    • Microsoft đang nắm vị thế gần như độc quyền trong không gian điện toán máy trạm và có nghĩa vụ bảo đảm tính bảo mật/độ tin cậy/chức năng của sản phẩm
    • Do thiếu cạnh tranh nên đổi mới trên Windows đang bị chậm lại
    • Ví dụ, CrowdStrike chạy trong không gian người dùng trên MacOS và Linux, nhưng không phải như vậy trên Windows
    • Cần có đổi mới về sandbox ứng dụng
    • Microsoft đang nắm chìa khóa của hạ tầng điện toán toàn cầu nhưng gần như không bị giám sát
    • Tỷ trọng doanh thu từ Windows đã giảm, nhưng vì đây là sản phẩm vận hành hạ tầng quan trọng nên cần có trách nhiệm lớn hơn
    • Chính phủ nên thúc đẩy cạnh tranh trong thị trường desktop workspace hoặc điều tiết sản phẩm Windows của Microsoft
  • Ý kiến thứ tư

    • Không thể hiểu vì sao phạm vi ảnh hưởng lại lớn đến vậy
    • Với các dịch vụ quan trọng, cách làm phổ biến là triển khai chậm kèm giám sát tự động và khả năng rollback
    • Thông thường sẽ triển khai ở giai đoạn beta mà không có lưu lượng khách hàng, rồi nếu không có vấn đề thì mở rộng dần
    • Cách làm đó lẽ ra đã có thể chặn sự cố ngay lập tức
  • Ý kiến thứ năm

    • Dù không dùng CrowdStrike, có vẻ driver CS được cài trước và được thiết kế để không thể gỡ bỏ
    • Driver nạp các tệp dữ liệu không có chữ ký, và người dùng có thể xóa chúng tùy ý
    • Người dùng ác ý có thể tạo tệp dữ liệu độc hại để khiến driver hoạt động sai
    • Có nguy cơ giành được quyền kernel
  • Ý kiến thứ sáu

    • Thắc mắc vì sao không phát hiện được vấn đề trong đợt triển khai thử nghiệm
    • Thật khó tin là họ không kiểm thử trước khi phát hành
    • Mọi công ty đều nên có môi trường kiểm thử trước khi triển khai
    • Việc trong quá trình phát triển cài một gói bị lỗi hoặc gây vấn đề là chuyện thường gặp, nhưng không nên đưa thẳng nó vào môi trường production
  • Ý kiến thứ bảy

    • Thắc mắc liệu khách hàng của CrowdStrike có thể đưa ra ý kiến về các bản cập nhật hay không
    • Không rõ liệu tất cả khách hàng có trao cho CrowdStrike toàn quyền thực thi mã từ xa hay không
    • Mong rằng các cơ quan chứng thực và chuyên gia mật mã có thể chặn những bản cập nhật như vậy trên hệ thống
  • Ý kiến thứ tám

    • Thắc mắc liệu "channel file" có được CS driver ký và xác thực hay không
    • Nếu không, đây có thể là một lỗ hổng lớn của rootkit
    • Dữ liệu đầu vào chạy với đặc quyền cao ít nhất phải được kiểm tra tính toàn vẹn
    • Việc có thể đơn giản xóa channel file cho thấy không có cơ chế chống né tránh phát hiện