Làm thế nào an toàn để biên dịch một đoạn mã nguồn từ một người lạ ngẫu nhiên? [đóng cửa]

Giả sử tôi đang xem xét mã mà người xin việc gửi để chứng minh kỹ năng của họ. Rõ ràng tôi không muốn chạy các tệp thực thi mà họ gửi. Không rõ ràng, tôi không muốn chạy kết quả biên dịch mã của họ (ví dụ, Java cho phép ẩn mã có thể chạy được trong các bình luận ).

Điều gì về việc biên dịch mã của họ? Tôi muốn cảnh báo trình biên dịch nếu có nhưng nếu mã của chúng chứa một số chuỗi ký tự thông minh khai thác trình biên dịch và trình biên dịch của tôi làm tổn hại máy của tôi thì sao?

Khi tôi Google cho "lỗ hổng trình biên dịch", các lần truy cập tôi nhận được là tất cả về tối ưu hóa trình biên dịch và phát xạ mã và liệu mã được phát ra có an toàn như mã nguồn gốc dự định hay không.

Các trình biên dịch thường được xác nhận để đảm bảo chúng sẽ không thỏa hiệp với máy người dùng khi biên dịch một số đoạn mã thông minh? Làm thế nào an toàn để biên dịch một đoạn mã từ một người lạ?

Nó phụ thuộc.

Đoạn makefile này có thể xóa thư mục chính của bạn:

all:
    rm -rf ~

Vì vậy, nếu bạn cần sử dụng một công cụ (như cmake hoặc makefile system), thì nó không an toàn. Nó chỉ phụ thuộc vào mức độ độc hại của coder.

Mặt khác, trình biên dịch được lập trình bởi mọi người, do đó họ có lỗi. Vì vậy, có thể ai đó đã tìm ra cách để thực thi mã độc trong quá trình biên dịch.

Như đã đề xuất trong các bình luận, nếu bạn muốn chắc chắn rằng không có điều gì buồn cười đang được thực hiện cho máy của bạn, hãy sử dụng máy ảo.

Tôi khá chắc chắn ở đâu đó trong doanh nghiệp có một số kẻ thông minh đã tạo ra một bản hack như vậy cho một phiên bản ngôn ngữ và trình biên dịch cụ thể. Địa điểm yêu thích của tôi để tìm kiếm thứ gì đó như thế này có lẽ sẽ là cuộc thi C Obfuscated quốc tế - (không biết có thứ gì có thể so sánh với Java không). Tuy nhiên, trong thực tế, bạn cân nhắc rủi ro cao đến mức nào, cho rằng

• người nộp đơn tạo ấn tượng chính đáng với bạn, anh ta thực sự muốn công việc tại công ty của bạn (và không phải là một vụ kiện)

• anh chàng không biết bao nhiêu đánh giá được thực hiện tại của bạn

• Anh ấy / cô ấy không biết bạn đang sử dụng phiên bản trình biên dịch chính xác nào

• Anh ấy / cô ấy không biết bạn sử dụng môi trường ảo hay trình biên dịch trực tuyến, để đảm bảo an toàn

• bạn không chấp nhận các chương trình quá lớn để được đánh giá hiệu quả

• bạn không biên dịch bất cứ thứ gì có vẻ đáng ngờ với bạn

• Không có nhiều người trên thế giới thực sự biết cách hoàn thành một cách kỹ thuật một nhiệm vụ như vậy (và một mình bạn sẽ không cung cấp cho bạn một "giới thiệu nhanh" hoặc hướng dẫn về điều này, như bạn đã tự mình tìm ra).

Vì vậy, mặc dù về mặt biên dịch không "hoàn toàn an toàn" về mặt lý thuyết, IMHO trong thực tế, rủi ro là cực kỳ thấp khi "trình biên dịch của bạn bị xóa sổ".

Chúng ta phải phân biệt một số trường hợp:

1. Một lỗi trong trình biên dịch. Giống như mọi chương trình phức tạp, trình biên dịch có thể có lỗi và một trong những lỗi đó có thể bị khai thác.
2. Một con ngựa thành Troia. Kẻ tấn công có thể khiến bạn thực thi một số mã tùy ý như là một phần của quá trình biên dịch. A Makefile, a build.xml, một configuretập lệnh shell, v.v. Về mặt kỹ thuật, điều này không phải do biên dịch mã của kẻ tấn công mà là thiết lập môi trường biên dịch.
3. Ngôn ngữ cho phép mã tùy ý chạy trong thời gian biên dịch. Ngôn ngữ macro của Scala là Scala, Ngôn ngữ macro chung của Lisp là Lisp chung, Ngôn ngữ macro của Haskell là Haskell. Scala cũng có các plugin biên dịch, một lần nữa là mã Scala tùy ý chạy trong thời gian biên dịch. F # có nhà cung cấp loại.
4. Các ngôn ngữ cho phép tính toán Turing tại thời điểm biên dịch. Các hệ thống loại của Scala và Haskell là Turing-Complete, cũng như các Mẫu của C ++. Bạn có thể nhận được trình biên dịch để thực hiện tính toán Turing tùy ý tại thời gian biên dịch, bao gồm nhưng không giới hạn ở các vòng lặp vô hạn. Lưu ý rằng Turing-Complete chỉ có nghĩa là bạn có thể tính toán mọi chức năng tính toán Turing, điều đó không có nghĩa là bạn có thể truy cập hệ thống tập tin hoặc một cái gì đó tương tự. Nhưng, bạn có thể tạo một chương trình sẽ mất nhiều thời gian để biên dịch.
5. Thời gian biên dịch rất dài. Ví dụ: các quy tắc của C # đối với độ phân giải quá tải rất phức tạp đến mức bạn có thể mã hóa bất kỳ vấn đề 3-SAT nào dưới dạng độ phân giải quá tải C #. Tất nhiên, 3-SAT là NP-hoàn thành nổi tiếng. Nói cách khác, theo kiến ​​thức hiện tại của chúng tôi, không thể tìm thấy một thuật toán hiệu quả để giải quyết quá tải trong C #. Bạn không thể thực hiện quá trình biên dịch mất nhiều thời gian, nhưng nó không cần một chương trình lớn để khiến việc biên dịch mất nhiều thời gian hơn vòng đời của vũ trụ, thực tế là điều tương tự.

#4. và # 5. nhiều nhất sẽ dẫn đến việc từ chối dịch vụ. Thực tế, trình biên dịch C ++ và Scala giới hạn số lần đệ quy bạn có thể làm, do đó thực tế không thể viết một vòng lặp vô hạn. Trong Scala, đó chỉ là một hạn chế triển khai, nhưng trong C ++, tôi tin rằng nó được cho phép rõ ràng.

# 2. về mặt kỹ thuật nằm ngoài phạm vi của câu hỏi vì câu hỏi là về việc biên dịch mã không chạy nó (OTOH, có một câu hỏi triết học sâu sắc: nếu kiểm tra kiểu chương trình Haskell có thể thực hiện tính toán Turing tùy ý, đó có phải là quá trình biên dịch hay chạy chương trình không?)

# 1. không chắc. Một mặt, trình biên dịch sản xuất rất phức tạp, vì vậy khả năng xảy ra lỗi là rất cao. Mặt khác, chúng được kiểm tra nghiêm ngặt, xét cho cùng, xử lý đầu vào không đúng cách một cách duyên dáng là một phần của mô tả công việc của trình biên dịch. Ngay cả khi chúng không được kiểm tra, chúng sẽ bị bắn phá với mã không được định dạng dù sao, chỉ cần nhìn vào một số câu hỏi StackOverflow để biết ví dụ về những gì người rác ném vào trình biên dịch của chúng!

Điều này khiến chúng tôi có 3. Một số trình biên dịch có thể giới hạn loại quyền truy cập mà mã thời gian biên dịch có vào hệ thống, nhưng đối với một số trường hợp sử dụng, việc truy cập đầy đủ là không thể tránh khỏi. Ví dụ, mục đích của các nhà cung cấp loại F # là để "giả" các loại tổng hợp cho dữ liệu có hệ thống loại không khớp với F #, để bạn có thể tương tác với một dịch vụ web có lược đồ WSDL được gõ mạnh thời trang. Tuy nhiên, để thực hiện việc này, nhà cung cấp loại cần có quyền truy cập vào tài nguyên lược đồ WSDL trên hệ thống tệp hoặc trên web, do đó, nó cần phải có quyền truy cập mạng và hệ thống tệp.

Vì vậy, nó có an toàn? Về mặt kỹ thuật, không. Có rủi ro không? Không hẳn vậy.

Không nên có bất kỳ rủi ro nào khi biên dịch mã. Về lý thuyết, có thể có một lỗi trong trình biên dịch mà một hacker thông minh có thể lợi dụng nhưng nghe có vẻ khó xảy ra.

Hãy lưu ý rằng tòa nhà có thể không an toàn. Ví dụ: trong C # 'build event' cho phép bạn chỉ định các dòng lệnh tùy ý để thực thi trước và sau khi xây dựng, điều này rõ ràng nguy hiểm và dễ khai thác hơn nhiều so với nói tràn bộ đệm trong mã trình biên dịch.

Thay vì suy đoán, tôi thực sự bận tâm thực hiện một số nghiên cứu về chủ đề này trước khi trả lời, đi đến tài nguyên có thẩm quyền nhất mà tôi có thể nghĩ đến ( Chi tiết CVE ). Danh sách toàn diện các khai thác bảo mật được tiết lộ công khai này có lẽ là cách tốt nhất mà người ta có thể làm để đánh giá mức độ đe dọa của các loại phần mềm khác nhau.

Dĩ nhiên, tôi không mất thời gian để đọc tất cả các tài liệu có sẵn, nhưng tôi đã chọn một vài trình biên dịch "chính", IDE và trình soạn thảo văn bản để đưa ra đánh giá mối đe dọa mẫu. Nếu bạn nghiêm túc về việc chạy bất kỳ phần mềm nào, ít nhất bạn nên xem những mối đe dọa nào ở ngoài đó. Cũng lưu ý rằng phần mềm cũ thường là lỗi hơn so với phần mềm mới hơn, do đó, việc chạy phần mềm mới nhất của bất cứ thứ gì bạn đang chạy là lý tưởng.

Đầu tiên, chúng ta có thể xem qua các trình soạn thảo văn bản khác nhau. Có vẻ như các biên tập viên tốt nhất là đơn giản nhất. Vi nếu bạn đang sử dụng trình bao Linux hoặc Notepad nếu bạn đang ở trong Windows. Một cái gì đó không có khả năng định dạng, không phân tích cú pháp, chỉ xem trực tiếp dữ liệu và tự động chấm dứt phân tích cú pháp nếu một ký tự nằm ngoài lược đồ mã hóa hiện tại. Ngay cả Notepad ++ cũng có một số lỗ hổng. Tránh bất cứ điều gì phức tạp khi xem các tập tin không đáng tin cậy.

Thứ hai, chúng ta có thể nhìn vào IDE. Nếu bạn chọn mở tệp trong IDE, bạn nên biết rằng một số IDE đã báo cáo lỗi. Rõ ràng Visual Studio đã khai thác có sẵn thông qua cơ chế mở rộng, vì vậy việc mở một giải pháp có thể có vấn đề. Tránh các IDE tránh được toàn bộ một lớp vấn đề giữa bạn và mã không tin cậy. Gắn bó với VI có vẻ an toàn hơn rất nhiều.

Thứ ba, chúng ta có thể nhìn vào trình biên dịch thực tế. Tôi đã duyệt qua một số, bao gồm C / C ++ của Adobe, Microsoft, Java và GNU, và thấy rằng nói chung, việc biên dịch mã (và thậm chí là xây dựng , giả sử không có tệp tạo tùy chỉnh) là tương đối an toàn, nhưng mỗi trình biên dịch đó làm hoặc làm có các khai thác bảo mật có thể phát sinh từ việc thực sự chạy các nhị phân được biên dịch. Nói cách khác, họ không thể chiếm hệ thống của bạn chỉ bằng cách biên dịch, nhưng họ có thể bằng cách chạy mã.

Vì vậy, kết luận, giả sử phương thức gửi không chiếm quyền điều khiển hệ thống của bạn (ví dụ: ứng dụng email của bạn đã bị hack hoặc ổ USB mà nó bị nhiễm ...), đọc mã nguồn và biên dịch mã nguồn có thể an toàn . Bằng cách nghiên cứu phần mềm cụ thể của bạn, bạn có thể làm cho nó an toàn hơn bằng cách xác nhận tệp nằm trong trang mã chính xác, v.v. Việc chạy mã chỉ nên được thực hiện trên phần cứng mà bạn không quan tâm. Không phải là VM, mà là toàn bộ máy tính vật lý khác nhau không có quyền truy cập mạng và không có tệp nhạy cảm hoặc thiết bị bên ngoài. Ngay cả khi bạn nghĩ rằng bạn hiểu mã, nghiên cứu đơn giản cho thấy ngay cả trình biên dịch cũng có lỗi có thể cho phép khai thác tràn bộ đệm ẩn để lén từ phía sau và thực thi mã tùy ý, nhưng chỉ khi bạn chọnchạy hoặc gỡ lỗi chương trình. Biên soạn thực tế nên được an toàn.

Chà, tôi sẽ bắt đầu với việc "xem lại mã của họ". Tại sao cần phải thực sự chạy mã?

Ngoài ra, có rất nhiều trình biên dịch trực tuyến nơi bạn có thể chỉ cần nhập mã và biên dịch và / hoặc chạy nó. Bạn có thể thực hiện yêu cầu đó: nó biên dịch trong trình biên dịch trực tuyến này.

Dưới đây là ví dụ về trang có trình biên dịch trực tuyến: Trình biên dịch trực tuyến

Mã để xem xét cho một cuộc phỏng vấn việc làm không nên quá lớn vì bạn không hiểu những gì đang xảy ra.

Các trình biên dịch có được xác nhận hợp lệ để đảm bảo chúng sẽ không làm hỏng máy người dùng khi biên dịch một số đoạn mã thông minh không?

Nói chung, chúng quá phức tạp và thường được viết bằng các ngôn ngữ không thực tế để chứng minh tính chất này.

Có thể không phải với mục đích cụ thể này, nhưng khái niệm về trình biên dịch thử nghiệm fuzz ít nhất được biết đến ( LLVM bây giờ có thể tự kiểm tra fuzz ). Các thử nghiệm nhằm bắt đầu vào làm hỏng trình biên dịch do lỗi trình biên dịch sẽ có xu hướng cũng bật lên các lỗ hổng có thể khai thác.

Đương nhiên, bạn phải xem xét trình biên dịch cụ thể mà bạn quan tâm đã được kiểm tra hay thử nghiệm fuzz để tìm các sự cố tiềm ẩn và liệu các lỗi được tìm thấy có thực sự được sửa hay không. Nguyên tắc chung là nếu có sự cố bất kỳ tồi tệ hơn ngoại lệ bộ nhớ, thì không cần điều tra chi tiết hơn nữa, bạn phải xem xét một khả năng nghiêm trọng mà chúng có thể được tận dụng để khai thác.

Làm thế nào an toàn để biên dịch một đoạn mã từ một người lạ?

Thật không may, một đoạn dây dài bao nhiêu. Về nguyên tắc , email có thể khai thác ứng dụng thư khách của bạn hoặc mã nguồn có thể khai thác trình soạn thảo văn bản hoặc cppcheck của bạn, trước khi nó đến trình biên dịch của bạn. Đề xuất của Sebastian trong các nhận xét để sử dụng trình biên dịch trực tuyến là một điều khá tốt, nhưng tất nhiên mã phải ở dạng mà trình biên dịch sẽ chấp nhận.

Bất kỳ ngôn ngữ hoặc trình biên dịch với các phương tiện để thực thi mã chung thời gian biên dịch tất nhiên là rất đáng ngờ. Các mẫu C ++ đã hoàn thành về mặt chức năng nhưng không có quyền truy cập (dự định) vào hệ thống, vì vậy chúng có rủi ro tương đối thấp. Bовић đề cập đến makerủi ro cực kỳ cao (vì nó đang thực thi mã của người lạ, chỉ là mã đó được viết bằng makengôn ngữ, không phải bằng C ++). Nếu trình biên dịch sẽ chạy systemthì bạn đang ở trong cùng một chiếc thuyền. Tôi đã từng làm việc với một trình biên dịch chương trình, nếu tôi nhớ đúng, có thể thực hiện mã thời gian biên dịch tùy ý. Nó được dùng để tính toán các bảng tra cứu, nhưng tôi không nghĩ bất cứ điều gì ngăn cản bạn thực hiện các cuộc gọi hệ thống.

Trong thực tế , nếu mã có vẻ ổn với tôi và tôi nghĩ tôi hiểu nó, thì tôi sẽ coi nó có rủi ro rất thấp để biên dịch nó, rủi ro thấp hơn nhiều so với việc nói "duyệt internet với trình duyệt bị khóa". Tôi thường xuyên làm những việc nguy hiểm hơn trên máy đa năng của mình, nhưng nhiều trong số đó tôi sẽ không làm, ví dụ như trong phòng thí nghiệm virus hoặc trên một máy chủ quan trọng. Nếu mã trông buồn cười hoặc bị che giấu rõ ràng thì tôi không thể mạo hiểm biên dịch nó, ngoài rủi ro nó có thể chứa một khai thác ẩn trong thùng rác không thể đọc được, đó là mã rác. Mã ngầm là khó khăn nhưng có thể. Mã được xử lý ngầm giúp máy thông qua khai thác trình biên dịch cần phải chứa một tải trọng thực thi không tầm thường, vì vậy cực kỳ khó khăn.

Nếu bạn muốn xem xét thêm về vấn đề này, hãy thử hỏi những người lưu trữ trình biên dịch trực tuyến. Nếu điều đó chưa được thực hiện với họ sau đó (cấm bạn chú ý đến NSA hoặc tương đương), bạn có thể cho rằng một cách hợp lý rằng nó sẽ không được thực hiện với bạn. Họ đã nỗ lực để chạy trình biên dịch của họ trong một hộp cát thích hợp, điều này có thể tốn nhiều công sức hơn bạn sẵn sàng, nhưng ít nhất họ có thể cho bạn biết tần suất mà hộp cát đó cứu họ.

Mặc dù điều này nói chung là một mối quan tâm, tôi nghĩ rằng vấn đề này không tồn tại do thiết lập.

Người nộp đơn đã gửi cho bạn một số mã nguồn. Làm thế nào hoặc tại sao điều đó xảy ra?

Rõ ràng là chỉ có ba khả năng:

1. Bạn đã cho người nộp đơn một nhiệm vụ để giải quyết một vấn đề cụ thể (được xác định rõ) để đánh giá các kỹ năng của anh ta.
2. Người nộp đơn muốn thể hiện một cái gì đó mát mẻ ông viết.
3. Người nộp đơn là một kẻ ngốc hoặc một gián điệp hoặc một người độc hại khác và không thực sự quan tâm đến việc được thuê. Tất cả những gì anh ấy hy vọng là bạn đủ ngu ngốc để chạy mã của anh ấy.

Khoảng 2) và 3)

Nguy cơ chính là phân biệt giữa 2) và 3). Rất có thể là nếu bất cứ điều gì anh ấy viết đều đáng xem , thì đó là thứ mà bạn có thể lấy mã nguồn trực tuyến (từ nguồn "trung tính") và thậm chí bạn có thể quen thuộc với nó, hoặc đó là thứ mà bạn thực sự không tặng Tôi không muốn xem xét vì bạn sẽ xâm phạm quyền sở hữu trí tuệ của đối thủ cạnh tranh (chủ cũ). Điều thứ hai có nghĩa là bạn sẽ không muốn thuê người đó.
Nếu bạn có thể lấy nguồn trực tuyến, hãy làm như vậy. Nếu bạn có thể xác minh đóng góp của người nộp đơn cho một phần mềm nổi tiếng (bao gồm cả phần mềm độc quyền) bằng tên của anh ta ở đâu đó trong các khoản tín dụng, hãy làm như vậy.
Trong mọi trường hợp khác, chỉ cần bỏ qua bất cứ điều gì anh ấy gửi cho bạn. Điều đó không đáng để xem xét, hoặc bất hợp pháp hoặc rủi ro cao.

Khoảng 1)

Người nộp đơn đã gửi cho bạn một cái gì đó bởi vì bạn đã giao cho anh ta một nhiệm vụ. Nếu bạn có bất kỳ năng lực nào (mà tôi cho là bạn làm!), Thì đối với một bài tập lập trình điển hình (... mà bạn thậm chí đã chọn chính mình!), Bạn sẽ có thể biết liệu đó có phải là một giải pháp hợp lý trông giống như nó có thể hoạt động không bằng cách xem mã nguồn trong ít hơn 30 giây (nhiều khả năng là 10 giây).

Nếu bạn không thể nói rằng chương trình có thể sẽ hoạt động (hoặc những gì nó đang làm) trong vòng 30 giây, thì người đã viết nó không phải là loại người bạn muốn thuê, fullstop. Bạn muốn những người viết mã mà những người khác có thể hiểu và duy trì. Bạn không muốn ai đó đang cố gắng thông minh với bạn, cũng không phải ai đó thường xuyên giành chiến thắng trong cuộc thi C khó hiểu. Nó thậm chí không quan trọng cho dù chương trình hoạt động. Ngay khi một người khác không thể hiểu được mã, nó không bao giờ "hoạt động".
Nếu chương trình có vẻ như sẽ hoạt động, nhưng bạn tìm thấy bất cứ thứ gì trông "lạ" (giả sử, các chuỗi thoát mã unicode của Java, chuỗi ký tự thô C ++, các công cụ trông giống như ba chữ, bất cứ thứ gì), coi phép gán là "fail", di chuyển vào người nộp đơn tiếp theo. Không cần thiết phải bao gồm bất cứ điều gì giống như trong 99% tất cả các chương trình (và, chắc chắn, không phải trong bài tập của bạn - tôi nên hy vọng). Vì vậy, nếu bạn tìm thấy bất cứ điều gì "kỳ lạ" như thế, người nộp đơn không phải là người bạn sẽ muốn thuê.

Nếu mã vượt qua lần xử lý đầu tiên đó, bạn có thể muốn dành thêm 2-3 phút để xem xét kỹ hơn. Nếu bạn vẫn hài lòng với những gì bạn thấy sau đó, bạn có thể chạy nó thông qua một bộ phân tích tĩnh và biên dịch nó trong một máy ảo ở mức cảnh báo cao.

Điều đó sẽ đưa ra các vấn đề mà bạn có thể đã bỏ lỡ trong khi đọc nguồn (chẳng hạn như gọi hành vi không xác định hoặc thu hẹp chuyển đổi).
Việc biên dịch trước hết sẽ cho bạn biết liệu người nộp đơn có cần mẫn và chú ý đến từng chi tiết hay không, không quá nhiều cho dù anh ta có kỹ năng lập trình hay không. Giống như viết chính xác tên của nhà tuyển dụng vào ứng dụng của bạn và kiểm tra chính tả CV của bạn trước khi nộp, cách tốt nhất là bạn đảm bảo bất kỳ mã nguồn nào bạn đưa vào biên dịch mà không có lỗi (và tốt nhất là không có cảnh báo). Nếu ai đó không làm điều đó, bạn không muốn thuê anh ta.

Nguy cơ của những điều xấu xảy ra tại thời điểm này (khai thác trình biên dịch và thoát ra khỏi VM) là không thể chấp nhận được, xem cách bạn đã chạy kiểm tra tính hợp lý đối với mã. Sẽ không xảy ra.

Nếu khả năng làm bạn lo lắng, hãy mang theo một máy cũ hơn (hầu hết chúng ta không có vài người ngồi xung quanh?), Cài đặt phiên bản Linux và trình biên dịch hiện tại, sao chép mã nguồn vào nó, rút ​​cáp mạng (hoặc tắt WiFi ) và thực hiện các biên dịch. Nếu bất cứ điều gì khó chịu xảy ra, nó sẽ không * ảnh hưởng đến bất cứ điều gì khác.

Và đối với phần mềm độc hại trong Makefile, hãy chạy nó với cờ -n (IIRC, RTMF) để xem nó sẽ làm gì mà không thực sự làm điều đó.

* Tất nhiên trừ khi lập trình viên của bạn mã hóa phần mềm độc hại để nó chờ kết nối lại, nhưng trong trường hợp đó, bạn a) lau máy; và b) chuyển tiếp sơ yếu lý lịch của anh chàng đến NSA, vì anh ta lãng phí trong thế giới thương mại :-)

Điểm mấu chốt là có là rủi ro. Rủi ro khá nhỏ như các câu trả lời khác lưu ý, nhưng có một rủi ro. Điều đó có nghĩa là bạn cần đặt hai câu hỏi:

1. Tôi có thể làm gì để giảm thiểu rủi ro?
2. Là rủi ro đủ cao mà tôi nên quan tâm?

Thứ hai là những gì bạn đã đặt ra ở đây trong câu hỏi này, nhưng đó là trọng tâm sai cho trường hợp cụ thể này. Câu trả lời để giảm thiểu rủi ro là rõ ràng và sẵn có: không biên dịch mã trên máy của bạn . Bạn có hai cách biên dịch rõ ràng mà không cần sử dụng máy của mình:

1. Sử dụng máy ảo (như @FlorianMargaine đã chỉ ra ngay lập tức trong các bình luận). Bạn chỉ cần chụp nhanh nó trước khi biên dịch và sau đó khôi phục ảnh chụp nhanh khi bạn hoàn thành.
2. Sử dụng một dịch vụ lưu trữ (như trình biên dịch trực tuyến).

Những cách giảm thiểu rủi ro của bạn rất rõ ràng, rẻ tiền và dễ dàng truy cập đến mức không đáng để dành nhiều thời gian để cố gắng phân tích mức độ rủi ro lớn như thế nào. Chỉ cần làm một trong số họ và được thực hiện với nó.

Visual Studio thực sự cảnh báo bạn nếu bạn mở một dự án từ một vị trí không đáng tin cậy (e, g, đã tải xuống hoặc chia sẻ mạng).

Một ví dụ về cách khai thác điều này sẽ như thế nào với dự án WPF: Bạn có thể tham chiếu các lớp .NET từ XAML và để cung cấp IntelliSense, VS tải và thực thi các lớp được tham chiếu tại thời điểm thiết kế.

Điều đó có nghĩa là kẻ tấn công có thể thả một mã độc vào thư mục bin, thay thế mã nguồn bằng mã không độc hại và tại thời điểm thiết kế, DLL được thực thi. Sau bản dựng đầu tiên của bạn, mọi dấu vết của nhị phân độc hại sẽ biến mất.

Vì vậy, mặc dù tất cả các mã được cung cấp là "sạch", trình biên dịch không có lỗi và tất nhiên, bạn không bao giờ thực hiện thủ công bất kỳ .EXE nào được cung cấp, mã độc vẫn có thể được thực thi trong nền. (Để an toàn trước cuộc tấn công cụ thể đó, bạn chỉ cần đảm bảo rằng KHÔNG có nhị phân trong cây thư mục trước khi mở giải pháp. Sau đó, VS sẽ nhắc bạn xây dựng giải pháp trước khi cung cấp IntelliSense vào thời gian thiết kế.)

Các vectơ tương tự có thể tồn tại với các ngôn ngữ / HĐH khác.

Đọc mã nguồn: hoàn toàn an toàn. Biên dịch mã nguồn: hoàn toàn an toàn. Thực hiện nhị phân biên dịch: tốt ... điều đó phụ thuộc.

Biên dịch chỉ là máy tính đọc mã nguồn và viết tương đương ở dạng nhị phân. Sau khi biên dịch, bạn chỉ có 2 tài liệu: một người có thể đọc được và một máy tính khác có thể đọc được. Trừ khi bạn nhận được máy tính để đọc (tức là chạy) tài liệu thứ 2, không có gì sẽ xảy ra.

Tôi nghĩ rằng bạn đang lo lắng về một trong hai hương vị:

• phần mềm độc hại tinh vi, khai thác : không thể, đặc biệt là vì chúng được nhắm mục tiêu vào phần cứng và / hoặc phần mềm rất cụ thể và [dựa trên câu hỏi của bạn] kẻ tấn công của bạn có thể không có kiến ​​thức hệ thống đó.
• những thứ liên quan đến môi trường của bạn : các chỉ thị chơi khăm độc hại (ví dụ như xóa thư mục chính của bạn) hoặc các chỉ thị không phù hợp / không đủ năng lực làm thay đổi hành vi hệ thống của bạn (ví dụ: viết lại các biến môi trường PATH hoặc LIBRARY)

Một số người đã đề xuất máy ảo hoặc hệ thống cũ, nhưng tôi cung cấp một giải pháp dễ dàng hơn nhiều: Biên dịch như một người dùng khác với các quyền được giảm / khác nhau . Dễ dàng hơn nhiều so với việc thiết lập một máy ảo hoặc một máy tính chuyên dụng.

Nếu trong trường hợp không chắc là hệ thống của bạn bị khai thác bởi các khai thác thời gian biên dịch, hãy khôi phục từ các bản sao lưu (bạn có những thứ đó, phải không?).