Lỗ hổng Python làm nổi bật tai ương bảo mật nguồn mở. mục tiêu công nghệ

Cách CVE-2007-4559 quản lý để tránh bị phát hiện

Cựu tình nguyện viên PSF Lars Gustäbel đã lãnh đạo công việc về lỗ hổng Python 15 năm trước và thậm chí còn đề xuất cách khắc phục vào năm 2014. Tuy nhiên, anh ấy đã rời PSF vào năm 2019 giữa cuộc thảo luận về một bản vá Python tarfile dường như đã bị bỏ rơi kể từ khi anh ấy rời đi

Gustäbel và một nhà bảo trì PSF đồng nghiệp đã quyết định rằng lỗ hổng Python tarfile không đảm bảo vấn đề bảo mật và thay vì vá lỗi, PSF đã cung cấp tài liệu cảnh báo tuyên bố rằng có thể "nguy hiểm khi trích xuất tệp lưu trữ từ các nguồn không đáng tin cậy" trong một chuỗi GitHub công khai từ năm 2007 đã thảo luận . "

Gustäbel đã viết trong một email gửi tới TechTarget Editorial, "Về nguyên tắc, tôi vẫn ủng hộ tuyên bố đó, nhưng đây không phải là vấn đề tầm thường và có nhiều khía cạnh của nó. "

Trong một bài đăng trên blog được xuất bản vào tuần trước, anh ấy đã cung cấp thêm thông tin cơ bản, lưu ý rằng anh ấy đã bỏ qua báo cáo lỗi ban đầu vào năm 2007 và đã gửi một bản vá để xem xét trong trình theo dõi lỗi Python vào năm 2014

Cuộc thảo luận nhanh chóng kết thúc, không có phiếu bầu rõ ràng và bản vá không bao giờ được áp dụng, Gustäbel đã viết trong một bài đăng trên blog, "Vào thời điểm đó, đối với tôi, dường như đây không phải là cách mà hầu hết mọi người muốn khắc phục sự cố. "Tôi ngày càng gặp khó khăn trong việc hoàn thành trách nhiệm của mình với tư cách là người duy trì tarfile, vì vậy khi cuộc thảo luận về bản vá được tiếp tục vào năm 2018, tôi đã không thể tham gia do hạn chế về thời gian. Do đó, tôi đã từ chức khỏi vị trí người bảo trì vào năm 2019

Chuỗi GitHub tiết lộ rằng bản vá được đề xuất của Gustäbel không nhận được phản hồi nào trong năm 2014;

Một nhà phát triển Python đã trả lời câu hỏi về tình trạng của bản vá năm 2019 bằng cách nói: "Đã có tiến triển như được mô tả về vấn đề này, nhưng vẫn còn nhiều việc phải làm và dường như không ai tự mình thực hiện điều này tại

Gustäbel đã viết rằng "tuyên bố rằng có một lỗ hổng bảo mật trong mô-đun tarfile đã bị bỏ qua trong 15 năm là hơi phóng đại và không có cơ sở.". " Anh ấy đã nói rõ rằng anh ấy không còn làm việc với PSF nữa và không đại diện cho nhóm cũng như các nhà phát triển của nó

Theo ý kiến ​​của Gustäbel, lỗ hổng này "không hiển thị lỗ hổng bảo mật trong mô-đun tarfile mà thay vào đó là trong Spyder IDE", một môi trường lập trình mã nguồn mở dành cho Python và ông đã giải quyết nhiều lo ngại từ báo cáo của Schulz từ tháng trước ghi nhận rủi ro cao hơn đối với . Các nhà nghiên cứu từ Trellix chỉ ra cách kẻ tấn công có thể sử dụng môi trường đó để khai thác lỗ hổng Python để thực thi mã từ xa

Gustäbel đã nêu trong bài đăng trên blog rằng "cả mô-đun tarfile và pickle đều được sử dụng theo những cách mà chúng không nhằm mục đích sử dụng và điều đó không được khuyến khích mạnh mẽ trong tài liệu. "

Chủ đề GitHub chỉ ra rằng không có cuộc thảo luận mới nào về bản vá được đề xuất kể từ khi Trellix xuất bản báo cáo của mình vào tháng trước, mặc dù nghiên cứu mới của Trellix về CVE-2007-4559

Victor Stinner, một nhà phát triển Python của PSF, đã nói với TechTarget Editorial vào tháng trước rằng có một đề xuất "thêm một tùy chọn để chọn tham gia hành vi an toàn hơn", nhưng nó đã không được triển khai. Không rõ PSF cuối cùng sẽ thực hiện hành động gì, nếu có, đối với lỗ hổng Python. Chủ đề GitHub của thay đổi được đề xuất nói rằng tính năng chọn tham gia đã được thảo luận rộng rãi trong vài tuần qua, nhưng nó vẫn chưa được triển khai

Trellix giải quyết vấn đề

Tính đến tuần trước, Douglas McKee, kỹ sư chính và giám đốc nghiên cứu lỗ hổng tại Trellix, cho biết họ đã gửi gần 11.000 yêu cầu kéo tới các kho lưu trữ, với khoảng 140 bản vá được áp dụng đã được xác nhận. Các nhà nghiên cứu của Trellix nhận thấy rằng 61% kho lưu trữ GitHub sử dụng gói tarfile dễ bị tấn công

Không có đối tác bổ sung nào tham gia và McKee nhấn mạnh quá trình vá lỗi diễn ra chậm như thế nào, nhưng ông đã nhấn mạnh một điểm tích cực, cho biết Trellix đang trên đà đáp ứng số lượng ban đầu khoảng 60.000 bản vá trước khi hoàn thành nhiệm vụ to lớn

Theo McKee, mạng mã nguồn mở Monai dành cho trí tuệ nhân tạo y tế, đã chấp nhận yêu cầu kéo của chúng tôi và có một khung dễ bị tổn thương bởi lỗ hổng này và đã được tải xuống hơn 600.000 lần, là một minh họa cho thấy điều này đang tăng cường an ninh mạng trong các ngành như thế nào.

"Những nỗ lực của chúng tôi đã giúp đảm bảo phần công nghệ nguồn mở này cho các chuyên gia y tế," ông nói. "Vì nó là một khung nên điều này ảnh hưởng trực tiếp đến chuỗi cung ứng, vì các ứng dụng được xây dựng xung quanh cơ sở mã này. Chúng tôi mong muốn được thấy những nỗ lực của chúng tôi sẽ tiếp tục mang lại lợi ích cho nhiều ngành công nghiệp như thế nào

Lỗ hổng Python làm nổi bật những lo ngại về bảo mật nguồn mở khi nói đến giao tiếp và hỗ trợ, bất chấp những bất đồng giữa Trellix và PSF về cách tiến hành. Các chuyên gia của Infosec đồng ý rằng đây là một tình huống phức tạp và rất khó để nói chính xác ai là người có lỗi

Theo Josh Bressers, phó chủ tịch an ninh của nhà cung cấp an ninh chuỗi cung ứng Anchore, trong khi phần mềm nguồn mở không có gì đảm bảo, thì có những kỳ vọng nhất định đối với công nghệ cốt lõi. Trong trường hợp này, Python là ngôn ngữ lập trình phổ biến

Mọi người có lẽ sẽ đồng tình rằng tuyên bố sứ mệnh của Tổ chức Phần mềm Python, kêu gọi "bảo vệ" ngôn ngữ Python, có thể áp dụng được, theo Bressers, người đã nói chuyện với TechTarget Editorial

Vì Python là mã nguồn mở nên bất kỳ ai có khả năng viết bằng C đều có thể đóng góp các bản cập nhật, theo Tim Mackey, chiến lược gia bảo mật chính tại Trung tâm nghiên cứu an ninh mạng Synopsys. Ông nói thêm, việc thiếu các bản cập nhật nói lên một vấn đề chung với việc tiêu thụ nguồn mở. Mặc dù gần như tất cả các doanh nghiệp đều sử dụng phần mềm nguồn mở, nhưng việc quản lý nó là một thách thức, theo một báo cáo bảo mật nguồn mở của Synopsys được công bố vào tháng 4

Nếu tương lai của công ty bạn phụ thuộc vào mã miễn phí nhưng bạn không trả lại hoặc tham gia tích cực vào các nhóm phát triển đang sản xuất phần mềm miễn phí đó, Mackey nói, "bạn đang mặc nhiên chấp nhận bất kỳ rủi ro nào liên quan đến các quyết định mà các tác giả đó đưa ra. "

Tương tự như vậy, ông nói rằng điều quan trọng là phải hiểu rằng các nền tảng phần mềm nguồn mở như PSF không thể so sánh với các nhà cung cấp phần mềm thương mại, những người được yêu cầu vá bất kỳ và tất cả các lỗi. Anh ấy nói, thật đơn giản để chỉ trích nền tảng đó khi sự phát triển nguồn mở cho phép mọi người có cơ hội đóng góp cả các bản sửa lỗi và chức năng mới, bao gồm cả các nhà nghiên cứu đang thu hút sự chú ý đến lỗ hổng.

Theo Mackey, "trong trường hợp này, có một cuộc thảo luận mới về vấn đề GitHub và cuộc thảo luận đó cho thấy mức độ khó để khắc phục sự cố bảo mật mà không thực hiện các thay đổi vi phạm người dùng. "

CSO có thể kiểm soát Robert Huber đã nêu bật các tài nguyên và mức độ nỗ lực cần thiết để khắc phục, lưu ý rằng các yếu tố này giống nhau đối với các nỗ lực thương mại, vì các yếu tố góp phần tạo nên sự khác biệt khác, đó là một số dự án nguồn mở có nhiều nhân viên giỏi hơn và phản hồi rất nhanh

Quan trọng hơn, theo Huber, an ninh chuỗi cung ứng đã không được tính đến ở mức độ tương tự vào năm 2007 khi lỗ hổng được phát hiện lần đầu tiên

Ngay cả những sản phẩm ra mắt trong tháng này của những gã khổng lồ công nghệ như Google cũng tập trung vào việc đảm bảo an toàn cho chuỗi cung ứng phần mềm, trước các cuộc tấn công chuỗi cung ứng phần mềm quan trọng trong vài năm qua, chẳng hạn như SolarWinds

Sẽ không an toàn khi chỉ tin tưởng vào phần mềm nguồn mở và Huber nhấn mạnh tầm quan trọng của việc các doanh nghiệp tự xác minh mã đó cho chính họ. Tuy nhiên, 15 năm trước, không có vòng đời phát triển phần mềm an toàn với phân tích thành phần phần mềm hoặc kiểm tra sự phụ thuộc của bên thứ ba

Huber nói, "Bạn phải đánh giá từng dự án một cách chi tiết để xác minh. Nghiên cứu [Trellix] lưu ý rằng họ đang tìm kiếm tệp tarfile nhập -- mặc dù đây là dấu hiệu cho thấy một dự án có thể dễ bị tấn công nhưng điều đó không nhất thiết có nghĩa là nó tồn tại,"Trong bất kỳ trường hợp nào, đó là một dấu hiệu tuyệt vời cho biết các quy trình phát triển phần mềm của bạn có hoạt động hay không.

Lỗ hổng truyền tải thư mục, mà Mackey định nghĩa là "các tình huống trong đó dữ liệu do người dùng cung cấp hoặc người dùng có thể sửa đổi được sử dụng mà không cần xác thực hoặc không có ranh giới", không có gì mới. Một vấn đề tiềm ẩn là lỗ hổng duyệt thư mục có thể ảnh hưởng đến nhiều thứ hơn là chỉ mô-đun tarfile. Quan trọng hơn, ông nói thêm, thật đơn giản để các nhà phát triển viết mã với loại lỗ hổng đó

Tuy nhiên, Mackey khẳng định rằng các công cụ bảo mật ứng dụng phổ biến có thể hỗ trợ xác định loại mối đe dọa này

Bressers thừa nhận rằng lỗ hổng sẽ ảnh hưởng đến nhiều thứ hơn là chỉ tập tin, đó là lý do tại sao ông tìm kiếm các mô-đun bị ảnh hưởng khác để tiết lộ đầy đủ lỗ hổng bảo mật

Bressers tuyên bố, "Các nhà phát triển Python đang bắt đầu thảo luận thay vì hành động ngay lập tức, điều mà tôi đồng ý 100% là hành động đúng đắn. "

Nếu các doanh nghiệp áp dụng các bản vá Trellix, thì điều quan trọng là người dùng Python phải kiểm tra kỹ lưỡng chương trình của họ để đảm bảo không có thay đổi nào phá vỡ bất kỳ điều gì và không cần cập nhật cài đặt cấu hình

Theo Mackey, người dùng Python trong các tình huống có tuổi thọ cao nên chú ý đến cách dữ liệu do người dùng cung cấp có thể được sử dụng bởi giao diện này, theo Mackey, dựa trên tuổi của lỗ hổng này

Làm thế nào CVE-2007-4559 lọt qua vết nứt

Lars Gustäbel, một cựu tình nguyện viên của PSF, đã dẫn đầu về lỗ hổng Python 15 năm trước và thậm chí đã đề xuất một bản sửa lỗi vào năm 2014. Tuy nhiên, anh ấy đã rời PSF vào năm 2019 trong bối cảnh cuộc thảo luận về bản vá tarfile Python đang diễn ra dường như đã thất bại trước sự ra đi của anh ấy

Trong một chủ đề GitHub công khai từ năm 2007 thảo luận về lỗ hổng Python tarfile, Gustäbel nói rằng "sau khi xem xét cẩn thận", ông và một nhà bảo trì PSF đồng nghiệp đã quyết định lỗ hổng này không đảm bảo vấn đề bảo mật. Thay vì vá lỗi, PSF cung cấp tài liệu cảnh báo cho biết có thể "nguy hiểm khi trích xuất tài liệu lưu trữ từ các nguồn không đáng tin cậy. "

"Về nguyên tắc, tôi vẫn đứng trước tuyên bố đó," Gustäbel nói trong một email gửi tới TechTarget Editorial. "Tuy nhiên, đây không phải là vấn đề tầm thường, và có nhiều khía cạnh của nó. "

Anh ấy đã cung cấp thêm ngữ cảnh trong một bài đăng trên blog vào tuần trước, lưu ý rằng anh ấy đã loại bỏ báo cáo lỗi đầu tiên vào năm 2007 và đề xuất một bản vá để thảo luận trong trình theo dõi lỗi Python vào năm 2014

"Vào thời điểm đó, đối với tôi, dường như đây không phải là cách mà hầu hết mọi người muốn giải quyết vấn đề. Cuộc thảo luận ngay lập tức kết thúc, vì vậy không có cuộc bỏ phiếu rõ ràng nào và bản vá không bao giờ được triển khai," Gustäbel viết trong bài đăng trên blog. "Năm 2018, cuộc thảo luận về bản vá đã được nối lại, nhưng do thời gian có hạn nên tôi không thể tham gia được nữa. Tôi ngày càng gặp khó khăn trong việc hoàn thành vai trò là người duy trì tarfile. Do đó, vào năm 2019, tôi đã từ bỏ vị trí người bảo trì. "

Chủ đề GitHub cho thấy bản vá được đề xuất của Gustäbel không nhận được phản hồi nào trong năm 2014. Mặc dù cuộc thảo luận về bản vá đã tiếp tục vào năm 2018 và một số tình nguyện viên đã bày tỏ sự ủng hộ đối với nỗ lực này và thậm chí đã sửa đổi bản vá, nhưng sự tham gia vào cuộc thảo luận đã giảm dần và bản vá không bao giờ được phát hành

Về tình trạng của bản vá năm 2019, một nhà phát triển Python đã trả lời: "Đã có tiến triển như được mô tả về vấn đề này, nhưng vẫn còn nhiều việc phải làm và dường như không ai tự mình thực hiện việc này vào lúc này. "

Trong khi Gustäbel nhấn mạnh rằng ông không còn làm việc với PSF và không đại diện cho tổ chức cũng như các nhà phát triển của nó, thì ông viết rằng "tuyên bố rằng có một lỗ hổng bảo mật trong mô-đun tarfile đã bị bỏ qua trong 15 năm là hơi phóng đại và không có cơ sở." . "

Ngoài ra, Gustäbel đã giải quyết nhiều lo ngại từ báo cáo của Schulz vào tháng trước đã ghi lại những rủi ro cao hơn đối với lỗ hổng Python. Theo ý kiến ​​của ông, lỗ hổng "không hiển thị lỗ hổng bảo mật trong mô-đun tarfile mà thay vào đó là trong Spyder IDE", một môi trường phát triển mã nguồn mở dành cho lập trình Python. Các nhà nghiên cứu của Trellix đã chứng minh cách kẻ tấn công có thể khai thác lỗ hổng Python để thực thi mã từ xa bằng môi trường đó

"Cả mô-đun tarfile và pickle đều được sử dụng theo cách mà chúng không được phép sử dụng và điều đó không được khuyến khích trong tài liệu," Gustäbel viết trong bài đăng trên blog

Bất chấp nghiên cứu mới của Trellix về CVE-2007-4559, bản vá đề xuất của Gustäbel vẫn chưa được phát hành. Chủ đề GitHub không hiển thị cuộc thảo luận mới nào về bản vá được đề xuất kể từ khi Trellix xuất bản báo cáo của mình vào tháng trước

Không rõ PSF cuối cùng sẽ thực hiện hành động gì, nếu có, đối với lỗ hổng Python. Victor Stinner, một nhà phát triển Python của PSF, đã nói với TechTarget Editorial vào tháng trước rằng có một đề xuất, lần đầu tiên được giới thiệu vào năm 2017, để "thêm một tùy chọn để chọn tham gia hành vi an toàn hơn", nhưng nó đã không được triển khai. Theo chủ đề GitHub về thay đổi được đề xuất, tính năng chọn tham gia đã được thảo luận rất lâu trong vài tuần qua, nhưng vẫn chưa được triển khai

Trellix giải quyết vấn đề

Khi các nhà nghiên cứu của Trellix phát hiện ra rằng 61% kho lưu trữ GitHub sử dụng gói tarfile dễ bị tấn công, công ty an ninh mạng đã hành động bằng cách phát triển các bản vá của riêng mình. Tính đến tuần trước, Douglas McKee, kỹ sư chính và giám đốc nghiên cứu lỗ hổng tại Trellix, cho biết họ đã gửi gần 11.000 yêu cầu kéo tới các kho lưu trữ, với khoảng 140 bản vá được áp dụng đã được xác nhận.

McKee nói với TechTarget Editorial rằng Trellix đang nhắm mục tiêu đáp ứng số lượng ban đầu khoảng 60.000 bản vá trước khi hoàn thành nhiệm vụ to lớn. Không có đối tác bổ sung nào tham gia và McKee nhấn mạnh quá trình vá lỗi chậm như thế nào, nhưng anh ấy đã nêu bật một điểm tích cực

"Một ví dụ về cách điều này đang cải thiện an ninh mạng trong các ngành là việc Monai, một mạng mã nguồn mở dành cho trí tuệ nhân tạo y tế, chấp nhận yêu cầu kéo của chúng tôi. Khuôn khổ này đã được tải xuống hơn 600.000 lần và dễ bị lỗ hổng này," McKee nói

Ông lưu ý: “Vì nó là một khuôn khổ nên điều này tác động trực tiếp đến chuỗi cung ứng, vì các ứng dụng được xây dựng xung quanh cơ sở mã này”. "Những nỗ lực của chúng tôi đã giúp đảm bảo phần công nghệ nguồn mở này cho các chuyên gia y tế. Chúng tôi rất vui khi thấy tác động tích cực mà những nỗ lực của chúng tôi sẽ tiếp tục có trên nhiều ngành công nghiệp. "

Bất chấp những ý kiến ​​trái chiều giữa Trellix và PSF về cách tiến lên phía trước, lỗ hổng Python đã cho thấy những lo ngại về bảo mật nguồn mở khi nói đến giao tiếp và hỗ trợ. Các chuyên gia của Infosec đồng ý rằng đây là một tình huống phức tạp và thật khó để nói chính xác trách nhiệm nằm ở đâu

Josh Bressers, phó chủ tịch an ninh của nhà cung cấp bảo mật chuỗi cung ứng Anchore, nói rằng trong khi phần mềm nguồn mở không có gì đảm bảo, ông nghĩ rằng có những kỳ vọng nhất định về công nghệ cốt lõi. Trong trường hợp này, Python là ngôn ngữ lập trình được sử dụng rộng rãi

Bressers nói với TechTarget Editorial: "Quỹ phần mềm Python có một tuyên bố sứ mệnh bao gồm 'bảo vệ' ngôn ngữ Python, mà tôi nghi ngờ mọi người sẽ đồng ý rằng điều này có thể áp dụng được".

Tim Mackey, chiến lược gia bảo mật chính tại Trung tâm nghiên cứu an ninh mạng Synopsys, cho biết điều quan trọng là phải nhận ra rằng vì Python là mã nguồn mở nên bất kỳ ai có kỹ năng viết bằng C đều có thể đóng góp các bản cập nhật. Ông nói thêm rằng thực tế là không có ai đóng góp nói lên một vấn đề rộng lớn hơn với việc tiêu thụ nguồn mở. Mức tiêu thụ đó cao. Synopsys đã xuất bản một báo cáo bảo mật nguồn mở vào tháng 4 xác định rằng trong khi gần 100% doanh nghiệp sử dụng phần mềm nguồn mở, thì việc quản lý nó tỏ ra khó khăn

Mackey nói: “Nếu bạn đang đặt tương lai doanh nghiệp của mình dựa trên mã miễn phí và không đóng góp lại hoặc tích cực tham gia với các nhóm phát triển tạo ra phần mềm miễn phí đó, thì bạn đang ngầm chấp nhận bất kỳ rủi ro nào liên quan đến các quyết định mà các tác giả đó đưa ra”.

Tương tự, ông nói rằng điều quan trọng là phải nhận ra rằng các nền tảng phần mềm nguồn mở như PSF không thể so sánh với các nhà cung cấp phần mềm thương mại có nghĩa vụ phải vá bất kỳ và tất cả các lỗi. Ông nói, thật dễ dàng để đổ lỗi cho nền tảng đó khi sự phát triển nguồn mở mang lại cho mọi người cơ hội đóng góp cả các bản sửa lỗi và chức năng mới, bao gồm cả các nhà nghiên cứu đang thu hút sự chú ý đến lỗ hổng.

"Trong trường hợp này, có một cuộc thảo luận mới về vấn đề GitHub và cuộc thảo luận đó cho thấy việc khắc phục sự cố bảo mật mà không tạo ra các thay đổi vi phạm cho người dùng khó đến mức nào," Mackey nói

Một sự khác biệt khác, mà Tenable CSO Robert Huber đã lưu ý, là một số dự án nguồn mở có nhiều nhân viên tốt hơn và phản ứng rất nhanh với các vấn đề so với các dự án khác. Ông nhấn mạnh các yếu tố góp phần là nguồn lực và mức độ nỗ lực cần thiết để khắc phục, điều mà ông chỉ ra là không khác gì đối với các nỗ lực thương mại

Quan trọng hơn, Huber cho biết, khi lỗ hổng được phát hiện lần đầu vào năm 2007, an ninh chuỗi cung ứng đã không được xem xét ở mức độ như ngày nay

Các cuộc tấn công chuỗi cung ứng phần mềm quan trọng trong vài năm qua, chẳng hạn như SolarWinds, đã làm tăng mối lo ngại cho cả doanh nghiệp và các dự án nguồn mở. Ngay cả những sản phẩm ra mắt trong tháng này của những gã khổng lồ công nghệ như Google cũng tập trung vào việc đảm bảo chuỗi cung ứng phần mềm

Tuy nhiên, 15 năm trước, không có vòng đời phát triển phần mềm an toàn với phân tích thành phần phần mềm, Huber lưu ý hoặc kiểm tra sự phụ thuộc của bên thứ ba. Sẽ không an toàn nếu chỉ tin tưởng vào phần mềm mã nguồn mở và Huber nhấn mạnh tầm quan trọng của việc các doanh nghiệp tự xác minh mã như vậy

"Nghiên cứu [Trellix] lưu ý rằng họ đang tìm kiếm tệp tarfile nhập -- mặc dù đây là một chỉ báo cho thấy một dự án có thể dễ bị tổn thương, nhưng điều đó không nhất thiết có nghĩa là nó. Bạn phải đánh giá chi tiết từng dự án để xác minh," Huber nói. "Bất kể, đó là một điểm dữ liệu tuyệt vời để đảm bảo bạn đang thực hành các phương pháp phát triển phần mềm an toàn tốt. "

Một vấn đề tiềm ẩn khác là lỗ hổng duyệt thư mục có thể ảnh hưởng đến nhiều thứ hơn là chỉ mô-đun tarfile. Lỗ hổng truyền tải thư mục, mà Mackey mô tả là "các tình huống trong đó dữ liệu do người dùng cung cấp hoặc người dùng có thể sửa đổi được sử dụng mà không cần xác thực hoặc không có ranh giới", không có gì mới. Quan trọng hơn, ông nói, các nhà phát triển dễ dàng viết mã có chứa loại lỗ hổng đó

Mặt khác, Mackey cho biết các công cụ bảo mật ứng dụng tiêu chuẩn có thể giúp xác định loại mối đe dọa này

Bressers đồng ý rằng lỗ hổng này sẽ không chỉ ảnh hưởng đến tarfile, đó là lý do tại sao ông tin rằng việc tìm kiếm các mô-đun bị ảnh hưởng khác là cách đúng đắn để giải quyết triệt để lỗ hổng bảo mật mã nguồn mở

Bressers cho biết: “Thay vì vội vàng làm điều gì đó, các nhà phát triển Python đang bắt đầu thảo luận, điều mà tôi 100% đồng ý là hướng đi đúng đắn”.

Mackey cho biết, nếu các doanh nghiệp triển khai các bản vá Trellix, thì điều quan trọng là người dùng Python phải kiểm tra rộng rãi các ứng dụng của họ để đảm bảo không có thay đổi vi phạm nào xảy ra và không cần cập nhật cài đặt cấu hình

Mackey cho biết: “Với độ tuổi của lỗ hổng này, người dùng Python trong các tình huống có tuổi thọ cao nên đặc biệt chú ý đến cách giao diện này có thể sử dụng dữ liệu do người dùng cung cấp”.

Python có lỗ hổng bảo mật không?

Lỗ hổng trong mã nguồn mở là gì?