ช่องโหว่การฉีดคีย์อินพุตผ่าน Bluetooth บน Android, Linux, macOS และ iOS

 (github.com/skysafe)
2 คะแนน โดย GN⁺ 2023-12-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • CVE-2023-45866 เป็นช่องโหว่การข้ามการยืนยันตัวตนใน Bluetooth stack ของหลายระบบปฏิบัติการ ที่ทำให้สามารถเชื่อมต่อคีย์บอร์ดปลอมและฉีดคีย์อินพุตได้โดยไม่ต้องมีการยืนยันจากผู้ใช้
  • ผู้โจมตีที่อยู่ใกล้สามารถลองทำงานอย่างการติดตั้งแอป รันคำสั่งตามอำเภอใจ และส่งข้อความได้ โดยใช้เพียง คอมพิวเตอร์ Linux และอะแดปเตอร์ Bluetooth ทั่วไป โดยไม่ต้องมีอุปกรณ์พิเศษ
  • เงื่อนไขของการโจมตีแตกต่างกันไปในแต่ละแพลตฟอร์ม โดย Android ขึ้นอยู่กับการเปิดใช้งาน Bluetooth, Linux/BlueZ ขึ้นอยู่กับสถานะ discoverable/connectable และ iOS กับ macOS ได้รับผลจากการจับคู่ Magic Keyboard
  • Android 11-14 บรรเทาปัญหาได้ด้วย ระดับแพตช์ความปลอดภัย 2023-12-05 แต่ Android 4.2.2-10 ไม่มีการแก้ไข และ BlueZ เคยมีการแก้ในปี 2020 ที่ถูกปิดไว้เป็นค่าเริ่มต้น
  • งานที่ต้องใช้รหัสผ่านหรือการยืนยันตัวตนด้วยชีวมิติไม่สามารถทำได้ด้วยการฉีดคีย์อินพุตเพียงอย่างเดียว แต่เครื่องที่ยังไม่ได้แพตช์อาจเปิดช่องให้ถูกโจมตีผ่าน Bluetooth ในระยะใกล้

การฉีดคีย์อินพุตผ่าน Bluetooth โดยไม่ต้องยืนยันตัวตน

  • CVE-2023-45866 เป็นช่องโหว่ที่เปิดให้เกิดการฉีดคีย์สโตรกผ่าน Bluetooth โดยไม่ต้องยืนยันตัวตนบน Android, Linux, macOS และ iOS
  • ใน Bluetooth stack หลายตัว มีการ ข้ามการยืนยันตัวตน ที่ทำให้ผู้โจมตีเชื่อมต่อกับโฮสต์ที่อยู่ในสถานะ discoverable และฉีดคีย์อินพุตได้โดยไม่ต้องมีการยืนยันจากผู้ใช้
  • ผู้โจมตีที่อยู่ใกล้สามารถสร้างการเชื่อมต่อ Bluetooth ที่ไม่ได้รับการยืนยันกับอุปกรณ์ที่มีช่องโหว่ และใช้คีย์อินพุตเพื่อทำสิ่งต่อไปนี้ได้
    • ติดตั้งแอป
    • รันคำสั่งตามอำเภอใจ
    • ส่งข้อความ
  • การโจมตีไม่ต้องใช้อุปกรณ์ฮาร์ดแวร์พิเศษ และสามารถทำได้ด้วยคอมพิวเตอร์ Linux และ อะแดปเตอร์ Bluetooth ทั่วไป
  • รายละเอียด exploit ทั้งหมดและสคริปต์ PoC มีกำหนดเปิดเผยในช่วงสัปดาห์ของ ShmooCon วันที่ 12-14 มกราคม

เงื่อนไขการโจมตีแยกตามแพลตฟอร์ม

  • ช่องโหว่นี้ทำงานโดยหลอก Bluetooth host state machine ให้จับคู่กับ คีย์บอร์ดปลอม โดยไม่ต้องมีการยืนยันจากผู้ใช้
  • กลไกการจับคู่แบบไม่ต้องยืนยันตัวตนที่เป็นรากฐานนั้นมีอยู่ในข้อกำหนดของ Bluetooth และบั๊กในแต่ละ implementation ทำให้มันกลายเป็นพื้นผิวการโจมตี
  • เงื่อนไขที่ต้องมีบนอุปกรณ์ที่ยังไม่ได้แพตช์แตกต่างกันไปตามระบบปฏิบัติการ
    • Android: มีช่องโหว่ถ้าเปิด Bluetooth อยู่
    • Linux/BlueZ: Bluetooth ต้องอยู่ในสถานะ discoverable/connectable
    • iOS และ macOS: Bluetooth ต้องเปิดอยู่ และมีการจับคู่ Magic Keyboard กับโทรศัพท์หรือคอมพิวเตอร์ไว้
  • หลังจากผู้โจมตีจับคู่กับโทรศัพท์หรือคอมพิวเตอร์เป้าหมายแล้ว ก็สามารถฉีดคีย์อินพุตด้วยสิทธิ์ของเหยื่อได้
  • การกระทำที่ต้องใช้รหัสผ่านหรือการยืนยันตัวตนด้วยชีวมิติไม่สามารถทำได้ด้วยการฉีดคีย์อินพุตเพียงอย่างเดียว

ช่องโหว่เก่าที่ถูกเปิดเผยหลังยุค MouseJack

  • งานวิจัย MouseJack ที่เปิดเผยในปี 2016 มุ่งเป้าไปที่โปรโตคอลไร้สายแบบกำหนดเองของอุปกรณ์ต่อพ่วง ไม่ใช่ Bluetooth
  • งานวิจัยครั้งนี้เริ่มต้นจากการตรวจสอบ Bluetooth และสภาพแวดล้อมของ Apple โดยใช้ Apple Magic Keyboard เป็นเป้าหมาย
  • พบการฉีดคีย์สโตรกผ่าน Bluetooth โดยไม่ต้องยืนยันตัวตนบน macOS และ iOS และทั้งสองแพลตฟอร์มยังถูกโจมตีได้แม้อยู่ใน Lockdown Mode
  • ต่อมาพบช่องโหว่ลักษณะคล้ายกันใน Linux และ Android ด้วย ทำให้ดูเหมือนเป็นข้อบกพร่องระดับโปรโตคอลมากกว่าบั๊ก implementation แบบง่าย ๆ และเมื่อตรวจสอบข้อกำหนด Bluetooth HID ก็พบว่าเป็นทั้งสองอย่าง
  • ช่องโหว่บางส่วนเก่ากว่า MouseJack และสามารถทำซ้ำการฉีดคีย์สโตรกได้ย้อนไปถึง Android 4.2.2

ผลกระทบต่อ Android และสถานะแพตช์

  • อุปกรณ์และเวอร์ชัน Android ที่ทดสอบแล้วพบว่ามีช่องโหว่มีดังนี้
    • Pixel 7, Android 14
    • Pixel 6, Android 13
    • Pixel 4a (5G), Android 13
    • Pixel 2, Android 11
    • Pixel 2, Android 10
    • Nexus 5, Android 6.0.1
    • BLU DASH 3.5, Android 4.2.2
  • ระดับแพตช์ความปลอดภัย 2023-12-05 ช่วยบรรเทาช่องโหว่ใน Android 11-14
  • Android 4.2.2-10 ไม่มีการแก้ไขที่ใช้งานได้
  • กำหนดการเปิดเผยมีดังนี้
    • 2023-08-05: รายงานช่องโหว่ต่อ Google
    • 2023-12-06: เปิดเผยสู่สาธารณะ
  • Google ระบุว่าได้ส่งมอบการแก้ไขปัญหาที่กระทบ Android 11-14 ให้กับ OEM ที่ได้รับผลกระทบแล้ว และอุปกรณ์ Pixel ที่ยังอยู่ในการสนับสนุนทั้งหมดจะได้รับการแก้ไขผ่านอัปเดต OTA เดือนธันวาคม

ผลกระทบต่อ Linux/BlueZ และแพตช์

  • เวอร์ชัน Ubuntu ที่ทดสอบแล้วพบว่ามีช่องโหว่คือ 18.04, 20.04, 22.04, 23.10
  • ตามข้อมูลจาก Google, ChromeOS ไม่ได้รับผลกระทบ และแม้จะไม่ได้ทดสอบโดยตรง แต่ดูเหมือนว่าการตั้งค่า BlueZ ช่วยบรรเทาช่องโหว่นี้ได้
  • ช่องโหว่บน Linux ถูกแก้ไปแล้วในปี 2020 ภายใต้ CVE-2020-0556 แต่การแก้ไขนั้นถูกปิดไว้เป็นค่าเริ่มต้น
  • ChromeOS เป็น Linux-based OS เพียงรายเดียวที่ทราบว่าได้เปิดใช้การแก้นี้
  • แพตช์ BlueZ สำหรับ CVE-2023-45866 เปิดใช้การแก้ไขจากปี 2020 เป็นค่าเริ่มต้น
  • แพตช์ BlueZ ที่เกี่ยวข้อง:
  • ข้อมูลที่เกี่ยวข้องกับ Ubuntu:
  • ข้อมูลที่เกี่ยวข้องกับ Debian:
  • ข้อมูลที่เกี่ยวข้องกับ Fedora:
  • กำหนดการเปิดเผยมีดังนี้
    • 2023-08-10: รายงานช่องโหว่ต่อ Canonical
    • 2023-09-25: รายงานช่องโหว่ต่อ Bluetooth SIG
    • 2023-10-02: เปิดเคสกับ CERT/CC
    • 2023-12-06: เปิดเผยสู่สาธารณะ

ผลกระทบต่อ macOS และ iOS

  • อุปกรณ์ที่ทดสอบบน macOS และพบว่ามีช่องโหว่มีดังนี้
    • 2022 MacBook Pro, macOS 13.3.3, M2
    • 2017 MacBook Air, macOS 12.6.7, Intel
  • Lockdown Mode บน macOS ไม่สามารถป้องกันการโจมตีนี้ได้
  • macOS Sonoma 14.2 แก้ไขช่องโหว่นี้แล้ว
  • กำหนดการเปิดเผยสำหรับ macOS มีดังนี้
    • 2023-08-01: รายงานช่องโหว่ต่อ Apple
    • 2023-12-06: เปิดเผยสู่สาธารณะ
  • อุปกรณ์ที่ทดสอบบน iOS และพบว่ามีช่องโหว่คือ iPhone SE ที่รัน iOS 16.6
  • Lockdown Mode บน iOS ก็ไม่สามารถป้องกันการโจมตีนี้ได้เช่นกัน
  • กำหนดการเปิดเผยสำหรับ iOS มีดังนี้
    • 2023-08-04: รายงานช่องโหว่ต่อ Apple
    • 2023-12-06: เปิดเผยสู่สาธารณะ

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

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

 
GN⁺ 2023-12-17
ความคิดเห็นจาก Hacker News

  • ผมต้องไปค้นดูอยู่บ้างเพื่อยืนยันเรื่องนี้ แต่ถ้าอยากใช้งานให้ปลอดภัย บน Android ควร ปิด Bluetooth เมื่อไม่ได้ใช้ อย่างไรก็ตาม ระหว่างที่ใช้งานอยู่ก็ยังมีช่องโหว่
    Pixel ของผมได้รับอัปเดตความปลอดภัยวันที่ 2023-12-05 และปัญหานี้ได้รับการแก้ไขแล้ว แต่สำหรับอุปกรณ์ที่ไม่ใช่ Pixel ผมไม่แน่ใจ
    บน Linux ให้เปิด /etc/bluetooth/input.conf แล้วตั้งค่า ClassicBondedOnly=true ในกรณีของผมไม่ต้องเพิ่มใหม่ แค่เอาคอมเมนต์ออกก็พอ ใน bluetoothd เวอร์ชันถัดไป ค่าเริ่มต้นจะเป็น true แต่ตอนนี้ก็ตั้งค่าเองได้ และหลังจากนั้นต้องรีสตาร์ตบริการ Bluetooth
    ส่วน macOS หรือ iOS ผมไม่มีอุปกรณ์พวกนั้นเลยไม่ทราบ

    • ผมไม่ชอบมาตลอดที่หลังอัปเดต iOS แล้ว Bluetooth จะกลับมาเปิดอยู่เสมอ ทั้งที่จริง ๆ ก็ไม่ได้ใช้ เลยสงสัยมานานว่าทำไมถึงเป็นแบบนั้น
      Wi-Fi ก็อยู่ในสภาพเหมือนชีสพรุน ๆ เพราะปิดให้สนิทจาก Control Center ไม่ได้
    • ใน bluez v5.70-4 ของ Fedora 38 ดูเหมือนว่าค่าเริ่มต้นจะเป็น true ตั้งแต่วันที่ 7 ธันวาคมแล้ว
      $ rpm -q --changelog bluez | grep CVE-2023-45866 -C1
      * Thu Dec 07 2023 Peter Robinson - 5.70-4
      - Add mitigation for CVE-2023-45866
    • น่าเสียดายที่การปิด Bluetooth บน iOS ยุ่งยากเกินไป บน Android แค่ปัดแล้วคลิกก็จบ แต่บน iOS ต้องปัด กดค้างสองครั้ง แล้วคลิกอีกสองครั้ง
      หลังย้ายมาจาก Android ผมพยายามอยู่พักหนึ่ง แต่สุดท้ายก็ยอมแพ้
    • ดูจากหน้านั้น เห็นว่าใช้งานได้เฉพาะกับสิ่งที่ไม่ต้องใช้รหัสผ่านหรือการยืนยันตัวตนแบบชีวมิติ
      ถ้าไม่ใช้โทรศัพท์ก็ล็อกเครื่องอย่างจริงจัง และถ้าขณะใช้งานมีการส่งคีย์อินพุตเข้ามาก็คงเห็นบนหน้าจอ ดังนั้นการเปิด Bluetooth ไว้ก็ไม่ได้ดูเลวร้ายขนาดนั้น
    • อยากรู้ว่ามีวิธีตรวจสอบไหมว่า GrapheneOS แก้เรื่องนี้ใน บรานช์ sunfish(4a) แล้วหรือยัง ผมใช้ Pixel 4a เลยติดอยู่กับ Android 13 และต้องใช้ Bluetooth เพื่อเปิดประตูรถ
      ถ้า GrapheneOS แก้แล้วก็คงเป็นแรงจูงใจให้ย้ายไปใช้ในที่สุด แต่โทรศัพท์ตอนนี้ยังใช้งานได้ดี เลยหาเหตุผลมารองรับการซื้อเครื่องใหม่ได้ยาก

  • ผมสงสัยที่ไม่มีการกล่าวถึง Windows เลย ฟังเผิน ๆ เหมือนเป็นข่าวดี แต่ต้องรู้ว่าทำไม Windows ถึงไม่ได้รับผลกระทบจริง ๆ จึงจะ ประเมินความเสี่ยง ได้
    เช่น ถ้ารู้ว่าใน Bluetooth stack ของ Windows มีโครงสร้างที่เทียบได้กับ ClassicBondedOnly=false ของ BlueZ หรือไม่ ก็จะตัดสินใจได้ว่าควรจับตาดูค่านั้นให้เป็น true ในสภาพแวดล้อมที่ต้องการเสริมความแข็งแกร่ง
    หรือไม่ stack ก็อาจทำงานต่างกันโดยสิ้นเชิง จนสิ่งที่ต้องพิจารณาก็ต่างออกไปทั้งหมด
    ผมตั้งตารอวิดีโอที่มี PoC และเดโมเยอะ ๆ แต่ Windows มีส่วนแบ่งตลาดสูง และคงมีผู้ดูแลระบบจำนวนมากที่ตกใจ ดังนั้นถ้ามีข้อมูลก็คงดี แม้แต่ “ยังไม่ได้ลองโจมตี Windows” ก็เป็นข้อมูลที่มีประโยชน์

    • การโจมตีเฉพาะแบบนี้อาจไม่ทำให้ Windows มีช่องโหว่ก็ได้
      แต่ถ้าใช้ Flipper Zero สร้างอุปกรณ์ Bluetooth ทันทีที่ไคลเอนต์ Windows เชื่อมต่อ มันจะถูกมองว่าเป็นคีย์บอร์ดและทำให้รัน คำสั่ง PowerShell ที่ต้องการได้ ผมเองลองแค่เปิด YouTube เพื่อ RickRoll เท่านั้น ไม่ได้ลองอะไรที่ผิดกฎหมาย
      ตอนนี้ผมปิด Bluetooth ทั้งหมดแล้ว แต่ไม่รู้วิธีลบ bluez โดยไม่ทำให้ Linux พัง
    • อาจเป็นเพราะบน Windows นั้น Bluetooth มักแทบไม่ทำงานตามปกติอยู่แล้วก็ได้
    • ที่บอกว่า Bluetooth stack ของ Windows เทียบได้กับ ClassicBondedOnly=false ของ BlueZ นี่หมายถึง ClassicBondedOnly=true หรือเปล่า?
    • ผมคิดว่าเป็นเพราะยังไม่ได้ลองทำสิ่งนี้บน Windows มากกว่า

  • ดีจริง ๆ ที่มีข่าวแบบนี้ออกมาในตอนที่อุตสาหกรรมเอาการเชื่อมต่อเสียงแบบกายภาพออกจากโทรศัพท์ แล้วผลักดันให้ใช้ไร้สายกัน เก่งมาก

    • USB-C DAC ราคาถูกและหาซื้อได้ทั่วไป
    • ช่องโหว่นี้เป็นปัญหาเรื่องการ ฉีดคีย์อินพุต เข้าไปยังคีย์บอร์ดและเมาส์ไร้สายที่เชื่อมต่ออยู่[1] การที่อุตสาหกรรมโทรศัพท์นำ USB-C มาใช้ ทำให้การเชื่อมต่อแบบมีสายง่ายกว่าที่เคย
      [1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/pr...

  • ช่องโหว่นี้ทำงานโดยหลอก state machine ฝั่งโฮสต์ของ Bluetooth ให้จับคู่กับคีย์บอร์ดปลอมโดยไม่ต้องมีการยืนยันจากผู้ใช้ กลไกพื้นฐานของ การจับคู่โดยไม่มีการยืนยันตัวตน ถูกกำหนดไว้ในสเปก Bluetooth และบั๊กในแต่ละ implementation ทำให้ผู้โจมตีใช้ประโยชน์ได้
    แต่ทำไมถึงอยากให้จับคู่กันแบบเงียบ ๆ กันนะ ผมอยากรู้รายละเอียดเพิ่มเติมเกี่ยวกับวัตถุประสงค์ที่ตั้งใจไว้ของกลไกที่เป็นปัญหานี้

    • ตามสเปก Bluetooth เป็นเพราะอุปกรณ์ที่ไม่ใช่คอมพิวเตอร์หลายชนิด เช่น ใช้เพื่อให้ไม่ต้องเสียบเมาส์ USB แล้วคลิก “อนุญาตให้จับคู่” ตอนจับคู่คอนโทรลเลอร์ตัวแรกกับ PlayStation
      ส่วนในอุปกรณ์ที่ได้รับผลกระทบจริง ๆ ผมไม่รู้ว่าทำไมถึงปล่อยไว้แบบนั้น
    • มันเป็นแค่การออกแบบเก่าจากยุคที่ไร้เดียงสากว่านี้ สเปกสมัยใหม่ไม่อนุญาตแล้ว แต่ Bluetooth stack ต่าง ๆ ปิดพฤติกรรมแบบใหม่ไว้เพื่อเพิ่มความเข้ากันได้ให้มากที่สุด

  • ปัญหานี้ได้รับการแก้ไขแล้วใน macOS 14.2 และ iOS 17.2
    https://support.apple.com/en-us/HT214036
    https://support.apple.com/en-us/HT214035

  • บน Arch Linux แก้ไขแล้วตั้งแต่ bluez 5.70-2 [1]
    [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/bl...

  • ประโยคที่ว่า “ตอนนั้น Bluetooth ดู intimidating เลยคิดเอาเองว่าปลอดภัย” โดนใจมาก ดูเหมือนว่า มายาคติ ที่ว่า ณ จุดใดจุดหนึ่งบนสแต็กเทคโนโลยีอันซับซ้อนนั้นมีคนที่รู้จริงอยู่ และคงไม่ได้เอาไม้ค้ำปราสาทที่สร้างบนทรายไว้เฉย ๆ เกิดขึ้นจากความน่าเกรงขามแบบนั้น

  • ยังสงสัยอยู่ว่าจะใช้ได้จริงแค่ไหนกับโทรศัพท์หรือคอมพิวเตอร์ แต่ถ้าต้องอยู่ในฐานะที่ต้องดูแล คีออสก์ ไม่ให้ใครมาแตะต้อง ชีวิตก็คงน่าสนใจขึ้นอีกหน่อย

    • ราว 10 ปีก่อน ผมเคยเผลอเปิดเครื่อง Linux ที่เปิด VNC แบบไม่มีรหัสผ่านทิ้งไว้ให้เข้าถึงได้จากอินเทอร์เน็ต ภายในไม่กี่นาทีก็มีคนเชื่อมต่อเข้ามาแล้วพยายามรันอะไรบางอย่างด้วยการป้อนคีย์อัตโนมัติ ซึ่งเห็นได้ชัดว่าเป็นพฤติกรรมที่เล็งไปที่ Windows
      ถ้าฝังแบ็กดอร์ได้สำเร็จสักตัว หลังจากนั้นก็ทำงานต่อได้แล้ว
      ถ้าเป็นการโจมตีแบบเจาะจงเป้าหมาย แค่ส่งการกดปุ่ม Shift ทุก 1 นาทีเพื่อไม่ให้หน้าจอล็อก แล้วค่อยไปที่หน้าเครื่องเองทีหลังเพื่อทำอะไรบางอย่าง ก็อาจเพียงพอแล้ว
    • บนคอมพิวเตอร์ ดูเหมือนว่าจะทำได้ด้วยการซ่อน sudo หรือ su ที่ถูกวางยาพิษไว้ที่ไหนสักแห่ง แล้วเพิ่มเข้าไปใน $PATH

  • USB ก็คล้ายกัน ถ้าเสียบคีย์บอร์ดเข้ากับพอร์ต “ชาร์จอย่างเดียว” มันก็ทำงาน ผมลองเองบน Android แล้ว และโดนตำหนิว่ากรณีนี้เอาไปโจมตีจริงไม่ได้

    • พอร์ต Android ใช้แค่ชาร์จอย่างเดียวหรือ? มันมีประโยชน์มากกับ HDMI ด้วย และใช้กับอุปกรณ์ต่อพ่วงได้ด้วย
      ถึงอย่างนั้น ผมก็ไม่มองว่านี่เป็นช่องโหว่ มันเป็นแค่ฟีเจอร์ที่มีประโยชน์ ปัญหาตรงนี้คือมีใครบางคนสามารถทำสิ่งนี้ได้โดยที่ผู้ใช้ไม่ทันรู้ตัว แม้ระหว่างทำงานที่อ่อนไหวอยู่ก็ตาม
      โปรเจกต์เจ๋ง ๆ ที่โพสต์เมื่อวาน https://mitxela.com/projects/smsc ก็ใช้งานกับโทรศัพท์ด้วยวิธีแบบนี้ได้เช่นกัน
    • สงสัยว่าอุปกรณ์ Android แบบไหนที่มีพอร์ต “ชาร์จอย่างเดียว” ในเชิงกายภาพ

  • ช่องโหว่ของ Linux ถูกแก้ไปแล้วในปี 2020 (CVE-2020-0556) แต่แพตช์นั้นยังคงถูกปิดใช้งานไว้เป็นค่าเริ่มต้น มีรายงานว่าเฉพาะ ChromeOS เท่านั้นที่เปิดใช้แพตช์ดังกล่าว ทั้งที่ Ubuntu, Debian, Fedora, Gentoo, Arch, Alpine ต่างก็ออกประกาศแล้ว

    • ใช้เวลา 30 วินาทีก็พอจะตรวจได้ว่ามันเข้า NixOS แล้วหรือยัง[1] ใช้เวลาอีก 30 วินาทีดูต่อ ก็พบว่าแพตช์ถูกใส่เมื่อ 2023-12-08 08:23 GMT+13 ซึ่งเป็นหนึ่งวันหลังจากบทความถูกโพสต์
      แต่ถ้าประกาศของดิสโทรบอกว่าแค่อัปเกรดก็แก้แล้ว[2] ผมก็ไม่เข้าใจว่า “การแก้ไขถูกปิดไว้เป็นค่าเริ่มต้น” หมายความว่าอะไร หมายความว่าหลังอัปเกรดแล้วยังต้องเปลี่ยนการตั้งค่าด้วยมืออีกหรือ? การแก้ของ NixOS ดูเหมือนเป็นการสลับค่าเริ่มต้น
      ถ้าหมายถึงผู้ใช้ที่ตั้ง ClassicBondedOnly=false ไว้อย่างชัดเจนต้องไปเปลี่ยน ก็น่าจะเขียนให้ชัดกว่านี้ได้มาก
      [1] https://github.com/NixOS/nixpkgs/blob/3dda6d5ed56af34534dd4c...
      [2] https://ubuntu.com/security/notices/USN-4311-1