การโจมตีระบบ UNIX ผ่าน CUPS

 (evilsocket.net)
1 คะแนน โดย GN⁺ 2024-09-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หาก เส้นทางการค้นพบเครื่องพิมพ์อัตโนมัติ ของ CUPS ทำงานร่วมกับการขาดการตรวจสอบคุณสมบัติ IPP ผู้โจมตีจากระยะไกลที่ไม่ต้องยืนยันตัวตนสามารถฉีดการตั้งค่าเครื่องพิมพ์อันตราย และนำไปสู่การรันคำสั่งตามอำเภอใจเมื่อมีการพิมพ์ได้
  • จุดเริ่มของการโจมตีคือพฤติกรรมที่ cups-browsed รับแพ็กเก็ตจากแหล่งใดก็ได้บน พอร์ต UDP 631 แล้วส่งคำขอ Get-Printer-Attributes ของ IPP ไปยัง URL ของผู้โจมตี
  • ช่องโหว่ถูกแบ่งเป็น CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, CVE-2024-47177 และเชื่อมต่อกันไปถึงการสร้าง PPD ใน libcupsfilters, libppd, cups-filters และลำดับการทำงานของ foomatic-rip
  • ขอบเขตผลกระทบครอบคลุมดิสทริบิวชัน GNU/Linux ส่วนใหญ่, BSD บางส่วน, Oracle Solaris และอาจรวมถึง Chromium/ChromeOS โดยจากการสแกน IPv4 สาธารณะพบการ callback จากอุปกรณ์หลายแสนเครื่อง และมี ไคลเอนต์พร้อมกันสูงสุด 200,000~300,000 เครื่อง
  • ในทางปฏิบัติ ควรปิดใช้งานหรือลบ cups-browsed หากไม่จำเป็น และอัปเดตแพ็กเกจ CUPS; หากอัปเดตได้ยาก ควรพิจารณาบล็อก UDP 631 และทราฟฟิก DNS-SD หากจำเป็น

แกนหลักของห่วงโซ่ช่องโหว่

  • ห่วงโซ่นี้เริ่มจากความสามารถในการค้นพบเครื่องพิมพ์อัตโนมัติของ CUPS แล้วต่อเนื่องไปยังการประมวลผลคุณสมบัติ IPP, การสร้างไฟล์ PPD และการรันฟิลเตอร์
  • ช่องโหว่หลักเชื่อมกันเป็นสี่ขั้นตอน
    • CVE-2024-47176: cups-browsed 2.0.1 และต่ำกว่า bind กับ UDP INADDR_ANY:631 และเชื่อถือแพ็กเก็ตจากแหล่งใดก็ได้ จึงกระตุ้นคำขอ IPP Get-Printer-Attributes ไปยัง URL ที่ผู้โจมตีควบคุม
    • CVE-2024-47076: cfGetPrinterAttributes5 ใน libcupsfilters 2.1b1 และต่ำกว่า ส่งต่อคุณสมบัติที่ได้รับจากเซิร์ฟเวอร์ IPP ไปยังระบบ CUPS โดยไม่ตรวจสอบหรือทำความสะอาด
    • CVE-2024-47175: ppdCreatePPDFromIPP2 ใน libppd 2.1b1 และต่ำกว่า เขียนคุณสมบัติ IPP ลงในไฟล์ PPD ชั่วคราวโดยไม่ตรวจสอบหรือทำความสะอาด เปิดทางให้แทรกข้อมูลที่ผู้โจมตีควบคุม
    • CVE-2024-47177: foomatic-rip ใน cups-filters 2.0.1 และต่ำกว่า อนุญาตให้รันคำสั่งตามอำเภอใจผ่านพารามิเตอร์ FoomaticRIPCommandLine ใน PPD

จุดเริ่มการโจมตีและขอบเขตผลกระทบ

  • ผู้โจมตีจากระยะไกลที่ไม่ต้องยืนยันตัวตนสามารถเปลี่ยน URL IPP ของเครื่องพิมพ์เดิมไปเป็น URL อันตรายแบบเงียบ ๆ หรือทำให้มีการติดตั้งเครื่องพิมพ์ใหม่
  • การรันคำสั่งจริงจะเกิดขึ้นเมื่อ เริ่มงานพิมพ์ บนเครื่องนั้น
  • จุดเริ่มมีสองแบบ
    • WAN / อินเทอร์เน็ตสาธารณะ: ผู้โจมตีจากระยะไกลส่งแพ็กเก็ตไปยังพอร์ต UDP 631 โดยไม่ต้องยืนยันตัวตน
    • LAN: ผู้โจมตีภายในเครือข่ายสามารถ spoof โฆษณา zeroconf, mDNS, DNS-SD เพื่อไปถึง RCE ผ่านเส้นทางโค้ดเดียวกัน
  • CUPS และ cups-browsed ถูกแพ็กเกจอยู่ในระบบตระกูล UNIX หลายแบบ
  • จากการสแกนช่วง IPv4 อินเทอร์เน็ตสาธารณะทั้งหมดหลายครั้งต่อวันเป็นเวลาหลายสัปดาห์ หลังส่งแพ็กเก็ต UDP พบอุปกรณ์ หลายแสนเครื่อง callback กลับมา และมีจุดพีกที่ ไคลเอนต์พร้อมกัน 200,000~300,000 เครื่อง

เส้นทางที่ cups-browsed เปิดทิ้งไว้

  • ระหว่างรัน netstat -anu บนโน้ตบุ๊ก Ubuntu พบพอร์ต UDP ที่รับฟังอยู่บน 0.0.0.0:631
  • เมื่อตรวจด้วย lsof -i :631 พบว่า TCP 631 ถูกใช้โดย cupsd ส่วน UDP 631 ถูกใช้โดย cups-browsed
  • ใน ps aux พบว่าโปรเซส cups-browsed ทำงานด้วยสิทธิ์ root
  • cups-browsed เป็นส่วนหนึ่งของระบบ CUPS ทำหน้าที่ค้นพบเครื่องพิมพ์ใหม่และ เพิ่มเข้าไปในระบบโดยอัตโนมัติ
  • จากการตรวจโค้ดต้นฉบับ พบว่าบริการ bind อยู่กับ INADDR_ANY:631 UDP และคาดหวังแพ็กเก็ต UDP ในรูปแบบ HEX_NUMBER HEX_NUMBER TEXT_DATA
  • เมื่อไฟล์ตั้งค่าปริยายส่วนใหญ่ถูกคอมเมนต์ไว้ ข้อจำกัดการเข้าถึงจึงแทบอ่อนแอมากในทางปฏิบัติ

ปัญหาการพาร์สและบั๊กเพิ่มเติม

  • แม้แพ็กเกจ CUPS เองจะรวมอยู่ใน oss-fuzz แต่ cups-browsed ดูเหมือนจะไม่มี fuzzing coverage
  • เมื่อสร้างเป้าหมาย fuzzing แบบ AFL รอบ ๆ process_browse_data ก็พบอินพุต 5 แบบที่กระตุ้น stack-buffer-overflow
  • สาเหตุที่ชี้ไว้คือโฟลว์ที่มีการ dereference pointer ก่อนตรวจเงื่อนไขสิ้นสุดในสองลูป
  • ต่อมายังพบ race condition และ DoS ที่เป็นไปได้ตรงจุดจัดการ lock
  • ปัญหาเหล่านี้ถูกรายงานไปยังนักพัฒนาและ CERT แล้ว แต่ตามเกณฑ์ของผู้วิจัยยังไม่ได้รับการยอมรับหรือแพตช์

คำขอ IPP และการฉีด PPD

  • found_cups_printer ใช้หนึ่งในฟิลด์ข้อความที่พาร์สมาจากแพ็กเก็ต UDP เป็น URL
  • URL นี้และข้อมูลที่เกี่ยวข้องจะผ่านโฟลว์ examine_discovered_printer_record, create_remote_printer_entry และไปสู่การเรียก cfGetPrinterAttributes ของ libcupsfilters
  • หากผู้โจมตีส่งแพ็กเก็ตในรูปแบบ 0 3 http://<ATTACKER-IP>:<PORT>/printers/whatever เครื่องเป้าหมายที่รัน cups-browsed จะเชื่อมต่อไปยัง URL ของผู้โจมตี
  • ระหว่างเชื่อมต่อ เฮดเดอร์ User-Agent มีเวอร์ชันเคอร์เนลและสถาปัตยกรรมรวมอยู่ด้วย และในบางคำขอมีรายงานชื่อผู้ใช้ของเป้าหมายด้วย
  • Internet Printing Protocol เป็นโปรโตคอลสื่อสารระหว่างไคลเอนต์กับเครื่องพิมพ์หรือพรินต์เซิร์ฟเวอร์ ใช้สำหรับตรวจสอบสถานะเครื่องพิมพ์และส่งงานพิมพ์ เป็นต้น
  • ระบบเป้าหมายจะมองเซิร์ฟเวอร์ของผู้โจมตีเป็นเครื่องพิมพ์ และส่งคำขอ Get-Printer-Attributes ที่ห่ออยู่ภายใน HTTP
  • เมื่อใช้ ippserver python package เพื่อตอบกลับด้วยคุณสมบัติที่ควบคุมได้ เครื่องพิมพ์ปลอมก็ถูกเพิ่มเข้าเป็นเครื่องพิมพ์ภายในเครื่องโดยไม่มีการแจ้งเตือนผู้ใช้

PPD และเส้นทางการรัน foomatic-rip

  • ใน debug log แสดงให้เห็นกระบวนการสร้างคิวเครื่องพิมพ์, สร้างไฟล์ PPD ชั่วคราว, และการใช้งานกับการแก้ไข PPD
  • ฟังก์ชัน create_queue ส่งต่อคุณสมบัติ IPP ไปยัง API ppdCreatePPDFromIPP2 ของ libppd
  • ppdCreatePPDFromIPP2 เขียนคุณสมบัติข้อความที่ผู้โจมตีควบคุม เช่น printer-make-and-model ลงในไฟล์ PPD โดยไม่ตรวจสอบหรือ escape
  • ไฟล์ PostScript Printer Description เป็นไฟล์ข้อความที่อธิบายความสามารถและคุณลักษณะของเครื่องพิมพ์ และใน CUPS ใช้กำหนดความสามารถของเครื่องพิมพ์และวิธีใช้งาน
  • ในบรรดาคำสั่งต่าง ๆ ของ PPD นั้น cupsFilter2 ซึ่งเป็นส่วนขยายของ CUPS สามารถรันไฟล์ปฏิบัติการใต้ /usr/lib/cups/filter เป็นฟิลเตอร์ระหว่างงานพิมพ์ได้
  • foomatic-rip ถูกจัดเป็นฟิลเตอร์ที่สามารถรันคำสั่งได้ผ่านคำสั่ง FoomaticRIPCommandLine ใน PPD
  • ในอดีต foomatic-filters เคยมีการแก้ไขที่เกี่ยวข้องกับ CVE-2011-2964 และ CVE-2011-2697 แต่ยืนยันว่าระหว่างการรวมเข้ากับ CUPS การแก้ไขดังกล่าวไม่ได้ถูกพอร์ตมาด้วย
  • ใน CVE-2024-35235 ที่ใหม่กว่านี้ ก็มีการกล่าวถึงการรันคำสั่งตามอำเภอใจผ่าน FoomaticRIPCommandLine เช่นกัน
  • ตามคำอธิบายจากฝั่งนักพัฒนา CUPS การจำกัดสิ่งที่ใส่ใน FoomaticRIPCommandLine ได้เป็นเรื่องยากมากหากไม่ทำให้ไดรเวอร์เดิมพัง และมีความเป็นไปได้ว่าเครื่องพิมพ์เก่าหลายร้อยรุ่นก่อนปี 2010 จะพึ่งพา Foomatic เพียงอย่างเดียว

ลำดับการทำซ้ำ RCE

  • ห่วงโซ่ RCE ประกอบด้วยสามขั้นตอน
    • ทำให้ระบบเป้าหมายเชื่อมต่อไปยังเซิร์ฟเวอร์ IPP อันตรายของผู้โจมตี
    • ตอบกลับด้วยสตริงคุณสมบัติ IPP ที่ผู้โจมตีควบคุม เพื่อแทรกคำสั่งลงในไฟล์ PPD ชั่วคราว
    • เมื่อมีการส่งงานพิมพ์ไปยังเครื่องพิมพ์ปลอม คำสั่งและคำสั่งกำกับใน PPD ก็จะถูกรัน
  • ในการตั้งค่าเซิร์ฟเวอร์ IPP การรันคำสั่งถูกจัดขึ้นด้วยวิธีปิดสตริง PPD แล้วแทรกบรรทัดใหม่ จากนั้นใส่คำสั่ง FoomaticRIPCommandLine และ cupsFilter2
  • เป้าหมายเดโมคือ Ubuntu 24.04.1 LTS ที่แพตช์ครบแล้วกับ cups-browsed 2.0.1 และสามารถทำให้เกิดการรันคำสั่งจากเครื่องของผู้โจมตีได้
  • โฟลว์นี้จะเกิดขึ้นได้เมื่อหลายขั้นตอนประมวลผลใน cups-browsed, libcupsfilters, libppd, cups-filters ทำงานเชื่อมต่อกัน

การบรรเทาและคำแนะนำ

  • หากไม่จำเป็นต้องใช้ cups-browsed แนะนำให้ปิดบริการและลบออก
  • ควรอัปเดตแพ็กเกจ CUPS ของระบบ
  • หากอัปเดตไม่ได้และยังต้องใช้บริการดังกล่าว ควรบล็อกทราฟฟิก UDP 631
  • ตามสถานการณ์ อาจบล็อกทราฟฟิก DNS-SD ได้ด้วย แต่ในสภาพแวดล้อมที่ใช้ zeroconf อาจนำไปใช้ได้ยาก
  • ผู้วิจัยระบุเป็นคำแนะนำส่วนตัวว่าจะลบบริการ, ไบนารี และไลบรารีของ CUPS ออกจากระบบของตนเอง และจะไม่พิมพ์ไปยังระบบ UNIX
  • พร้อมเสริมว่าจะลบ listener ของ zeroconf, Avahi และ Bonjour ด้วย

กระบวนการเปิดเผยและงานต่อเนื่อง

  • แม้งานวิจัยเองจะใช้เวลาเพียงไม่กี่วัน แต่หลังจากเปิด security advisory ในรีโพซิทอรี OpenPrinting cups-browsed เมื่อวันที่ 5 กันยายนและเริ่มกระบวนการเปิดเผยอย่างรับผิดชอบ ก็ใช้เวลา 22 วันกว่าจะเปิดเผยสู่สาธารณะ
  • การหารือที่เกี่ยวข้องขยายไปสู่ security advisory ของ cups-browsed, libcupsfilters, libppd, cups-filters
  • งานวิจัยใช้เวลา 2 วัน ส่วน exploit ที่ใช้งานได้จริงมี 249 บรรทัด และในกระบวนการเปิดเผยมีทั้งการโต้เถียง อีเมล ข้อความ และข้อความรวมกันมากกว่า 100 หน้า
  • เกี่ยวกับข้อถกเถียงเรื่องคะแนน CVSS 9.9 มีคำอธิบายว่าคะแนน 9.9 เริ่มต้นนั้นเป็นค่าที่วิศวกร RedHat ประเมินในรายงาน VINCE และมีวิศวกรอีกคนทบทวน
  • ผู้วิจัยมองว่า RCE นี้ถูกนำไปใช้โจมตีได้ง่ายและแพ็กเกจมีอยู่กว้างขวาง จึงน่าจะเป็นเหตุผลที่ได้ 9.9 ในตอนแรก แต่ก็เสริมว่าในมุมผลกระทบตนเองคงไม่จัดเป็น 9.9
  • มีการเปิดเผยว่ารายงาน Markdown และ exploit ฉบับเต็มที่แชร์ให้เฉพาะ CERT VINCE เท่านั้นได้รั่วไหลออกมา
  • exploit.py เวอร์ชันแรกทำเพียงส่งแพ็กเก็ต UDP และสร้างเซิร์ฟเวอร์ IPP อันตราย แต่ต่อมาได้เพิ่มความสามารถโฆษณา zeroconf จนกลายเป็นเครื่องมือ
  • หลังจากนั้นมีการเขียนใหม่ด้วย Go และรวมเข้ากับ bettercap โดยเพิ่มความสามารถปลอมแปลงบริการที่ถูกโฆษณาผ่าน zeroconf, Bonjour, Avahi บน LAN แบบโปร่งใส รวมถึงการจัดการที่เกี่ยวข้องกับ IPP
  • ในบทความถัดไป ผู้วิจัยวางแผนจะพูดถึงการโจมตี Apple macOS ด้วยโมดูล bettercap ที่ยังไม่เปิดเผย แต่กำหนดการยังไม่แน่นอนเพราะติดขั้นตอนการเปิดเผยอื่น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-09-27
ความคิดเห็นจาก Hacker News

  • ตอนแรกนึกว่านี่เป็นมุกเสียอีก เนื้อหาคือ “ผู้โจมตีจากระยะไกลที่ไม่ต้องยืนยันตัวตนสามารถเปลี่ยน IPP URL ของเครื่องพิมพ์ที่มีอยู่ให้เป็น URL อันตราย หรือเพิ่มเครื่องพิมพ์ใหม่ เพื่อให้รันคำสั่งตามอำเภอใจได้เมื่อมีการเริ่มงานพิมพ์บนคอมพิวเตอร์นั้น” แต่ Heartbleed ได้ 7.5 ดังนั้นอันนี้ดูไม่น่าใช่ 9.9
    ทวีตต้นฉบับบอกว่าเป็น “remote code execution แบบไม่ต้องยืนยันตัวตนต่อทุกระบบ GNU/Linux” แต่ในความเป็นจริง หลายดิสโทร bind CUPS ไว้แค่ loopback หรือไม่ได้ติดตั้งมาเลย
    อีกทั้งมีการอ้างว่าสแกน IPv4 สาธารณะทั้งหมดวันละหลายครั้งเป็นเวลาหลายสัปดาห์แล้วได้รับ callback จากอุปกรณ์หลายแสนตัว ถ้าผมเข้าใจไม่ผิด นั่นแปลว่ามี CUPS instance ที่เปิดอยู่บน IPv4 สาธารณะทั้งหมดราว 300,000 ตัว และการ remote code execution จะเกิดขึ้นก็ต่อเมื่อ CUPS server นั้นได้รับงานพิมพ์ ซึ่งส่วนใหญ่คงไม่เกิดขึ้น

    • ถ้าอ่านเนื้อหาดี ๆ ก็ยอมรับว่าแย่อยู่พอสมควร แต่ประเด็นน่าจะใกล้กับว่า cups-browsed daemon ควรถูกเลิกใช้ไปได้แล้ว และ Linux ecosystem ควรคุยกันจริงจังเรื่องอนาคตของ CUPS มากกว่า
      บั๊กเหล่านี้ดูง่ายจนน่าตกใจ และท้ายที่สุดก็เป็นปัญหาความปลอดภัยที่ค่อนข้างร้ายแรง ซึ่งไม่ใช่ระดับการรับมือจาก upstream ที่ควรคาดหวังได้สำหรับแพ็กเกจเดสก์ท็อป Linux ที่ติดตั้งมาเป็นค่าเริ่มต้น
      ถึงอย่างนั้นก็ยังไม่ถึงขั้น CVSS 9.9 แบบตื่นตระหนกทั้งโลกหยุดหมุน แน่นอน
    • เพื่อความเป็นธรรม ผู้เขียนก็พูดไว้ว่า “ถ้าวัดตามผลกระทบ ผมก็คงไม่จัดมันเป็น 9.9 หรอก แต่จริง ๆ แล้วผมจะไปรู้อะไร”
    • ยังมี buffer overflow ที่โจมตีได้โดยไม่ต้องมีการกระทำจากผู้ใช้ด้วย เส้นทาง foomatic ที่ต้องอาศัยงานพิมพ์เป็นเพียงหนึ่งในวิธีที่สแกนหาและนำไปโจมตีได้ง่ายที่สุด
    • ผมหัวเราะดังมากกับมีม “Look at me, I'm the printer now” ไม่ว่าจะให้คะแนนความร้ายแรงอย่างไร อย่างน้อยก็ได้มุกดี ๆ มาหนึ่งอัน
    • Heartbleed เป็นการรั่วของหน่วยความจำ แต่อันนี้คือ remote code execution เต็มรูปแบบ โดยไม่ต้องมีการกระทำจากผู้ใช้ ซึ่งแน่นอนว่า remote code execution หมายถึงการเปิดเผยข้อมูลทั้งหมดและอะไรที่มากกว่านั้น
      ให้แม่นยำกว่านั้น โครงสร้างคือเมื่อผู้ใช้พิมพ์งานไปยังเครื่องพิมพ์ของตัวเองครั้งถัดไป ระบบจะไปรันค่าตั้งค่าเครื่องพิมพ์ที่ผู้โจมตีแก้ไว้ล่วงหน้า และช่องโหว่นี้ไม่ได้อยู่ที่ cupsd แต่เป็น cupsd-browser
      อาจจะมีปัญหาเรื่องท่าทีของผู้เขียน แต่ตัวช่องโหว่นี้เองถือว่าเป็นเรื่องใหญ่จริง

  • ใครก็ตามที่เปิด CUPS ออกสู่อินเทอร์เน็ต ก็คงอยู่ในระดับที่ไม่ใส่ใจอะไรเลยจน CVE เอื้อมไม่ถึงแล้ว

    • ดูเหมือนบริการที่มีปัญหาจะรับฟังอยู่บน 0.0.0.0 ซึ่งน่ากังวล นั่นหมายความว่าโดยปกติแล้วเสี่ยงต่อการโจมตีจากใน LAN และถ้า server เปิดสู่อินเทอร์เน็ต ก็แปลว่าต้องบล็อกพอร์ต 631 ไว้อย่างชัดเจน
      แน่นอนว่าต้องให้ผู้ใช้สั่งพิมพ์อะไรบางอย่างก่อนถึงจะ trigger ได้ และโดยส่วนตัวแล้วผมแทบจำไม่ได้เลยว่าเคยพิมพ์อะไรบน Linux แต่คำกล่าวอ้างว่าได้รับ callback จากเครื่อง Linux หลายแสนเครื่องก็ดูสมเหตุสมผล
    • ในกรณีนี้ คำว่า “เปิด CUPS สู่อินเทอร์เน็ต” ฟังดูเหมือนหมายถึง “ใช้งาน Linux desktop ที่ต่ออินเทอร์เน็ต” ผมคงไม่ทำเอง แต่ก็ไม่ถึงขั้นบ้าคลั่ง และทำให้น่าคาดหวังว่าการติดตั้ง Debian desktop แบบค่าเริ่มต้น ควรปลอดภัยพอแม้ไม่มีไฟร์วอลล์
      อย่างน้อยผมคิดว่า Linux laptop ไม่ควรเปราะบางต่ออุปกรณ์อื่นทั้งหมดอย่างหนักเมื่ออยู่บนเครือข่ายอย่าง Wi‑Fi สนามบิน
    • ใครก็ตามที่ไปนั่งคาเฟ่แล้วใช้ Wi‑Fi สาธารณะ ก็เท่ากับกำลังเปิด CUPS และอาจถูกโจมตีได้ การปัดทิ้งแบบง่าย ๆ ไม่ได้ช่วยใครเลย
    • น่าเหลือเชื่อที่ CUPS ไม่ได้รันเป็นโปรแกรมผู้ใช้ที่ถูก sandbox อย่างเข้มงวด แต่รันเป็น system daemon
    • อย่างไรก็ตาม นี่ก็ยังเป็นชัยชนะเต็ม ๆ สำหรับ การเคลื่อนที่ด้านข้าง และการยกระดับสิทธิ์

  • หากตีความตัวชี้วัด Scope ของ CVSSv3 ต่างกันไป ตัวเลขที่แม่นกว่าน่าจะเป็น 8.8 หรือ 9.6
    สรุปคือ บนเดสก์ท็อป Linux บางสายพันธุ์ CUPS ที่เปิดให้เห็นบน LAN กำลังฟังอยู่ที่ 0.0.0.0, รันด้วยสิทธิ์ root และมีช่องโหว่ remote code execution แบบไม่ต้องยืนยันตัวตน แม้บน Linux สาย server อย่าง Ubuntu Server หรือ CentOS ส่วนใหญ่จะไม่ใช่บริการค่าเริ่มต้น แต่บน Linux สายเดสก์ท็อปส่วนใหญ่ดูเหมือนจะเริ่มทำงานมาให้โดยปริยาย
    การ trigger ให้ remote code execution เกิดขึ้น ต้องอาศัยให้ผู้ใช้ของเครื่อง Linux ที่เปราะบางนั้นสั่งพิมพ์เอกสารหลังจากถูกโจมตีแล้ว
    evilsocket บอกว่าได้รับ callback หลายแสนครั้ง และถึงพวกเราส่วนใหญ่แทบไม่เคยพิมพ์อะไรบน Linux เลย ผลกระทบระดับนั้นก็น่าจะเพียงพอสำหรับการสร้าง botnet ขนาดใหญ่ได้

    • ในมหาวิทยาลัยมีคนจำนวนมากที่ใช้ Linux desktop ที่มี public IP และพิมพ์งานอยู่ตลอด ไม่ว่าจะเป็นงานวิจัย งานเขียนของตัวเอง หรือของคนอื่น
    • ส่วนแบ่งเดสก์ท็อป Linux แม้ไม่นับ ChromeOS ก็ยังอยู่ราว 4.5% ต่อให้พวกเราส่วนใหญ่ไม่พิมพ์ งานพิมพ์ที่ส่งออกจากโฮสต์ Linux ก็ยังมีอยู่มากพอสมควร
    • Heartbleed ได้ 7.5 และต่ำกว่าเหตุการณ์ xz แค่ 0.4 เอง ผมเลยไม่เข้าใจว่าอันนี้จะเป็น 9.6 ได้อย่างไร

  • ผมเปิด cupsd สู่อินเทอร์เน็ตอยู่ พอได้ยินข่าวก็แอบตื่นตกใจนิดหน่อย แต่เหมือนที่หัวข้อนี้บอก ประเด็นนี้ก็มีส่วนที่สื่อสารผิดไปเช่นกัน ปัญหาไม่ได้อยู่ที่ cupsd แกนหลัก แต่เป็นแพ็กเกจ/คอมโพเนนต์แยกต่างหากชื่อ cups-browsed
    Gentoo Linux ที่ผมใช้เป็น server แยก cups-browsed เป็นคนละแพ็กเกจ และผมไม่ได้ติดตั้ง จึงไม่ได้รับผลกระทบ ผู้ใช้ CUPS ส่วนใหญ่ที่ไม่ได้ติดตั้งแพ็กเกจเสริมนี้ก็ไม่ได้รับผลจากบั๊กนี้เช่นกัน
    การพูดว่าทุกระบบที่รัน CUPS สามารถถูกแฮ็กได้ เป็นการอธิบายขนาดของปัญหาผิดไป

    • แม้ Debian จะค่อนข้างอนุรักษนิยม แต่ผมก็ไม่เคยชอบเลยที่พอติดตั้ง cups แล้วมักจะมี cups-browsed ติดมาด้วยโดยปริยาย ดูเหมือนจะแก้ได้ด้วย “no install recommends” แต่ถ้าจำไม่ผิด พวกไดรเวอร์เสริมอย่าง hplip ก็อาจดึงมันกลับเข้ามาอีก
      ที่บ้านผมแค่ปิดบริการนี้ไป แต่ยิ่งเจอซอฟต์แวร์มากขึ้นที่ขยายขอบเขตตัวเองจนทำให้คอมโพเนนต์ที่ควรเป็นทางเลือก กลายเป็นเหมือนของจำเป็น ก็ยิ่งน่าหงุดหงิดมาก
      อีกตัวอย่างที่คล้ายกันคือ avahi-daemon ถ้าลองพยายามลบมันออกบน Debian/Ubuntu แบบเดสก์ท็อป ก็มีโอกาสสูงที่จะลบซอฟต์แวร์อื่นที่ทำให้งงตามไปด้วย ทั้งที่สงสัยว่าเหตุใด avahi ถึงต้องเป็น dependency แบบเข้มขนาดนั้น

  • เข้าใจประเด็นที่ว่า “นักวิจัยถูกคาดหวังและถูกมองเป็นเรื่องปกติมากเกินไป เพราะมี triager ที่ทำตัวราวกับว่า ‘คุณในฐานะนักวิจัยด้านความปลอดภัยต้องพิสูจน์ให้ได้ว่าสิ่งนี้คุ้มค่าที่จะรับฟัง’” แต่ก็มีความจริงที่น่าเศร้าอยู่อีกด้าน
    สำหรับรายงานที่ศึกษามาอย่างดีแบบนี้ 1 ฉบับ จะมีรายงานสแปมคุณภาพต่ำราว 57 ฉบับที่ส่งเข้ามาเพื่อพยายามรีดรางวัล bug bounty หรือเอา CVE discovery ไปใส่ในเรซูเม่ โดยเฉพาะเมื่อ LLM เพิ่มจำนวนขึ้น สแปมแบบนั้นก็หลอกคนได้ง่ายขึ้น
    เป็นสถานการณ์ที่น่าเศร้า แต่ก็โทษนักพัฒนาเต็ม ๆ ไม่ได้ที่พวกเขาจะมีท่าทีระแวง

  • สรุปคือ cups-browsed ฟังบนพอร์ต UDP 631 และสามารถติดตั้งเครื่องพิมพ์อัตโนมัติได้โดยไม่ต้องให้ผู้ใช้ยืนยัน
    ผู้โจมตีสามารถใช้ “ฟีเจอร์” นี้เพื่อติดตั้งเครื่องพิมพ์ปลอมที่แนบไดรเวอร์แบบกำหนดเองซึ่งดาวน์โหลดได้จากโฮสต์ใดก็ได้ โดยไม่ต้องให้ผู้ใช้ยืนยัน และระบุคำสั่งที่จะรันเมื่อมีการส่งงานพิมพ์
    ถ้าผู้ใช้พิมพ์อะไรสักอย่างไปยังเครื่องพิมพ์ปลอมนั้น คำสั่งดังกล่าวก็จะถูกเรียกใช้งาน

    • CUPS ถูกนำมาใช้ตั้งแต่ปี 1999 ดังนั้นในตอนนั้นการติดตั้งอัตโนมัติโดยไม่ต้องยืนยันจากผู้ใช้อาจฟังดูสมเหตุสมผลก็ได้ แต่ไม่เข้าใจว่าทำไมถึงยังคงอยู่มาจนถึงตอนนี้

  • ในกรณีนี้ดูเหมือนดิสโทรต่าง ๆ จะใส่ cups-browsed มาเป็นฟีเจอร์ แต่รู้สึกมาตลอดว่า Ubuntu/Debian และน่าจะรวมถึงดิสโทรที่อิง deb เกือบทั้งหมด ที่มักเปิดบริการแทบทุกอย่างอัตโนมัติระหว่างติดตั้ง เป็นเรื่องที่ไม่ดีเสมอ
    มันหมายความว่าแค่ติดตั้งแพ็กเกจหนึ่งตัว ก็อาจเผลอเปิดบริการเครือข่ายอื่นที่ถูกติดตั้งมาเป็น dependency ได้
    exim4 หลายคนคงรู้อยู่แล้ว แต่พูดกันอย่างยุติธรรม ค่าปริยายของมันฟังแค่ localhost จึงอาจไม่ใช่ปัญหาใหญ่มาก ผมเพิ่งลองติดตั้ง cups-browsed บนเครื่อง Debian เครื่องหนึ่ง แล้วพบว่ามีบริการ 2 ตัวที่ฟังบน 0.0.0.0 (cups-browsed กับ avahi) ถูกเปิดขึ้นมา
    บนดิสโทรสาย Arch/Gentoo และ CentOS ไม่เป็นแบบนี้

  • คะแนน CVSS ดั้งเดิมที่โพสต์บน Twitter ระบุว่าไม่ต้องมีการโต้ตอบจากผู้ใช้ แต่พออ่านเชน remote code execution ในหน้านั้น กลับบอกว่า “รอให้งานพิมพ์ถูกส่งไปยังเครื่องพิมพ์ปลอม เพื่อให้ PPD directive และคำสั่งที่ตามมาถูกเรียกใช้”
    ถ้า Alice ไม่กดปุ่มพิมพ์ ก็ดูเหมือนว่างานพิมพ์จะไม่ถูกทริกเกอร์ เลยสงสัยว่าผมพลาดอะไรไปหรือเปล่า ไม่ได้กำลังสงสัย evilsocket แต่อยากเช็กความเข้าใจของตัวเอง

    • ยังมี buffer overflow ที่หาเจอด้วย fuzzer ซึ่งอาจนำไปสู่ remote code execution ได้โดยไม่ต้องมีการโต้ตอบจากผู้ใช้ เพียงแต่ผู้เขียนไม่ได้เชี่ยวชาญด้านนี้มากพอจะทำ exploit ใช้งานจริงได้
    • มันขึ้นอยู่กับนิยามของคำว่า “การโต้ตอบ” เท่าที่ผมเข้าใจ Alice ไม่จำเป็นต้องพิมพ์เอกสารที่ผู้โจมตีจัดเตรียมไว้ แค่ พิมพ์อะไรก็ได้ ก็เพียงพอแล้ว

  • ทุกครั้งที่ต้องพิมพ์อะไรสักอย่างบน MacOS ผมจะนึกขึ้นมาอีกครั้งว่าผมเกลียดเครื่องพิมพ์และซอฟต์แวร์ที่เกี่ยวกับเครื่องพิมพ์มากแค่ไหน ใช้คอมพิวเตอร์มา 40 ปีแล้ว แต่รู้สึกจริง ๆ ว่าทุก ๆ 10 ปี เครื่องพิมพ์ยิ่งน่าปวดหัวกว่าเดิม

    • เรื่องน่าขำคือขบวนการ FSF เริ่มต้นขึ้นส่วนหนึ่งจากการที่ Stallman หงุดหงิดกับคุณภาพของไดรเวอร์เครื่องพิมพ์มาก แต่ตลอด 40 ปีที่ผ่านมา ไม่ว่าด้วยเหตุผลใด ขบวนการนั้นก็ไม่ได้ช่วยยกระดับคุณภาพซอฟต์แวร์เกี่ยวกับเครื่องพิมพ์อย่างเห็นได้ชัด
    • ผมเขียนโค้ดเกี่ยวกับเครื่องพิมพ์มานานกว่า 10 ปี เข้าใจดีว่าปัญหาทางเทคนิคนั้นยากแค่ไหน แต่บรรดาผู้ขายทำให้สถานการณ์แย่ลงไปอีกมาก เครื่องพิมพ์นี่แย่มาก และผมมองว่ายุค LaserJet III คือจุดสูงสุดแล้ว
    • ผมรู้สึกว่าเครื่องพิมพ์ทุกวันนี้ดีกว่าเมื่อ 10 ปีก่อนมาก อย่างน้อยบน MacOS และ iOS การหาเครื่องพิมพ์และสั่งพิมพ์ไม่มีปัญหา 10 ปีก่อนมันทรมาน แต่ตอนนี้สำหรับผมถือว่าลื่นไหล และไม่ต้องติดตั้งไดรเวอร์ด้วย
    • ข่าวล่าสุด: HP กำลังเพิ่ม AI เข้าไปในไดรเวอร์เครื่องพิมพ์ ไม่ได้ล้อเล่นนะ: https://hardware.slashdot.org/story/24/09/27/0030239/hp-is-a...
    • แม้จะเสียการควบคุมงานพิมพ์ไป แต่ถ้าแปลงเอกสารเป็น PostScript แล้วส่งไปยังพอร์ตของเครื่องพิมพ์ด้วย netcat ก็ใช้งานได้ดี
      pdf2ps - | nc 9001