Nhận thưởng $10.000 nhờ phát hiện lỗ hổng làm lộ email người dùng YouTube

 (brutecat.com)
1 điểm bởi GN⁺ 2025-02-13 | 1 bình luận | Chia sẻ qua WhatsApp
  • obfuscated Gaia ID là định danh tài khoản Google nội bộ của kênh YouTube đã bị lộ, và có thể được liên kết với địa chỉ email thông qua API chia sẻ của Pixel Recorder, tạo ra vấn đề về quyền riêng tư của tài khoản Google
  • Yêu cầu Innertube từ menu chặn trong live chat trả về tham số moderateLiveChatEndpoint chứa Gaia ID của kênh mục tiêu, ngay cả khi chưa thực hiện chặn thật sự
  • Khi thay channel ID trong tham số yêu cầu, phạm vi mục tiêu mở rộng tới cả Topic Channel không có tin nhắn live chat, cho thấy đây không phải vấn đề chỉ giới hạn ở một số người tham gia cụ thể
  • WriteShareList của Pixel Recorder nhận obfuscated Gaia ID của đối tượng được chia sẻ và trả về địa chỉ email trong phản hồi; đồng thời còn có thể ngăn email thông báo được gửi bằng tiêu đề bản ghi dài 2,5 triệu ký tự
  • Sau khi nhận báo cáo ngày 2024-09-15, Google xác nhận đã vá cả hai lỗ hổng vào ngày 2025-02-09 và trả tổng cộng $10.633 tiền thưởng

Gaia ID bị lộ từ tính năng chặn của YouTube

  • Tài liệu discovery của môi trường staging cho Google Internal People API cho thấy đối tượng BlockedTarget sử dụng obfuscated Gaia ID và fallbackName
    • profileId là obfuscated Gaia ID của người dùng bị chặn
    • fallbackName là tên hiển thị của người dùng bị chặn
  • Phần trợ giúp tài khoản Google có hướng dẫn rằng có thể chặn tài khoản trên YouTube, và khi thực sự chặn một người dùng trong live stream YouTube thì người đó sẽ xuất hiện tại myaccount.google.com/blocklist
  • Trong danh sách chặn, tên kênh Mega Prime xuất hiện dưới dạng fallbackName, còn 107183641464576740691 được hiển thị là profile ID
  • Dựa trên giả định rằng kênh YouTube không được làm lộ tài khoản Google nền tảng phía sau, tác giả bắt đầu tìm thêm đường khai thác vì trước đây từng có lỗi chuyển Gaia ID thành địa chỉ email

Mở rộng từ menu live chat ra toàn bộ kênh

  • Chỉ cần mở menu ba chấm trong live chat YouTube là yêu cầu /youtubei/v1/live_chat/get_item_context_menu sẽ được gửi đi
  • Phản hồi chứa moderateLiveChatEndpoint và giá trị params dẫn tới /youtubei/v1/live_chat/moderate
  • params này là protobuf mã hóa base64 thường được Google sử dụng; khi giải mã thì bên trong có Gaia ID của người dùng bị chặn
    • Phản hồi mẫu chứa 113907466537670370590 cùng các định danh liên quan tới kênh
    • Có thể lấy Gaia ID của mục tiêu mà không cần thực hiện thao tác chặn thật sự
  • Khi giải mã tham số yêu cầu của get_item_context_menu, có thể thấy channel ID của kênh bị chặn, video ID của livestream và ID tác giả livestream
  • Kết quả thử thay channel ID trong tham số yêu cầu bằng giá trị khác cho thấy có thể lấy được cả Gaia ID 103261974221829892167 của Topic Channel do YouTube tự động tạo
    • Topic Channel được YouTube tự động tạo, và thử nghiệm này dựa trên giả định rằng nó không có tin nhắn live chat

Pixel Recorder trở thành đường chuyển đổi sang email

  • Trong lúc tìm lỗi hoặc sai sót logic trên các sản phẩm Google cũ có thể đổi Gaia ID thành email, tác giả đã cùng nathan xem xét Pixel Recorder
  • Sau khi tạo một bản ghi thử nghiệm trên điện thoại Pixel và đồng bộ nó với tài khoản Google, tác giả sử dụng endpoint recorder.google.com trên web
  • Khi chia sẻ bản ghi với email thử nghiệm, yêu cầu WriteShareList chứa obfuscated Gaia ID trong danh sách đối tượng được chia sẻ
  • Phản hồi từ pixelrecorder-pa.clients6.google.com PlaybackService/WriteShareList trả về địa chỉ email của đối tượng đó
    • Phản hồi thử nghiệm có chứa vrptest2@gmail.com
    • Khi đưa vào Gaia ID 107183641464576740691 lấy được từ thí nghiệm chặn trên YouTube, phản hồi cũng trả về redacted@gmail.com
  • Điều này tạo ra chuỗi tấn công trong đó Gaia ID lấy từ YouTube có thể được đưa vào API chia sẻ của Pixel Recorder để tìm ra địa chỉ email

Tiêu đề bản ghi 2,5 triệu ký tự dùng để chặn email thông báo

  • Nếu chia sẻ một bản ghi Pixel Recorder với nạn nhân, nạn nhân sẽ nhận được email thông báo, làm giảm mức độ ảnh hưởng của cuộc tấn công
  • Hộp thoại chia sẻ không có tùy chọn tắt thông báo, và ngay cả khi phân tích protobuf yêu cầu bằng req2proto cũng không thấy trường nào để vô hiệu hóa thông báo
  • Cấu trúc WriteShareListRequest có các trường sau
    • recording_id
    • delete_obfuscated_gaia_ids
    • update_shared_users
    • sharing_message
  • Kể cả khi thêm và xóa người dùng cùng lúc thì email vẫn tiếp tục được gửi
  • Từ việc tiêu đề email thông báo có chứa tiêu đề bản ghi, tác giả suy luận rằng nếu đặt tiêu đề bản ghi thật dài thì có thể khiến việc gửi email thất bại
  • Tác giả viết một script Python dùng endpoint UpdateRecordingTitle để đổi tiêu đề bản ghi thành 2,5 triệu ký tự và thử nghiệm; phía máy chủ không có giới hạn độ dài tiêu đề
  • Sau khi đặt tiêu đề dài 2,5 triệu ký tự rồi chia sẻ cho một người dùng thử nghiệm khác, email thông báo đã không được gửi đi

PoC cuối cùng và lịch xử lý

  • Chuỗi tấn công hoàn chỉnh gồm ba bước
    • Lấy obfuscated Gaia ID của kênh mục tiêu từ endpoint Innertube /get_item_context_menu của YouTube
    • Chia sẻ một bản ghi Pixel Recorder có tiêu đề cực dài với mục tiêu để chuyển Gaia ID thành địa chỉ email
    • Xóa người dùng đó khỏi danh sách được chia sẻ của bản ghi Pixel Recorder để dọn dẹp
  • Video PoC được cung cấp tại video YouTube

Tiền thưởng và dòng thời gian vá lỗi của Google

  • 2024-09-15: Gửi báo cáo cho nhà cung cấp
  • 2024-09-16: Nhà cung cấp triage báo cáo và phản hồi Nice catch!
  • 2024-10-03: Hội đồng đánh dấu đây là bản trùng với lỗi theo dõi đã có, và thực hiện bản vá chưa hoàn chỉnh cho việc lộ obfuscated Gaia ID trên YouTube ban đầu
  • 2024-10-03: Tác giả giải thích lại với nhà cung cấp rằng bản thân Pixel Recorder cũng là một lỗ hổng
    • obfuscated Gaia ID cũng có thể bị lộ từ Google Maps và người đánh giá trên Google Play
    • Đồng thời cung cấp cả cách vòng qua để tiếp tục làm lộ obfuscated Gaia ID của kênh YouTube
  • 2024-11-05: Hội đồng trả thưởng $3.133
    • Lý do là khả năng khai thác ở mức trung bình
    • Được phân loại là phương pháp luận liên quan đến lạm dụng có tác động cao
  • 2024-12-03: Đội sản phẩm gửi lại báo cáo cho hội đồng để xem xét thưởng thêm, đồng thời điều phối lịch công khai vào 2025-02-03
  • 2024-12-12: Hội đồng trả thêm $7.500
    • Lý do là khả năng khai thác cao
    • Được phân loại là phương pháp luận liên quan đến lạm dụng có tác động cao
    • Do độ phức tạp của chuỗi tấn công nên bị hạ 1 bậc so với mức cơ bản
  • 2025-01-29: Nhà cung cấp đề nghị lùi lịch công khai tới 2025-02-02
  • 2025-02-09: Xác nhận cả hai phần của chuỗi tấn công đều đã được vá
    • Thời điểm này là 147 ngày sau báo cáo đầu tiên
  • 2025-02-12: Báo cáo được công khai

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-02-13
Ý kiến trên Hacker News

  • Tiêu đề gây nhầm lẫn. Nói cho những ai chưa đọc đến cuối bài: không phải email bị rò rỉ khiến họ tốn chi phí, mà là họ đã bỏ thời gian và sự nhanh trí, rồi nhận được bug bounty 10.000 USD

    • Ban đầu tôi tưởng là họ cung cấp một dịch vụ làm rò rỉ email người dùng với giá 10.000 USD mỗi người dùng
    • Tôi cũng tưởng ý là cung cấp như một dịch vụ giá 10.000 USD
    • Cũng có thể là tiêu đề nhằm câu click
    • Ban đầu tôi tưởng sẽ là chuyện kiểu chi phí tính toán để brute-force một hàm băm nào đó

  • Có rất nhiều tiếng ồn quanh việc công bố có trách nhiệm, động cơ và phần thưởng, nhưng hiếm thấy ai nói rằng đây là thêm một bằng chứng chống lại danh tính vĩnh viễn tập trung
    Mỗi khi một dịch vụ tuyên bố rằng nó hoạt động tốt nhất khi chỉ gắn với một Real Identity™ duy nhất, tôi lại có cảm giác các nhà cung cấp chỉ quan tâm đến việc thực sự bảo vệ người dùng ở mức trừu tượng, mà ngay cả thế cũng chỉ thỉnh thoảng
    Hãy tưởng tượng bất kỳ ai bạn tương tác trên YouTube đều có thể ngay lập tức tiến gần hơn ba bốn bước đến việc doxxing bạn; tôi cho rằng tác động thực tế của lỗi này là như vậy. May là nó đã được sửa, nhưng tôi không nghĩ loại lỗi này sẽ sớm biến mất. Cần điều gì để các nhà cung cấp và các tập đoàn lớn nhận ra rằng kiểu thiết kế này là một bãi mìn chỉ chực nổ?

    • Về mặt trừu tượng thì tôi đồng ý. Những tài khoản như vậy nên được phép có một mức độ ẩn danh và khả năng vứt bỏ nhất định. Dù sao thì chúng cũng chỉ là một hàng trong cơ sở dữ liệu ở đâu đó
      Tuy nhiên, nhiều người giao dịch với các công ty này bằng tiền thật. Ví dụ như người đăng ký YouTube Premium hoặc nhà sáng tạo nội dung. Trên thực tế, ở đâu đó trong tài khoản có thể vứt bỏ ấy vẫn phải lưu một định danh ngoài đời thực. Vì rủi ro gian lận và thực tế của nghiệp vụ ngân hàng, bạn sẽ giao danh tính và địa chỉ thật của mình cho công ty, và công ty cũng sẽ lưu chúng
      Tôi không đưa thông tin có thể nhận dạng mình cho các ứng dụng hay website ngẫu nhiên, nhưng bên mà tôi giao dịch thì tất yếu biết con người thật của tôi, và về lý thuyết đó trở thành một điểm mà dữ liệu có thể bị rò rỉ
    • Vì không có hậu quả pháp lý nên họ không bận tâm
      Thử để một nhà cung cấp dịch vụ y tế làm rò rỉ dữ liệu y tế xem, họ sẽ bị đánh sập hoàn toàn

  • “Đây là POC khai thác đang hoạt động: video này đã bị xóa vì vi phạm Điều khoản Dịch vụ của YouTube” nghe buồn cười thật

    • Tác giả bài gốc đã công khai địa chỉ email của một người dùng có thật để chứng minh khái niệm. Trong video đăng lại, địa chỉ email đã được làm mờ
    • Ban đầu tôi cũng thấy như vậy, nhưng khi mở lại bài thì có vẻ video đã hiện. Không biết có phải vừa được khôi phục không

  • Cứ mỗi bình luận thứ ba trong luồng này lại nói rằng Google trả quá ít cho lỗi này, nên nếu nói vài điều cơ bản về định giá lỗ hổng thì như sau:
    Lỗ hổng phía máy chủ có giá trị thấp vì các bên mua không cạnh tranh với nhau. Thực tế không có thị trường xám cho lỗ hổng phía máy chủ. Rất khó để bên thứ ba định giá một lỗi mà Google có thể tiêu diệt ngay lập tức, gần như không có chu kỳ bán rã kể từ lúc bị phát hiện, và nếu bị khai thác thì sẽ tạo ra telemetry đáng tin cậy ở phía mục tiêu.
    Ngược lại, những lỗi như full chain Android/Chrome được bán với giá hàng trăm nghìn đô la vì Google phải cạnh tranh với một thị trường xám đã hình thành tốt. Một bên mua có thể lấy lỗi đó và bán cho nhiều cơ quan ở một nước châu Âu, có thể tới 6 nơi.
    Dù vậy, so sánh bounty với thị trường xám là so sánh táo với cam. Google không cần một exploit có độ tin cậy cao, chỉ cần bằng chứng rằng có thể viết được exploit, và cũng không cần chi phí bảo trì, nên họ trả thấp hơn thị trường xám rất nhiều. Tổng giá trị của phần thị trường còn lại được chia qua nhiều tầng và đi kèm các điều kiện rủi ro, nhưng Google có thể đưa ra một khoản trả một lần hấp dẫn dù đã bị chiết khấu.
    Kẻ tấn công mua các lỗ hổng phù hợp với quy trình kinh doanh hiện có. Nói chung họ không suy đoán tưởng tượng những điều hay ho có thể làm với một lỗ hổng mới nào đó và cách kiếm tiền từ nó. Thu thập thông tin thanh toán, chiếm hàng nghìn máy cho botnet là các quy trình kinh doanh sẵn có. Việc lộ tên thật của tài khoản Google có thể trở thành một hoạt động kinh doanh không? Có thể. Hiện đã có chưa? Có lẽ là chưa.
    Mức bounty thường không phải là một cuộc trưng cầu xem lỗi thông minh hay thú vị đến đâu. Tuy nhiên ở đây thì cũng hơi có phần như vậy, vì 10.000 đô la cho một lỗi web phía máy chủ có vẻ cao bất thường.
    Với người kiếm sống bằng việc tìm các lỗi như thế này, chiến lược kinh doanh là trở nên giỏi trong việc tìm được nhiều lỗi. Nó khác với phát triển exploit iOS, nơi người ta đổ vài tháng vào một exploit có độ tin cậy cao duy nhất.
    Nghiên cứu lỗ hổng tôi làm trong sự nghiệp gần đây khá gần với hướng này hơn nhiều công việc khác, nên tôi khá tự tin. Dù vậy trên HN có những người làm full-time mảng bounty này, nên tôi sẽ rất vui nếu họ chỉnh lại cho đúng.

    • Hầu hết các lĩnh vực khác không được trả công dựa trên giá trị chợ đen của thứ họ tạo ra.
      Nếu áp dụng phân tích này sang thứ khác, giá trần của đầu phát âm thanh xe hơi hoặc xe đạp mới sẽ khoảng 100 đô la, và giá của mọi hàng hóa có bản quyền sẽ bị giới hạn bởi chi phí truyền qua mạng.
      Tôi nghĩ sẽ hữu ích hơn nếu lấy số tiền Google trả chia cho thời gian bỏ ra cho việc này và toàn bộ thời gian cho các nỗ lực exploit thất bại kể từ bounty trước đó.
      Phần lớn người trong lĩnh vực này có lẽ kiếm được ít hơn mức lương tối thiểu của Mỹ so với công sức bỏ ra, và đang chịu chi phí cơ hội sáu chữ số mỗi năm.
      Con số đó cho thấy chính xác Google coi trọng bảo mật và quyền riêng tư của người dùng cuối đến mức nào. Nó thấp hơn nhiều bậc độ lớn so với số tiền họ trả cho các kỹ sư khác để đánh cắp dữ liệu cá nhân của chính những người đó.
    • Tôi không thích việc luồng HN này phần lớn nói về số tiền bounty, nhưng điều đó cũng tự nhiên. Hầu hết những người bình luận ở đây làm trong ngành phần mềm và muốn bình thường hóa các khoản bounty rất cao.
      Vì đó là một nguồn thu nhập bổ sung đối với họ. Cũng như kỹ sư phần mềm muốn nghề của mình được trả lương cao, họ cũng muốn bug bounty tăng lên. Người lao động muốn đòi lương cao hơn cho nghề của mình là điều tự nhiên, và bất kỳ sự hợp lý hóa nào cũng không thay đổi được bản năng đó.
    • Dù nói “kẻ tấn công mua các lỗ hổng phù hợp với quy trình kinh doanh hiện có”, chẳng phải những thứ như thế này cũng có thị trường sao? Ví dụ kiểu “hãy tìm ra người đứng sau tài khoản đang chỉ trích công ty/chính phủ mờ ám của chúng ta để vô hiệu hóa họ”.
      Ngoài giá trị thị trường đối với kẻ tấn công còn có những động cơ khác. Một kẻ bạo lực đang rình rập một người nổi tiếng trên mạng có thể không phải là khách hàng sinh lợi trong thị trường exploit zero-day, nhưng nếu một công ty do bất cẩn có thể làm lộ danh tính mục tiêu cho một stalker bạo lực, thì lỗ hổng đó vẫn là rủi ro trách nhiệm pháp lý và đạo đức.
      Cá nhân tôi cho rằng nếu đang trả những khoản tiền khổng lồ cho các nghệ sĩ trình diễn LeetCode để họ sản xuất ra lượng code khổng lồ với sự chú ý không hoàn hảo đến bảo mật, thì cũng nên trả tốt cho những người giúp tìm và sửa vô số sai sót của họ trước khi chuyện xấu xảy ra.
    • Việc cơ quan thực thi pháp luật khai thác lỗi phía máy chủ là vùng xám hơn nhiều, hoặc thực sự có thể là bất hợp pháp. Trong khi đó, các cơ quan thực thi pháp luật hoặc tình báo đã có quy trình tiêu chuẩn để xin lệnh tòa nhằm khai thác thiết bị của mục tiêu cụ thể, tức điện thoại hoặc laptop.

  • “Do độ phức tạp của chuỗi tấn công cần thiết, áp dụng hạ một bậc so với mức cơ bản” — chuyện này có phổ biến không?
    Tôi mới chỉ tham gia vài chương trình lỗ hổng, nhưng phần lớn lại trả ít hơn cho những lỗi đơn giản đến vô lý nhưng nghiêm trọng, như email người dùng lộ trong source của trang.

    • Ngược lại, tôi hiểu là nó bị trừ điểm vì tương đối phức tạp đối với một lỗ hổng web.
    • Điều này có vẻ ngược. Thực tế là đã tìm ra 2 lỗi, nên phải tăng so với mức cơ bản mới đúng.

  • “Cách đây không lâu, khi đang tìm mục tiêu nghiên cứu ở Google, tôi đào sâu vào tài liệu discovery của Internal People API (Staging)” — cái này cứ công khai như vậy có ổn không: https://staging-people-pa.sandbox.googleapis.com/$discovery/...

    • Nó chỉ là file schema được tự động chuyển đổi từ định nghĩa .proto nội bộ. Google không dựa vào bảo mật bằng sự mơ hồ, mà dựa vào mật mã học thực sự.
      Hơn nữa, endpoint discovery được tài liệu hóa công khai[0] và được tạo ra cho người dùng bên ngoài. Người nội bộ sẽ không đọc endpoint discovery mà xem trực tiếp file .proto bằng tìm kiếm mã nguồn.
      Theo kinh nghiệm làm việc ở Google, để đưa một API ra công khai phải vật lộn với bộ máy quan liêu trong nhiều tuần. Đây không phải kiểu bucket AWS S3 tình cờ bị công khai. Nhóm đó biết nó là công khai, và hẳn đã vượt qua bộ máy quan liêu để công khai nó.
      [0]: https://developers.google.com/discovery/v1/getting_started

  • Nhìn vào timeline của bài viết thì tác giả đã báo cáo cho bên công ty vào 2024-09-15, đến 2025-01-29 công ty yêu cầu gia hạn công khai đến 2025-02-12, ngày 2025-02-09 xác nhận cả hai phía của exploit đều đã được sửa, và công khai vào 2025-02-12
    Vậy chẳng phải trong 136 ngày nó chưa được sửa và Google đã yêu cầu gia hạn sao. Mất 147 ngày để sửa, 150 ngày để công khai
    So với thời hạn công khai trước khi sửa mà Google Project Zero áp cho các công ty khác, họ nói: “Lỗi này áp dụng thời hạn công khai 90 ngày. Nếu bản sửa được cung cấp cho người dùng trước thời hạn 90 ngày, báo cáo lỗi này sẽ được công khai 30 ngày sau khi bản sửa được cung cấp. Nếu không, nó sẽ được công khai khi hết hạn”
    “Nếu dự kiến bản vá sẽ ra trong vòng 14 ngày sau khi hết hạn, Project Zero có thể cung cấp gia hạn… tuy nhiên, thời gian ân hạn 14 ngày chồng lên khoảng thời gian 30 ngày để áp dụng bản vá, nên các lỗ hổng được sửa trong thời gian ân hạn cũng sẽ được công khai muộn nhất vào ngày thứ 120 tính từ thời hạn 90 ngày ban đầu”
    “Nếu xác định rằng bản sửa sẽ không sẵn sàng trong vòng 14 ngày, chúng tôi dùng thời hạn 90 ngày ban đầu làm thời điểm công khai. Nói cách khác, chỉ khi nhà phát triển cam kết triển khai bản sửa trong thời gian ân hạn 14 ngày thì mới được cấp gia hạn 14 ngày”
    https://googleprojectzero.blogspot.com/p/vulnerability-discl...

    • Tôi không nghĩ phép so sánh này hữu ích. Đây là lỗi Google trong phần mềm của Google, còn thứ Project Zero tìm thường là lỗi trong phần mềm được nhiều người dùng, nên tôi hiểu là mức độ khẩn cấp để sửa cao hơn

  • “Cái params đó chỉ là protobuf được mã hóa base64, một định dạng mã hóa thường dùng rộng rãi trong Google” cơ à; phải rót một ly cho lập trình viên Google phụ trách việc mã hóa base64 một định dạng thông điệp nhị phân xịn sò rồi nhét vào một cục JSON mới được
    Nếu muốn thấy tương lai, hãy tưởng tượng một chiếc ủng có khắc chữ “worse is better” ở đế, giẫm lên mặt kỹ sư mãi mãi

    • Cái này ở đâu cũng có và tệ nhất. Đôi khi tôi tự hỏi liệu lượng byte protobuf được biểu diễn bằng base64 bên trong JSON có còn nhiều hơn số byte protobuf thật sự chạy trên đường truyền Internet không, rồi tự rót cho mình một ly
    • Nội bộ chắc là protobuf base64 nằm trong một trường protobuf
      Phần JSON là chuyển đổi tự động
    • Chuỗi JSON chứa protocol buffer mã hóa base64 à; không biết công ty nào làm, nhưng cũng biết là công ty nào rồi

  • Việc làm hỏng hệ thống email khiến mail không gửi được chính là nét chấm phá hoàn hảo. Ở một tập đoàn khổng lồ tạo ra vô số sản phẩm như Google, bảo mật có cảm giác như đồ giả
    Nếu từng dòng code đều là lỗ hổng tiềm tàng, thì với hàng triệu dòng, nó đơn giản là điều tất yếu. Có vẻ chẳng có cách nào ngoài việc giữ mọi thứ đơn giản, ví dụ như khai tử trang recorder, nhưng ngay cả vậy cũng không dễ

    • Đây có thể là một lý do khác khiến Google khai tử nhiều sản phẩm đã thành công, nhưng không đủ thành công để tiếp tục duy trì và giữ an toàn trong toàn bộ hệ thống của Google
    • Đáng tiếc là với số lượng người dùng của Google, bất kỳ lần khai tử nào cũng sẽ kéo theo tiếng kêu đau đớn và phản ứng kiểu “tôi đang phụ thuộc vào phím cách để sưởi ấm máy tính”. Cứ xem https://killedbygoogle.com/ là biết
    • Tôi muốn nghe ví dụ về trường hợp bảo mật có cảm giác “thật”, và nó giúp ích như thế nào
      Phần lớn sản phẩm phần mềm phụ thuộc vào một software stack rất phức tạp, và nếu bạn tin tưởng 100% mọi thư viện cùng hệ điều hành mình dùng thì theo tôi đó là tư duy sai. Ngay cả bộ xử lý cũng từng có lỗi như Meltdown. Bảo mật là cuộc chiến liên tục, bạn không bao giờ biết mình đã thắng hay chưa, chỉ thỉnh thoảng mới biết khi mình đã thua
    • Về bản chất, bạn đang đề xuất một thứ giống phương trình Drake[1] để tính số lỗ hổng bảo mật dựa trên số dòng code. Còn những yếu tố nào sẽ đi vào phương trình này nữa?
      [1] https://en.wikipedia.org/wiki/Drake_equation
    • Ý chính là bảo mật là đồ giả. Không ứng dụng nào thật sự an toàn. Dù chi hàng triệu đô la cho bảo mật ứng dụng, chỉ một sai sót của một người dùng là cũng có thể bị xuyên thủng

  • Tôi cũng đã hiểu nhầm tiêu đề theo nghĩa kiểu chi phí tính toán GPU 10 nghìn đô la. Nhìn việc chọn một sản phẩm Google cũ rồi tìm ra lỗ hổng ngay, có vẻ còn hàng chục hoặc hàng trăm lỗi như thế nữa

    • Nó không hoạt động theo kiểu “chọn một sản phẩm Google cũ rồi tìm ra lỗ hổng ngay” đâu. Có lẽ tác giả đã đào bới nhiều sản phẩm trong vài tuần hoặc vài tháng trước khi tìm được thứ có giá trị
    • Tôi cũng đã hiểu nhầm là muốn bán địa chỉ email YouTuber với giá 10 nghìn đô la