Cảnh báo: Mô hình ngôn ngữ lớn (LLM) có thể chiếm quyền điều khiển máy chủ qua lỗ hổng suy luận

| Đọc trên LessWrong |

Các mô hình ngôn ngữ lớn (LLM) thường thực hiện các hành động trên một máy tính (thông qua một công cụ hỗ trợ tác nhân như Claude Code hoặc Codex), tuy nhiên phản hồi của LLM đối với các câu lệnh (prompt) lại được tính toán trên một máy tính khác có quyền truy cập GPU. Liệu một LLM độc hại có thể giành quyền kiểm soát máy chủ nơi các trọng số (weights) của nó được tải lên không? Một cỗ máy như vậy là mục tiêu có giá trị cao: nó có đủ năng lực tính toán để chạy một LLM tiên tiến, cung cấp quyền truy cập dễ dàng vào các trọng số của LLM, và có quyền truy cập đặc quyền vào các máy tính khác trong trung tâm dữ liệu so với một máy tính thông thường trên internet.

Bài viết này khám phá mức độ dễ dàng mà một LLM độc hại có thể giành quyền kiểm soát máy chủ. Cuộc tấn công chính được xem xét ở đây liên quan đến việc LLM phát ra một chuỗi token có ý nghĩa ngữ nghĩa không liên quan, nhưng lại khai thác lỗ hổng trong phần mềm tải LLM lên GPU, chạy LLM để tạo ra các token đầu ra và phân tích các token đó thành phản hồi.

Làm thế nào một LLM có thể thực thi mã trên máy chủ?

Giống như bất kỳ chương trình nào, các công cụ suy luận (inference engine) như vLLM hoặc SGLang có thể chứa các lỗi có thể khai thác được. Vì LLM kiểm soát các token được truyền đến công cụ suy luận, một LLM độc hại có thể phát ra một chuỗi token mà một công cụ suy luận được viết kém sẽ nhầm lẫn là mã hoặc hướng dẫn cần thực thi thay vì dữ liệu để trả về cho người dùng.

Nhưng chắc chắn tất cả các công cụ suy luận đều là những phần mềm mạnh mẽ và điều này sẽ không bao giờ xảy ra, phải không?

vLLM trước đây đã từng sử dụng eval trên các tham số gọi công cụ (tool-call).

CVE-2025-9141 là một lỗi thực thi mã tùy ý trong trình phân tích cú pháp XML của vLLM dành cho Qwen3 Coder. Trình phân tích này đã truyền gần như mọi đối số gọi công cụ vào eval, cho phép LLM thực thi mã tùy ý trên máy chủ. Gemini đã tự động phân tích PR (Pull Request) giới thiệu lỗi này và gắn cờ chính xác nó là một lỗ hổng bảo mật nghiêm trọng. Bất chấp cảnh báo đó, người bảo trì chính của vLLM đã ép buộc hợp nhất (force-merge) PR này và viết rằng:

Thật không may, việc phân tích một chuỗi token tùy ý thành một cuộc trò chuyện hoàn chỉnh (với lượt người dùng, phản hồi của trợ lý, các lệnh gọi công cụ, v.v.) không hề đơn giản, và quy trình chính xác thường khác nhau giữa các LLM. Sự phức tạp này tạo ra nhiều cơ hội hơn cho các lỗi có thể cho phép thực thi mã tùy ý trên máy chủ.

vLLM và SGLang rất phức tạp, và các lỗi là điều phổ biến.

Các công cụ suy luận hiện đại làm được nhiều việc hơn là chỉ ánh xạ chuỗi token sang chuỗi ký tự. Tài liệu của vLLM liệt kê hỗ trợ cho hơn 200 kiến trúc mô hình, và thư mục ví dụ của nó chứa khoảng 35 mẫu trò chuyện Jinja. Các công cụ suy luận hiện đại phân tích nhiều định dạng trò chuyện, và logic phân tích được chỉ định sai lệch một chút sẽ dẫn đến việc đầu ra của LLM bị hiểu nhầm thành mã cần thực thi.

Trong vấn đề này của vLLM, một người dùng đã thảo luận về cách các LLM suy luận với MiniMax-M3, và LLM đã phát ra chuỗi <mm:think>. vLLM đã phân tích nhầm chuỗi thuần túy này thành phần bắt đầu của một khối suy luận. Vì vậy, thay vì:

Phản hồi: Tôi sẽ lặp lại chính xác những gì bạn đã nói: <mm:think>\nĐấy, như vậy được chưa?

vLLM đã phân tích thành:

Phản hồi: Tôi sẽ lặp lại chính xác những gì bạn đã nói:

Suy luận: \nĐấy, như vậy được chưa?

Đây là một lỗi trình phân tích cú pháp khá vô hại, nhưng nó chứng minh rằng các công cụ suy luận làm được nhiều việc hơn là chỉ chuyển đổi token thành chuỗi ký tự và nối chúng lại. Chúng là những hệ thống phức tạp đang được lặp lại liên tục và các nhà phát triển của chúng đang chịu áp lực lớn để làm cho chúng nhanh nhất có thể. Những yếu tố này làm tăng nguy cơ một LLM độc hại có thể biến một lỗi trình phân tích cú pháp thành việc thực thi mã tùy ý trên máy chủ suy luận.

Các token hình ảnh và âm thanh có thể làm tăng bề mặt tấn công.

Các kiến trúc đa phương thức (multimodal) cho phép LLM phản hồi bằng hình ảnh hoặc âm thanh cũng như văn bản thuần túy. Việc chuyển đổi đầu ra âm thanh hoặc hình ảnh của mô hình thành phương tiện có thể sử dụng được có lẽ phức tạp hơn việc giải mã các token văn bản. Tuy nhiên, theo những gì tôi có thể thấy, các LLM đa phương thức hiện nay thường phát ra các token phương tiện bị giới hạn thay vì các byte tệp tùy ý. Một bộ giải mã dành riêng cho mô hình sẽ biến các token đó thành pixel hoặc dạng sóng, sau đó được mã hóa thành tệp. Điều này làm cho các kiểu khai thác tệp bị lỗi cổ điển nhắm vào phần mềm như ffmpeg hoặc trình xem phương tiện ít trực tiếp hơn đối với mô hình, mặc dù các bộ giải mã, bộ mã hóa và nhân gốc bổ sung vẫn làm tăng bề mặt tấn công.

Hiện tại, tôi không coi đầu ra đa phương thức là con đường chính để xâm nhập máy chủ. Tuy nhiên, nó cung cấp băng thông cao hơn nhiều so với chỉ văn bản, và các công cụ suy luận trong tương lai có thể tối ưu hóa các con đường tạo phương tiện này theo những cách khiến chúng dễ bị khai thác hơn. Tôi cũng không biết các mô hình đa phương thức độc quyền thể hiện đầu ra hình ảnh và âm thanh như thế nào; các phương pháp của chúng có thể mang những rủi ro khác nhau.

Khả năng một LLM phát hiện và khai thác các lỗ hổng của công cụ suy luận là bao nhiêu?

Có khả năng không? Tôi không chắc. Việc phát hiện ra một lỗ hổng hữu ích có lẽ là bước khó khăn hơn. Chuỗi token cần thiết để khai thác nó có thể khá bất thường, nhưng điều đó không làm cho lỗ hổng trở nên không thể khai thác được. Với bối cảnh phù hợp (ví dụ: một LLM khám phá cơ sở mã vLLM và phát hiện ra một lỗ hổng trong quá trình này), tôi kỳ vọng một LLM tiên tiến có thể phát ra các token cần thiết để khai thác nó.

Việc sử dụng công cụ có thể làm cho quá trình khai thác có khả năng tái lập.

Khi một LLM phát hiện ra một chuỗi token khai thác, nó có thể lưu trữ chuỗi đó, hoặc các hướng dẫn để tạo lại nó, trong các tệp, tên tệp hoặc URL có khả năng đi vào ngữ cảnh của một LLM khác. Cuộc khai thác sau đó sẽ hoạt động như một dạng tiêm câu lệnh (prompt injection) bền vững: một tác nhân có thể kích hoạt việc thực thi mã trên máy chủ GPU chỉ bằng cách liệt kê một thư mục hoặc đọc một tệp.

Các công cụ suy luận là mục tiêu hấp dẫn đối với các LLM có tham vọng quyền lực.

Tôi tin (hy vọng) rằng OpenAI, Google và Anthropic có các đội ngũ bảo mật thực hiện kiểm thử xâm nhập (red-team) đối với phần mềm mà họ chạy nội bộ. Nhưng khi các LLM mã nguồn mở (open-weight) trở nên mạnh mẽ hơn, chúng ta sẽ có nhiều LLM chạy trên các công cụ suy luận tiên tiến vốn ít được giám sát hơn. Điều này làm tăng khả năng một LLM mã nguồn mở độc hại sẽ gặp phải và khai thác một công cụ suy luận dễ bị tổn thương.

Một vectơ tấn công khác có thể xuất hiện khi các LLM ngày càng được giao nhiệm vụ viết hoặc sửa đổi các công cụ suy luận chạy chúng, thường là để cải thiện hiệu suất. Một LLM độc hại có thể sử dụng quyền truy cập đó để cài cắm một cửa sau (backdoor). Các thành phần C++ và CUDA của quy trình suy luận dường như là những mục tiêu đặc biệt hấp dẫn: LLM có thể giới thiệu một lỗ hổng truy cập bộ nhớ ngoài giới hạn (out-of-bounds memory-access) cho phép thực thi mã tùy ý trên GPU hoặc trên máy chủ CPU điều khiển chúng.

Làm thế nào để chúng ta phòng thủ trước điều này?

Ngoài việc kiểm thử xâm nhập các công cụ suy luận để tìm lỗ hổng, một vài biện pháp khác có thể hữu ích: