Ken Thompson Hack (1984)

Ken Thompson đã phác thảo một phương pháp để làm hỏng tệp nhị phân của trình biên dịch (và phần mềm được biên dịch khác, như tập lệnh đăng nhập trên hệ thống * nix) vào năm 1984. Tôi tò mò muốn biết liệu trình biên dịch hiện đại có giải quyết được lỗi bảo mật này hay không.

Mô tả ngắn:

Viết lại mã trình biên dịch để chứa 2 lỗi:

• Khi biên dịch nhị phân của chính nó, trình biên dịch phải biên dịch các lỗi này
• Khi biên dịch một số mã được chọn trước khác (chức năng đăng nhập), nó phải biên dịch một số backlink tùy ý

Do đó, trình biên dịch hoạt động bình thường - khi nó biên dịch tập lệnh đăng nhập hoặc tương tự, nó có thể tạo ra một cửa hậu bảo mật và khi nó biên dịch các phiên bản mới hơn của chính nó trong tương lai, nó vẫn giữ các lỗi trước đó - và các lỗ hổng sẽ chỉ tồn tại trong trình biên dịch nhị phân vì vậy cực kỳ khó phát hiện.

Câu hỏi:

Tôi không thể tìm thấy bất kỳ câu trả lời cho những điều này trên web:

• Làm thế nào điều này liên quan đến biên dịch chỉ trong thời gian?
• Các chức năng như đăng nhập xử lý chương trình trên hệ thống * nix có được biên dịch khi chúng chạy không?
• Đây có phải vẫn là một mối đe dọa hợp lệ, hoặc đã có những phát triển trong bảo mật biên dịch từ năm 1984 ngăn điều này trở thành một vấn đề quan trọng?
• Điều này có ảnh hưởng đến tất cả các ngôn ngữ?

Tại sao tôi muốn biết?

Tôi đã bắt gặp điều này trong khi làm một số bài tập về nhà, và nó có vẻ thú vị nhưng tôi thiếu nền tảng để hiểu một cách cụ thể cho dù đây là một vấn đề hiện tại, hoặc một vấn đề được giải quyết.

Tài liệu tham khảo

• Tổng quan
• Một số mã

Hack này phải được hiểu trong bối cảnh. Nó được xuất bản tại một thời điểm và trong một nền văn hóa nơi Unix chạy trên tất cả các loại phần cứng khác nhau là hệ thống thống trị.

Điều gì khiến cuộc tấn công rất đáng sợ là trình biên dịch C là các mảnh trung tâm của phần mềm cho các hệ thống này. Hầu hết mọi thứ trong hệ thống đều đi qua trình biên dịch khi nó được cài đặt lần đầu (phân phối nhị phân rất hiếm do phần cứng không đồng nhất). Mọi người biên soạn mọi thứ mọi lúc. Mọi người thường xuyên kiểm tra mã nguồn (họ thường phải điều chỉnh để biên dịch mã), do đó, trình biên dịch tiêm ngược lại dường như là một loại kịch bản "tội phạm hoàn hảo" mà bạn không thể bị bắt.

Ngày nay, phần cứng tương thích hơn nhiều và trình biên dịch do đó có vai trò nhỏ hơn nhiều trong hoạt động hàng ngày của một hệ thống. Trình biên dịch bị xâm nhập không còn là kịch bản đáng sợ nhất nữa - rootkit và BIOS bị xâm nhập thậm chí còn khó phát hiện và loại bỏ hơn.

Mục đích của bài phát biểu đó không phải là để làm nổi bật một lỗ hổng cần được giải quyết, hoặc thậm chí để đề xuất một lỗ hổng về lý thuyết mà chúng ta cần phải nhận thức được.

Mục đích là, khi nói đến bảo mật, chúng tôi muốn không phải tin bất cứ ai, nhưng thật không may, điều đó là không thể. Bạn luôn phải tin tưởng một ai đó (do đó, tiêu đề: "Refl Refl On Trusting Trust")

Ngay cả khi bạn thuộc loại hoang tưởng mã hóa ổ cứng máy tính để bàn của mình và từ chối chạy bất kỳ phần mềm nào bạn không tự biên dịch, bạn vẫn cần tin tưởng vào hệ điều hành của mình. Và ngay cả khi bạn tự biên dịch hệ điều hành, bạn vẫn cần tin tưởng vào trình biên dịch bạn đã sử dụng. Và ngay cả khi bạn biên dịch trình biên dịch của riêng mình, bạn vẫn cần tin tưởng vào trình biên dịch đó ! Và đó thậm chí không đề cập đến các nhà sản xuất phần cứng!

Bạn chỉ đơn giản là không thể thoát khỏi việc không tin ai . Đó là điểm anh ấy đang cố gắng vượt qua.

Không

Cuộc tấn công, như mô tả ban đầu, không bao giờ là một mối đe dọa. Mặc dù về mặt lý thuyết, một trình biên dịch có thể làm điều này, nhưng thực sự việc thực hiện cuộc tấn công sẽ yêu cầu lập trình trình biên dịch để

• Nhận biết khi mã nguồn đang được biên dịch là của trình biên dịch và
• Chỉ ra cách sửa đổi mã nguồn tùy ý để chèn hack vào nó.

Điều này đòi hỏi phải tìm ra cách trình biên dịch làm việc từ mã nguồn của nó, để nó có thể sửa đổi nó mà không bị hỏng.

Ví dụ, hãy tưởng tượng rằng định dạng liên kết lưu trữ độ dài dữ liệu hoặc phần bù của mã máy đã biên dịch ở đâu đó trong tệp thực thi. Trình biên dịch sẽ phải tự tìm ra cái nào trong số này cần được cập nhật, và ở đâu, khi chèn tải trọng khai thác. Các phiên bản tiếp theo của trình biên dịch (phiên bản vô hại) có thể tùy ý thay đổi định dạng này, vì vậy mã khai thác sẽ thực sự cần phải hiểu các khái niệm này.

Đây là chương trình tự định hướng cấp cao, một vấn đề AI khó khăn (tôi đã kiểm tra lần cuối, trạng thái của nghệ thuật đã tạo ra mã được xác định thực tế bởi các loại của nó). Hãy nhìn xem: rất ít người thậm chí có thể làm điều này; bạn sẽ phải học ngôn ngữ lập trình và hiểu cơ sở mã trước tiên.

Ngay cả khi vấn đề AI được giải quyết, mọi người sẽ chú ý nếu biên dịch trình biên dịch nhỏ của họ dẫn đến một hệ nhị phân với một thư viện AI khổng lồ được liên kết với nó.

Tấn công tương tự: tin tưởng bootstrapping

Tuy nhiên, một khái quát của cuộc tấn công là có liên quan. Vấn đề cơ bản là chuỗi tin cậy của bạn phải bắt đầu từ đâu đó và trong nhiều lĩnh vực, nguồn gốc của nó có thể lật đổ toàn bộ chuỗi theo cách khó phát hiện.

Một ví dụ có thể dễ dàng rút ra trong cuộc sống thực

Hệ điều hành của bạn, như Ubuntu Linux, đảm bảo tính bảo mật (tính toàn vẹn) của các bản cập nhật bằng cách kiểm tra các gói cập nhật được tải xuống so với khóa ký của kho lưu trữ (sử dụng mã hóa khóa công khai). Nhưng điều này chỉ đảm bảo tính xác thực của các bản cập nhật nếu bạn có thể chứng minh rằng khóa ký được sở hữu bởi một nguồn hợp pháp.

Bạn lấy chìa khóa ký ở đâu? Khi bạn lần đầu tiên tải xuống bản phân phối hệ điều hành.

Bạn phải tin tưởng rằng nguồn gốc của chuỗi tin cậy của bạn, khóa ký này, không phải là xấu.

Bất cứ ai có thể MITM kết nối Internet giữa bạn và máy chủ tải xuống Ubuntu, đây có thể là ISP của bạn, một chính phủ kiểm soát truy cập Internet (ví dụ: Trung Quốc) hoặc nhà cung cấp dịch vụ lưu trữ của Ubuntu, có thể đã chiếm quyền điều khiển quá trình này:

• Phát hiện bạn đang tải xuống hình ảnh đĩa CD Ubuntu. Điều này rất đơn giản: thấy rằng yêu cầu sẽ đến bất kỳ máy nhân bản nào (được liệt kê công khai) và yêu cầu tên tệp của hình ảnh ISO.
• Phục vụ yêu cầu từ máy chủ của họ, cung cấp cho bạn hình ảnh CD chứa khóa công khai và vị trí kho lưu trữ của kẻ tấn công thay vì Ubuntu.

Từ đó, bạn sẽ nhận được các bản cập nhật của mình một cách an toàn từ máy chủ của kẻ tấn công. Cập nhật chạy dưới quyền root, vì vậy kẻ tấn công có toàn quyền kiểm soát.

Bạn có thể ngăn chặn cuộc tấn công bằng cách đảm bảo bản gốc là xác thực. Nhưng điều này đòi hỏi bạn phải xác thực hình ảnh CD đã tải xuống bằng cách sử dụng hàm băm ( ít người thực sự làm điều này ) và bản thân hàm băm phải được tải xuống một cách an toàn, ví dụ như qua HTTPS. Và nếu kẻ tấn công của bạn có thể thêm chứng chỉ trên máy tính của bạn (phổ biến trong môi trường công ty) hoặc kiểm soát cơ quan chứng nhận (ví dụ: Trung Quốc), ngay cả HTTPS cũng không bảo vệ.

Đầu tiên, bài viết yêu thích của tôi về bản hack này được gọi là Strange Loops .

Việc hack đặc biệt này chắc chắn có thể (*) được thực hiện ngày hôm nay trong bất kỳ dự án hệ điều hành nguồn mở lớn nào, đặc biệt là Linux, * BSD và tương tự. Tôi hy vọng nó sẽ hoạt động gần như giống hệt nhau. Ví dụ: bạn tải xuống một bản sao FreeBSD có trình biên dịch khai thác để sửa đổi openssh. Từ đó trở đi, mỗi khi bạn nâng cấp openssh hoặc trình biên dịch theo nguồn, bạn sẽ tiếp tục vấn đề. Giả sử kẻ tấn công đã khai thác hệ thống được sử dụng để đóng gói FreeBSD ngay từ đầu (có thể, vì hình ảnh bị hỏng hoặc thực tế kẻ tấn công là trình đóng gói), sau đó mỗi khi hệ thống xây dựng lại các nhị phân FreeBSD, nó sẽ khắc phục sự cố. Có rất nhiều cách để cuộc tấn công này thất bại, nhưng về cơ bản chúng không khác gì cách tấn công của Ken có thể thất bại (**). Thế giới thực sự đã không thay đổi nhiều.

Tất nhiên, các cuộc tấn công tương tự có thể dễ dàng (hoặc dễ dàng hơn) được chủ sở hữu của chúng đưa vào các hệ thống như Java, SDK iOS, Windows hoặc bất kỳ hệ thống nào khác. Một số loại lỗi bảo mật thậm chí có thể được thiết kế trong phần cứng (đặc biệt là làm suy yếu việc tạo số ngẫu nhiên).

(*) Nhưng bởi "chắc chắn" tôi có nghĩa là "trong pricincipl." Bạn có nên mong đợi rằng loại lỗ này tồn tại trong bất kỳ hệ thống cụ thể nào không? Không. Tôi sẽ xem xét nó khá khó xảy ra vì nhiều lý do thực tế. Theo thời gian, khi mã thay đổi và thay đổi, khả năng loại hack này sẽ gây ra các lỗi lạ tăng lên. Và điều đó làm tăng khả năng nó sẽ được phát hiện. Backreen ít khéo léo sẽ đòi hỏi âm mưu để duy trì. Tất nhiên chúng ta biết rằng thực tế là các cửa hậu "chặn hợp pháp" đã được cài đặt trong các hệ thống viễn thông và mạng khác nhau, vì vậy trong nhiều trường hợp, loại hack công phu này là không cần thiết. Bản hack được cài đặt công khai.

Vì vậy, luôn luôn, phòng thủ theo chiều sâu.

(**) Giả sử cuộc tấn công của Ken thực sự tồn tại. Ông chỉ thảo luận về cách nó có thể được thực hiện. Anh ấy đã không nói rằng anh ấy thực sự đã làm điều đó theo như tôi biết.

Điều này có ảnh hưởng đến tất cả các ngôn ngữ?

Cuộc tấn công này chủ yếu ảnh hưởng đến các ngôn ngữ tự lưu trữ. Đó là ngôn ngữ mà trình biên dịch được viết bằng chính ngôn ngữ đó. C, Squeak Smalltalk và trình thông dịch PyPy Python sẽ bị ảnh hưởng bởi điều này. Perl, JavaScript và trình thông dịch CPython Python sẽ không.

Làm thế nào điều này liên quan đến biên dịch chỉ trong thời gian?

Không nhiều lắm. Đó là bản chất tự lưu trữ của trình biên dịch cho phép hack bị ẩn. Tôi không biết về bất kỳ trình biên dịch JIT tự lưu trữ nào. (Có lẽ LLVM?)

Các chức năng như đăng nhập xử lý chương trình trên hệ thống * nix có được biên dịch khi chúng chạy không?

Không thường xuyên. Nhưng câu hỏi không phải là khi nó được biên dịch, mà bởi trình biên dịch nào . Nếu chương trình đăng nhập được biên dịch bởi trình biên dịch bị nhiễm độc, nó sẽ bị vô hiệu. Nếu nó được biên dịch bởi một trình biên dịch sạch, nó sẽ sạch.

Đây có phải vẫn là một mối đe dọa hợp lệ, hoặc đã có những phát triển trong bảo mật biên dịch từ năm 1984 ngăn điều này trở thành một vấn đề quan trọng?

Đây vẫn là một mối đe dọa về mặt lý thuyết, nhưng không có khả năng lắm.

Một điều bạn có thể làm để giảm thiểu nó là sử dụng nhiều trình biên dịch. Ví dụ, Trình biên dịch LLVM do GCC biên dịch sẽ không đi qua cửa sau. Tương tự, một GCC do LLVM biên dịch sẽ không đi qua cửa sau. Vì vậy, nếu bạn lo lắng về kiểu tấn công này, thì bạn có thể biên dịch trình biên dịch của mình với một trình biên dịch khác. Điều đó có nghĩa là tin tặc độc ác (tại nhà cung cấp hệ điều hành của bạn?) Sẽ phải làm mờ cả hai trình biên dịch để nhận ra nhau; Một vấn đề khó khăn hơn nhiều.

Có một cơ hội lý thuyết cho điều này xảy ra. Tuy nhiên, có một cách để kiểm tra xem một trình biên dịch cụ thể (với mã nguồn có sẵn) đã bị xâm phạm hay chưa, thông qua quá trình biên dịch kép Đa dạng của David A. Wheeler .

Về cơ bản, sử dụng cả trình biên dịch bị nghi ngờ và một trình biên dịch được phát triển độc lập khác để biên dịch nguồn của trình biên dịch nghi ngờ. Điều này cho phép bạn SC _sc và SC _T . Bây giờ, biên dịch nguồn nghi ngờ bằng cách sử dụng cả hai nhị phân này. Nếu các nhị phân kết quả là giống hệt nhau (ngoại trừ nhiều thứ có thể khác nhau về mặt pháp lý, như dấu thời gian các loại), trình biên dịch nghi ngờ đã không thực sự lạm dụng lòng tin.

Là một cuộc tấn công cụ thể, nó là một mối đe dọa lớn hơn bao giờ hết, gần như không có mối đe dọa nào cả.

Làm thế nào điều này liên quan đến biên dịch chỉ trong thời gian?

Không chắc ý của bạn là gì Là một JITter miễn dịch với điều này? Không. Có dễ bị tổn thương hơn không? Không hẳn vậy. Là nhà phát triển, ứng dụng của BẠN dễ bị tổn thương hơn đơn giản vì bạn không thể xác thực rằng nó chưa được thực hiện. Lưu ý rằng ứng dụng chưa phát triển của bạn về cơ bản là miễn dịch với điều này và tất cả các biến thể thực tế, bạn chỉ phải lo lắng về trình biên dịch mới hơn mã của bạn.

Các chức năng như đăng nhập xử lý chương trình trên hệ thống * nix có được biên dịch khi chúng chạy không?

Điều đó không thực sự phù hợp.

Đây có phải vẫn là một mối đe dọa hợp lệ, hoặc đã có những phát triển trong bảo mật biên dịch từ năm 1984 ngăn điều này trở thành một vấn đề quan trọng?

Không có bảo mật thực sự của việc biên dịch, và không thể. Đó thực sự là điểm chính trong cuộc nói chuyện của anh ấy, rằng đến một lúc nào đó bạn phải tin tưởng một ai đó.

Điều này có ảnh hưởng đến tất cả các ngôn ngữ?

Đúng. Về cơ bản, vào lúc này hay lúc khác, các hướng dẫn của bạn phải được biến thành thứ gì đó mà máy tính loại bỏ và bản dịch đó có thể được thực hiện không chính xác.

David Wheeler có một bài viết hay: http://www.dwheeler.com/trusting-trust/

Tôi, tôi lo lắng hơn về các cuộc tấn công phần cứng. Tôi nghĩ rằng chúng ta cần một chuỗi công cụ thiết kế hoàn toàn VLSI với mã nguồn FLOSS, chúng ta có thể tự sửa đổi và biên dịch, cho phép chúng ta xây dựng một bộ vi xử lý không có công cụ chèn ngược. Các công cụ cũng sẽ cho chúng tôi hiểu mục đích của bất kỳ bóng bán dẫn nào trên chip. Sau đó, chúng tôi có thể mở một mẫu chip đã hoàn thành và kiểm tra chúng bằng kính hiển vi, đảm bảo rằng chúng có cùng một mạch mà các công cụ nói rằng chúng đáng lẽ phải có.

Các hệ thống trong đó người dùng cuối có quyền truy cập vào mã nguồn là những hệ thống mà bạn sẽ phải ẩn loại tấn công này. Đó sẽ là các hệ thống nguồn mở trong thế giới ngày nay. Vấn đề là mặc dù có sự phụ thuộc vào một trình biên dịch duy nhất cho tất cả các hệ thống Linux, cuộc tấn công sẽ phải vào các máy chủ xây dựng cho tất cả các bản phân phối Linux chính. Vì những người không tải xuống các nhị phân trình biên dịch trực tiếp cho mỗi bản phát hành trình biên dịch, nguồn cho cuộc tấn công sẽ phải có trên các máy chủ xây dựng của họ trong ít nhất một bản phát hành trước đó của trình biên dịch. Phiên bản đầu tiên của trình biên dịch mà họ đã tải xuống dưới dạng nhị phân sẽ phải bị xâm phạm.

Nếu một người có mã nguồn cho một hệ thống biên dịch / xây dựng mà đầu ra của họ không nên phụ thuộc vào bất cứ thứ gì ngoài nội dung của các tệp nguồn được cung cấp và nếu một người có một số trình biên dịch khác và biết rằng tất cả chúng không chứa cùng một trình biên dịch hack, thì người ta có thể đảm bảo rằng người ta có được một tệp thực thi mà không phụ thuộc vào mã nào khác ngoài mã nguồn.

Giả sử người ta có mã nguồn cho gói trình biên dịch / trình liên kết (giả sử Groucho Suite) được viết theo cách mà đầu ra của nó sẽ không phụ thuộc vào bất kỳ hành vi không xác định nào, cũng như bất kỳ nội dung nào ngoài nội dung của tệp nguồn đầu vào và một biên dịch / liên kết mã trên nhiều gói trình biên dịch / trình liên kết được sản xuất độc lập (giả sử Harpo Suite, bộ Chico và Zeppo Suite), mang lại một bộ ngoại lệ khác nhau cho mỗi nhóm (gọi chúng là G-Harpo, G-Chico và G-Zeppo). Sẽ không có gì ngạc nhiên khi các tệp thực thi này chứa các chuỗi hướng dẫn khác nhau, nhưng chúng phải giống nhau về mặt chức năng. Tuy nhiên, việc chứng minh rằng chúng giống nhau về mặt chức năng trong mọi trường hợp, tuy nhiên, có thể sẽ là một vấn đề khó giải quyết.

May mắn thay, bằng chứng đó sẽ không cần thiết nếu người ta chỉ sử dụng các tệp thực thi kết quả cho một mục đích duy nhất: biên dịch lại bộ Groucho. Nếu một trình biên dịch bộ Groucho sử dụng G-Harpo (mang lại GG-Harpo), G-Chico (GG-Chico) và G-Zeppo (GG-Zeppo), thì cả ba tệp kết quả là GG-Harpo, GG-Chico và GG-Zeppo, nên giống hệt nhau theo từng byte. Nếu các tệp khớp nhau, điều đó có nghĩa là bất kỳ "vi-rút trình biên dịch" nào tồn tại trong bất kỳ tệp nào cũng phải tồn tại giống hệt nhau trong tất cả các tệp đó (vì cả ba tệp đều giống nhau theo byte, không có cách nào khác nhau về hành vi của chúng đường).

Tùy thuộc vào độ tuổi và dòng dõi của các trình biên dịch khác, có thể đảm bảo rằng một loại virus như vậy không thể tồn tại một cách chính đáng trong chúng. Ví dụ: nếu người ta sử dụng máy Macintosh cổ để cung cấp trình biên dịch được viết từ đầu năm 2007 thông qua phiên bản MPW được viết vào những năm 1980, thì trình biên dịch năm 1980 sẽ không biết nên chèn virus vào trình biên dịch 2007 ở đâu. Có thể một trình biên dịch ngày nay có thể thực hiện phân tích mã đủ để tìm ra nó, nhưng mức độ tính toán cần thiết cho phân tích đó sẽ vượt xa mức tính toán cần thiết để biên dịch mã, và không thể không chú ý lắm trong một thị trường nơi tốc độ biên dịch là một điểm bán hàng chính.

Tôi sẽ khẳng định rằng nếu một người đang làm việc với các công cụ biên dịch trong đó các byte trong một tệp thực thi được tạo ra thì không nên phụ thuộc vào bất kỳ cách nào ngoài nội dung của các tệp nguồn được gửi, có thể đạt được khả năng miễn dịch hợp lý từ một Thompson virus kiểu. Thật không may, vì một số lý do, tính không xác định trong quá trình biên dịch dường như được coi là bình thường trong một số môi trường. Tôi nhận ra rằng trên một hệ thống nhiều CPU, trình biên dịch có thể chạy nhanh hơn nếu nó được phép có các khía cạnh nhất định của việc tạo mã khác nhau tùy thuộc vào việc hai luồng nào hoàn thành một phần công việc trước.

Mặt khác, tôi không chắc chắn tôi thấy bất kỳ lý do nào mà trình biên dịch / trình liên kết không nên cung cấp chế độ "đầu ra chính tắc" trong đó đầu ra chỉ phụ thuộc vào các tệp nguồn và "ngày biên dịch" có thể bị người dùng ghi đè . Ngay cả khi việc biên dịch mã trong chế độ như vậy mất gấp đôi thời gian biên dịch thông thường, tôi sẽ đề xuất rằng sẽ có giá trị đáng kể để có thể tạo lại bất kỳ "bản dựng phát hành" nào, byte cho byte, hoàn toàn từ các tài liệu nguồn, ngay cả khi điều đó có nghĩa là bản dựng phát hành sẽ mất nhiều thời gian hơn "bản dựng thông thường".