Logo Zephyrnet

S3 Ep145: Những Lỗi Có Tên Ấn Tượng!

Ngày:

MỘT TUẦN, HAI LẦN

Apple các bản vá lỗi hai zero-day, một cho lần thứ hai. Làm thế nào một hệ thống mật mã 30 tuổi có được nứt. Tất cả bí mật của bạn đều thuộc về chảy máu não. Ghi nhớ những quảng cáo PC/Mac tinh ranh.

Không có trình phát âm thanh bên dưới? Nghe trực tiếp trên Soundcloud.

Với Doug Aamoth và Paul Ducklin. Nhạc giới thiệu và kết thúc bởi Edith Mudge.

Bạn có thể lắng nghe chúng tôi trên Soundcloud, Podcast của Apple, Google Podcasts, Spotify và bất cứ nơi nào tìm thấy podcast tốt. Hoặc chỉ cần thả URL của nguồn cấp dữ liệu RSS của chúng tôi vào podcatcher yêu thích của bạn.


ĐỌC BẢNG BIỂU

DOUGLAS.  Các bản vá lỗi của Apple, bảo mật so với hiệu suất và hack đài cảnh sát.

Tất cả những điều đó và hơn thế nữa, trên podcast Naked Security.

[CHẾ ĐỘ ÂM NHẠC]

Chào mừng mọi người đến với podcast.

Tôi là Doug Aamoth; anh ấy là Paul Ducklin.

Paul, có chuyện gì vậy, anh bạn?


VỊT.  Đó là tháng Bảy, Douglas!


DOUGLAS.  Vâng, chúng ta hãy nói về tháng bảy trong của chúng tôi Tuần này trong Lịch sử Công nghệ phân khúc.

Ngày 28 tháng 1993 năm 1.0 mang đến cho chúng tôi phiên bản XNUMX của Ngôn ngữ lập trình Lua.

Và ngay cả khi bạn chưa bao giờ nghe nói về Ngôn ngữ nhỏ có thể, thì có lẽ bạn đã được hưởng lợi từ nó.

Lua được sử dụng trong các ứng dụng như Roblox, World of Warcraft, Angry Birds, các ứng dụng web từ Venmo và Adobe, chưa kể đến Wireshark, Nmap, Neovim và hàng trăm ứng dụng script phổ biến khác.

Paul, bạn sử dụng Lua trong một số bài viết về Naked Security, nếu tôi không nhầm.


VỊT.  Tôi là một người hâm mộ Lua lớn, Douglas.

Tôi sử dụng nó khá rộng rãi cho kịch bản của riêng mình.

Đó là thứ mà tôi muốn gọi là “cỗ máy chiến đấu hèn hạ”.

Nó có một số đặc điểm đáng yêu: đó là một ngôn ngữ rất dễ học; đó là ngôn ngữ rất dễ đọc; và thậm chí bạn có thể viết chương trình theo phong cách chức năng.

(Nói về mặt kỹ thuật, các hàm là đối tượng hạng nhất trong ngôn ngữ, vì vậy bạn có thể thực hiện tất cả các loại nội dung gọn gàng mà bạn không thể thực hiện với các ngôn ngữ truyền thống hơn như C.)

Và tôi thường sử dụng nó cho những gì lẽ ra sẽ là mã giả trong các bài viết về Bảo mật trần trụi.

Bởi vì (A) bạn có thể sao chép và dán mã và tự mình dùng thử nếu muốn, và (B) nó thực sự dễ đọc một cách đáng ngạc nhiên, ngay cả đối với những người không quen lập trình.

Lua đến từ Rio de Janeiro ở Brazil.
Từ Lua có nghĩa là 'mặt trăng' trong tiếng Bồ Đào Nha.

DOUGLAS.  Đáng yêu!

Được rồi, hãy tiếp tục về chủ đề mã.

Chúng tôi đã nói nhiều lần về bản vá Phản hồi nhanh thứ hai của Apple.

Nó ở đó, nó không ở đó, chuyện gì đã xảy ra với nó?

Chà, bản vá đó hiện là một phần của cập nhật đầy đủ, và một trong số đó thực sự đã vá lỗi zero-day thứ hai, Paul.

Apple gửi bản vá phần mềm gián điệp “Phản hồi nhanh” gần đây cho mọi người, khắc phục lỗi zero-day thứ hai


VỊT.  Vâng.

Nếu bạn nhớ điều đó Hồi đáp nhanh, như bạn đã nói ...

…đã có một bản cập nhật với phiên bản (a), đó là cách chúng biểu thị cái đầu tiên, thì đã xảy ra sự cố với điều đó (duyệt đến một số trang web không phân tích cú pháp đúng chuỗi Tác nhân người dùng).

Và thế là Apple nói, “Ồ, đừng lo, chúng tôi sẽ đưa ra phiên bản (b) một lát nữa."

Và điều tiếp theo chúng tôi thấy là phiên bản (c).

Bạn nói đúng, ý tưởng của những Phản hồi nhanh này là cuối cùng chúng sẽ đưa nó vào bản nâng cấp đầy đủ, nơi bạn nhận được số phiên bản mới đầy đủ.

Vì vậy, ngay cả khi bạn sợ Phản hồi nhanh, bạn sẽ nhận được các bản sửa lỗi đó sau, nếu không muốn nói là sớm hơn.

Và lỗi zero-day trong WebKit (đó là thứ được vá theo Phản hồi nhanh) hiện đã được đi kèm với bản sửa lỗi zero-day cho lỗ hổng cấp nhân.

Và có một số (làm thế nào tôi có thể nói nó?) “sự trùng hợp thú vị” khi bạn so sánh nó với lần nâng cấp bảo mật lớn cuối cùng của Apple vào tháng 2023 năm XNUMX.

Cụ thể là lỗi zero-day đã được sửa trong phần Phản hồi nhanh nằm trong WebKit và được quy cho “một nhà nghiên cứu ẩn danh”.

Và lỗi zero-day hiện được vá trong kernel được cho là do công ty chống vi-rút Kaspersky của Nga, người đã báo cáo một cách nổi tiếng rằng họ đã tìm thấy một loạt lỗi zero-day trên iPhone của các giám đốc điều hành của chính họ, có lẽ được sử dụng để cấy ghép phần mềm gián điệp.

Vì vậy, tiền thông minh đang nói, mặc dù Apple đã không đề cập rõ ràng điều này trong bản tin bảo mật của họ, rằng đây là một bản sửa lỗi khác liên quan đến cái gọi là Trojan tam giác.

Nói cách khác, phần mềm gián điệp in-the-wild đã được sử dụng trong ít nhất một số cuộc tấn công có chủ đích.

Điều đó làm cho Phản hồi nhanh trở nên dễ hiểu hơn (về lý do tại sao Apple muốn đưa nó ra nhanh chóng), bởi vì điều đó ngăn trình duyệt được sử dụng để đánh lừa điện thoại của bạn ngay từ đầu.

Và nó làm cho bản nâng cấp này trở nên cực kỳ quan trọng, bởi vì nó có nghĩa là nó đóng lại lỗ hổng đằng sau lỗ hổng mà chúng tôi tưởng tượng rằng kẻ gian sẽ sử dụng sau khi xâm phạm trình duyệt của bạn.

Họ sẽ xâu chuỗi vào lỗ hổng thứ hai này, về cơ bản, đã cho họ toàn quyền kiểm soát.


DOUGLAS.  OK, vậy chúng ta đi từ hai tuần trước đến 30 năm trước…

…và đây là một câu chuyện thú vị.

Đó là một câu chuyện cảnh báo về việc không cố gắng che giấu các bí mật mật mã đằng sau các thỏa thuận không tiết lộ. [NDA]

Hoàn thành với một BWAIN mới, Paul.

Chúng tôi đã có một BWAIN mới!

Hack đài cảnh sát: Lỗ hổng tiền điện tử 30 năm tuổi được chú ý


VỊT.  “Lỗi Với Một Cái Tên Ấn Tượng.”

Nếu việc giữ bí mật thuật toán là cần thiết để nó hoạt động chính xác…

…chỉ cần một người nhận hối lộ, phạm sai lầm hoặc thiết kế ngược sản phẩm của bạn là toàn bộ sự việc sẽ sụp đổ.

Và đó là những gì hệ thống đài TETRA này đã làm.

Nó dựa trên các thuật toán mã hóa bí mật thương mại, độc quyền, phi tiêu chuẩn, với kết quả là chúng chưa bao giờ thực sự được xem xét kỹ lưỡng trong nhiều năm.

TETRA là Đài phát thanh Trunked Terrestrial.

Nó giống như điện thoại di động, nhưng có một số lợi thế đáng kể cho những người như cơ quan thực thi pháp luật và những người phản hồi đầu tiên, cụ thể là nó có phạm vi phủ sóng xa hơn, vì vậy bạn cần ít trạm gốc hơn.

Và nó được thiết kế ngay từ đầu với tính năng liên lạc một-một và một-nhiều, lý tưởng khi bạn đang cố gắng điều phối một nhóm người để ứng phó với trường hợp khẩn cấp.

Thật không may, hóa ra nó có một số điểm không hoàn hảo mà mãi đến năm 2021, một nhóm các nhà nghiên cứu người Hà Lan mới phát hiện ra nó.

Và họ đã kiên nhẫn chờ đợi gần hai năm để thực hiện tiết lộ có trách nhiệm của mình, để đưa ra thông tin chi tiết về các lỗi mà họ sẽ thực hiện tại một loạt hội nghị, bắt đầu từ Black Hat 2023.

Bạn có thể hiểu tại sao họ muốn gây chú ý lớn về nó ngay bây giờ, bởi vì họ đã nghiên cứu thông tin này, làm việc với các nhà cung cấp để sẵn sàng các bản vá, kể từ cuối năm 2021.

Trên thực tế, các CVE, số lỗi mà họ mắc phải, đều là CVE-2022-xxxx, chỉ số này cho biết có bao nhiêu quán tính trong hệ thống mà họ phải vượt qua để có được các bản vá cho những lỗ hổng này.


DOUGLAS.  Và BWAIN của chúng tôi là TETRA:BURST, thật thú vị.

Hãy nói về một số lỗ hổng này.


VỊT.  Tổng cộng có năm CVE, nhưng có hai vấn đề chính mà tôi cho là “những khoảnh khắc có thể dạy được”.

Cái đầu tiên, đó là CVE-2022-24401, giải quyết vấn đề nhức nhối về thỏa thuận chính.

Làm thế nào để trạm cơ sở của bạn và thiết bị cầm tay của ai đó thống nhất về khóa mà họ sẽ sử dụng cho cuộc trò chuyện cụ thể này, để nó khác biệt đáng tin cậy với bất kỳ khóa nào khác?

TETRA đã làm điều đó bằng cách dựa vào thời gian hiện tại, rõ ràng là chỉ di chuyển theo hướng thuận. (Quá xa so với điều chúng ta biết.)

Vấn đề là không có giai đoạn xác thực hoặc xác thực dữ liệu.

Khi thiết bị cầm tay kết nối với trạm gốc và nhận được dấu thời gian, nó không có cách nào để kiểm tra, “Đây có phải là dấu thời gian thực từ trạm gốc mà tôi tin tưởng không?”

Không có chữ ký điện tử trên dấu thời gian, điều đó có nghĩa là bạn có thể thiết lập một trạm gốc giả mạo và bạn có thể lừa họ nói chuyện với bạn bằng cách sử dụng dấu thời gian *của bạn*.

Nói cách khác, khóa mã hóa cho cuộc trò chuyện từ người khác *mà bạn đã chặn và ghi lại ngày hôm qua*…

…hôm nay bạn có thể trò chuyện một cách hồn nhiên với ai đó, không phải vì bạn muốn trò chuyện mà vì bạn muốn khôi phục dòng khóa.

Sau đó, bạn có thể sử dụng luồng khóa đó, *vì nó giống với luồng đã được sử dụng ngày hôm qua*, cho cuộc hội thoại mà bạn đã chặn.

Và, tất nhiên, một điều khác mà bạn có thể làm là, nếu bạn nhận ra rằng mình muốn chặn thứ gì đó vào thứ Ba tới, bạn có thể lừa ai đó trò chuyện với bạn *hôm nay* bằng cách sử dụng dấu thời gian giả cho tuần tới.

Sau đó, khi bạn chặn cuộc trò chuyện đó trong tương lai, bạn có thể giải mã nó vì bạn đã nhận được luồng khóa từ cuộc trò chuyện hôm nay.


DOUGLAS.  OK, vậy đó là lỗi đầu tiên.

Và đạo đức của câu chuyện là: Đừng dựa vào dữ liệu mà bạn không thể xác minh.

Trong lỗi thứ hai, đạo đức của câu chuyện là: Đừng xây dựng các cửa hậu hoặc các điểm yếu có chủ ý khác.

Đó là một điều không nên, Paul!


VỊT.  Nó thực sự là.

Cái đó là CVE 2022-24402.

Bây giờ, tôi đã thấy trên các phương tiện truyền thông rằng có một số tranh luận về việc liệu điều này có thực sự được coi là một cửa hậu hay không, bởi vì nó được đưa vào có mục đích và tất cả những người đã ký NDA đều biết rằng nó ở trong đó (hoặc lẽ ra phải nhận ra).

Nhưng hãy gọi nó là cửa hậu, bởi vì nó là một cơ chế được lập trình có chủ ý, theo đó những người vận hành một số loại thiết bị (may mắn thay, không phải loại thường được bán cho cơ quan thực thi pháp luật hoặc cho những người phản ứng đầu tiên, mà là loại được bán cho các tổ chức thương mại)….

…có một chế độ đặc biệt, thay vì sử dụng các khóa mã hóa 80 bit, có một nút ma thuật mà bạn có thể nhấn với nội dung: “Này, các bạn, chỉ sử dụng 32 bit thay vì 80.”

Và khi bạn nghĩ rằng chúng tôi đã loại bỏ DES, tiêu chuẩn mã hóa dữ liệu, vào khoảng đầu thiên niên kỷ vì nó chỉ có khóa 56 bit, bạn có thể tưởng tượng, *hôm nay vào năm 2023*, khóa mã hóa 32 bit thực sự yếu đến mức nào.

Chi phí thời gian và vật liệu để thực hiện một cuộc tấn công vũ phu có lẽ là không đáng kể.

Bạn có thể tưởng tượng, với một vài chiếc máy tính xách tay còn khá, bạn có thể làm điều đó trong một buổi chiều cho bất kỳ cuộc trò chuyện nào mà bạn muốn giải mã.


DOUGLAS.  Được rồi, rất tốt.

Cuối cùng, nhưng không kém phần quan trọng, chúng ta có…

…nếu bạn còn nhớ Heartbleed vào năm 2014, đừng hoảng sợ, nhưng có một thứ mới được gọi là chảy máu não

Zenbleed: Việc tìm kiếm hiệu suất CPU có thể khiến mật khẩu của bạn gặp rủi ro như thế nào


VỊT.  Vâng, đó là BWAIN Số Hai trong tuần. [CƯỜI]


DOUGLAS.  Vâng, đó là một BWAIN khác! [CƯỜI]


VỊT.  Tôi có ý định viết cái này vì nó có một cái tên dễ thương, Zenbleed (cái tên “Zen” xuất phát từ thực tế là lỗi này áp dụng cho dòng bộ xử lý Zen 2 của AMD, theo như tôi biết), và bởi vì cái này đã được tìm thấy bởi thợ săn lỗi huyền thoại từ Google Project Zero, Tavis Ormandy, người đang hướng sự chú ý của mình vào những gì xảy ra bên trong bộ vi xử lý.

Các cuộc tấn công “Bleed”… Tôi sẽ chỉ mô tả chúng bằng những từ mà tôi đã viết trong bài báo:


Hậu tố “-bleed” được sử dụng cho các lỗ hổng làm rò rỉ dữ liệu theo cách ngẫu nhiên mà cả kẻ tấn công và nạn nhân đều không thực sự kiểm soát được.


Vì vậy, một cuộc tấn công chảy máu là một cuộc tấn công mà bạn không thể chọc kim đan vào máy tính trên Internet và nói: “Aha! Bây giờ tôi muốn bạn tìm cơ sở dữ liệu cụ thể được gọi là sales.sql và tải nó lên cho tôi.”

Và bạn không thể cắm kim đan vào một lỗ khác và nói: “Tôi muốn bạn xem bù bộ nhớ 12 cho đến khi số thẻ tín dụng xuất hiện, sau đó lưu nó vào đĩa để dùng sau.”

Bạn chỉ nhận được dữ liệu giả ngẫu nhiên rò rỉ ra khỏi chương trình của người khác.

Bạn nhận được những thứ tùy ý mà bạn không được phép xem, mà bạn có thể thu thập theo ý muốn trong vài phút, vài giờ, vài ngày, thậm chí vài tuần nếu bạn muốn.

Sau đó, bạn có thể thực hiện công việc dữ liệu lớn của mình trên những thứ bị đánh cắp đó và xem bạn thu được gì từ nó.

Vì vậy, đó là những gì Tavis Ormandy tìm thấy ở đây.

Về cơ bản, đó là một vấn đề với xử lý véc tơ, đó là nơi bộ xử lý Intel và AMD không hoạt động ở chế độ 64 bit thông thường của chúng (nơi chúng có thể cộng hai số nguyên 64 bit cùng một lúc), nhưng chúng có thể hoạt động ở chế độ 256 -bit khối dữ liệu tại một thời điểm.

Và điều đó hữu ích cho những thứ như bẻ khóa mật khẩu, khai thác tiền điện tử, xử lý hình ảnh, tất cả những thứ khác.

Đó là một tập lệnh hoàn toàn riêng biệt bên trong bộ xử lý; toàn bộ bộ đăng ký nội bộ riêng biệt; một tập hợp toàn bộ các phép tính lạ mắt và thực sự mạnh mẽ mà bạn có thể thực hiện trên những con số siêu lớn này để có kết quả hiệu suất siêu lớn.

Cơ hội mà chúng không có lỗi là gì?

Và đó là điều mà Tavis Ormandy đã tìm kiếm.

Anh ấy phát hiện ra rằng một hướng dẫn rất đặc biệt được sử dụng rộng rãi để tránh làm giảm hiệu suất…

…bạn có hướng dẫn kỳ diệu này được gọi là VZEROUPPER điều đó nói với CPU, “Bởi vì tôi đang sử dụng những thanh ghi 256-bit ưa thích này nhưng tôi không còn quan tâm đến chúng nữa, bạn không phải lo lắng về việc lưu trạng thái của chúng cho lần sau.”

Đoán xem nào?

Lệnh kỳ diệu này, đặt 128 bit trên cùng của tất cả các thanh ghi vectơ 256 bit thành XNUMX cùng một lúc, tất cả chỉ bằng một lệnh (bạn có thể thấy có rất nhiều điều phức tạp ở đây)…

…về cơ bản, đôi khi nó làm rò rỉ dữ liệu từ một số quy trình hoặc luồng khác đã chạy gần đây.

Nếu bạn lạm dụng hướng dẫn này đúng cách và Tavis Ormandy đã tìm ra cách thực hiện điều này, bạn sẽ thực hiện các hướng dẫn véc-tơ ma thuật của riêng mình và bạn sử dụng siêu tuyệt vời này VZEROUPPER hướng dẫn theo một cách đặc biệt và điều xảy ra là các thanh ghi vectơ trong chương trình của bạn thỉnh thoảng bắt đầu hiển thị với các giá trị dữ liệu mà chúng không được phép có.

Và những giá trị dữ liệu đó không phải là ngẫu nhiên.

Chúng thực sự là những khối dữ liệu 16 byte (128 bit) *đến từ quy trình của người khác*.

Bạn không biết của ai.

Bạn chỉ cần biết rằng dữ liệu giả mạo này thỉnh thoảng xuất hiện một cách ma quái.

Thật không may, Taviso đã phát hiện ra rằng bằng cách sử dụng sai hướng dẫn này theo cách đúng/sai, anh ấy thực sự có thể trích xuất 30KB dữ liệu ma quái giả mạo từ các quy trình của người khác mỗi giây trên mỗi lõi CPU.

Và mặc dù điều đó nghe có vẻ như tốc độ dữ liệu rất chậm (ngày nay ai lại muốn 30KB mỗi giây trên kết nối internet chứ? – không ai cả)…

…khi nói đến việc lấy các khối dữ liệu 16 byte ngẫu nhiên từ các chương trình của người khác, nó thực sự hoạt động ở mức khoảng 3GB mỗi ngày cho mỗi lõi.

Sẽ có một số trang web của người khác; sẽ có tên người dùng; có thể có cơ sở dữ liệu mật khẩu; có thể có mã thông báo xác thực.

Tất cả những gì bạn phải làm là đi qua nguồn cung cấp cỏ khô phong phú này và tìm bất kỳ cây kim nào trông thú vị.

Và phần thực sự tồi tệ của điều này là *không chỉ các quy trình khác chạy ở cùng cấp độ đặc quyền với bạn*.

Vì vậy, nếu bạn đăng nhập với tên “Doug”, lỗi này không chỉ theo dõi các tiến trình khác đang chạy dưới tài khoản hệ điều hành “Doug”.

Như chính Taviso đã chỉ ra:


Các thao tác cơ bản như strlen, memcpystrcmp...


(Đó là các chức năng tiêu chuẩn mà tất cả các chương trình sử dụng để tìm độ dài của chuỗi văn bản, để sao chép bộ nhớ xung quanh và để so sánh hai mục văn bản.)


Các hoạt động cơ bản đó sẽ sử dụng các thanh ghi véc tơ, vì vậy chúng ta có thể sử dụng kỹ thuật này một cách hiệu quả để theo dõi các hoạt động đó xảy ra ở bất kỳ đâu trên hệ thống!


Và anh ấy tự cho phép mình, một cách dễ hiểu, một dấu chấm than, ngay tại đó.


Sẽ không thành vấn đề nếu chúng đang xảy ra trong các máy ảo, hộp cát, thùng chứa, quy trình khác, bất cứ thứ gì.


Tôi nghĩ rằng anh ấy thực sự cũng đã sử dụng dấu chấm than thứ hai ở đó.

Nói cách khác, *mọi quy trình*, cho dù đó là hệ điều hành, cho dù đó là người dùng khác trong cùng VM với bạn, cho dù đó là chương trình điều khiển VM, cho dù đó là hộp cát được cho là xử lý mật khẩu siêu riêng tư.

Bạn chỉ nhận được nguồn cấp dữ liệu ổn định gồm các khối dữ liệu 16 byte này đến từ những người khác và tất cả những gì bạn phải làm là ngồi, xem và chờ đợi.


DOUGLAS.  Vì vậy, không cần đợi nhà cung cấp bo mạch chủ vá…

Nếu đang sử dụng máy Mac, bạn không cần phải lo lắng về điều này vì có máy Mac dựa trên ARM và máy Mac dựa trên Intel, nhưng không có máy Mac AMD, nhưng còn người dùng Windows với bộ xử lý AMD và có thể một số người dùng Linux nhất định thì sao?


VỊT.  Bản phân phối Linux của bạn có thể có bản cập nhật vi mã chương trình cơ sở mà bản cập nhật này sẽ tự động áp dụng cho bạn.

Và có một tính năng AMD về cơ bản không có giấy tờ (hoặc tốt nhất là tài liệu rất kém), một lệnh đặc biệt mà bạn có thể cung cấp cho chip thông qua cái được gọi là MSR, hoặc thanh ghi dành riêng cho mô hình.

Chúng giống như các công cụ thiết lập cấu hình cho từng vòng chip cụ thể.

Có một cài đặt mà bạn có thể thực hiện để miễn dịch cho chip của bạn chống lại lỗi này, vì vậy bạn có thể áp dụng cài đặt đó.

Có các lệnh để thực hiện việc này cho Linux và BSD, nhưng thật không may, tôi không biết các lệnh tương tự trên Windows.

Việc xáo trộn các thanh ghi CPU dành riêng cho kiểu máy [MSR] có thể được thực hiện trên Windows, nhưng nói chung, bạn cần có trình điều khiển nhân.

Và điều đó thường có nghĩa là lấy nó từ một số bên thứ ba không xác định, tự biên dịch nó, cài đặt nó, tắt đăng nhập trình điều khiển…

…vì vậy chỉ làm điều đó nếu bạn thực sự cần và bạn hoàn toàn biết mình đang làm gì.

Nếu bạn thực sự khao khát Windows và bạn có bộ xử lý AMD Zen 2, tôi nghĩ… (Tôi chưa thử vì tôi không có sẵn máy tính phù hợp cho các thử nghiệm của mình.)


DOUGLAS.  Bạn nên chi tiêu một. [CƯỜI]

Cái này liên quan đến công việc!


VỊT.  Bạn có thể, nếu bạn tải xuống và cài đặt Windbg [phát âm là “windbag”], Trình gỡ lỗi Microsoft…

…cho phép bạn kích hoạt tính năng gỡ lỗi hạt nhân cục bộ, kết nối với hạt nhân của riêng bạn và thao tác với các thanh ghi dành riêng cho kiểu máy [DRAMATIC VOICE] *trong tình trạng nguy hiểm của riêng bạn*.

Và, tất nhiên, nếu bạn đang sử dụng OpenBSD, từ những gì tôi nghe được, Theo [de Raadt] già tốt bụng đã nói, “Bạn biết không, có một sự giảm nhẹ; nó đang bật bit đặc biệt này để ngăn lỗi hoạt động. Chúng tôi sẽ đặt mặc định đó trong OpenBSD, vì sở thích của chúng tôi là cố gắng ưu tiên bảo mật ngay cả khi phải trả giá bằng hiệu suất.”

Nhưng đối với những người khác, bạn sẽ phải đợi cho đến khi nó được sửa xong hoặc tự mình thực hiện một chút hack vi mô!


DOUGLAS.  Được rồi, rất tốt.

Chúng tôi sẽ để mắt đến điều này, đánh dấu lời nói của tôi.

Và khi mặt trời bắt đầu lặn trong chương trình của chúng ta hôm nay, hãy lắng nghe ý kiến ​​từ một trong những độc giả của chúng ta trên Facebook.

Điều này liên quan đến câu chuyện Apple đã nói ở đầu chương trình.

Anthony viết:


Tôi còn nhớ, trước đây, khi người dùng Apple thường ca ngợi đám đông PC về cách kiến ​​trúc của Apple kín nước và không cần vá lỗi bảo mật.


Paul, điều đó đặt ra một câu hỏi thú vị, bởi vì tôi nghĩ rằng chúng tôi xem xét lại điều này ít nhất hàng năm.

Chúng tôi nói gì với những người nói rằng Apple an toàn đến mức họ không cần bất kỳ phần mềm bảo mật nào hoặc họ không cần lo lắng về việc hack, phần mềm độc hại hoặc bất kỳ thứ gì tương tự?


VỊT.  Chà, thông thường chúng ta nở một nụ cười thân thiện thật tươi và nói: “Này, có ai nhớ những quảng cáo đó không? Tôi là PC/Tôi là máy Mac. Tôi là PC/Tôi là máy Mac. Làm thế nào điều đó diễn ra? [CƯỜI]


DOUGLAS.  Nói hay lắm!

Và cảm ơn bạn rất nhiều, Anthony, vì đã viết điều đó.

Nếu bạn có một câu chuyện, nhận xét hoặc câu hỏi thú vị mà bạn muốn gửi, chúng tôi rất muốn đọc nó trên podcast.

Bạn có thể gửi email tới tips@sophos.com, nhận xét về bất kỳ bài viết nào của chúng tôi hoặc bạn có thể liên hệ với chúng tôi trên mạng xã hội: @nakedSecurity.

Đó là chương trình của chúng tôi cho ngày hôm nay; cảm ơn rất nhiều vì đã lắng nghe

Đối với Paul Ducklin, tôi là Doug Aamoth, sẽ nhắc bạn, cho đến lần sau, hãy…


CẢ HAI.  Giữ an toàn!

[CHẾ ĐỘ ÂM NHẠC]


tại chỗ_img

Tin tức mới nhất

tại chỗ_img