พวกเขาค้นพบช่องโหว่ใน xterm ที่นำไปสู่การเรียกใช้โค้ด

ความอ่อนแอ

หากถูกโจมตี ข้อบกพร่องเหล่านี้อาจทำให้ผู้โจมตีเข้าถึงข้อมูลที่ละเอียดอ่อนโดยไม่ได้รับอนุญาต หรือก่อให้เกิดปัญหาโดยทั่วไป

ล่าสุดมีข่าวดังกล่าว พบช่องโหว่ในโปรแกรมจำลองเทอร์มินัล xterm (จัดรายการแล้วภายใต้ CVE-2022-45063) ปัญหา อนุญาตให้ดำเนินการคำสั่งเชลล์ เมื่อมีการประมวลผลลำดับการหลบหนีบางอย่างในเทอร์มินัล

เกี่ยวกับปัญหาดังกล่าวว่า เกิดจากข้อผิดพลาดในการประมวลผลของ Escape Code 50 ซึ่งใช้เพื่อตั้งค่าหรือรับตัวเลือกแบบอักษร ถ้าไม่มีฟอนต์ที่ร้องขอ การดำเนินการจะส่งกลับชื่อของฟอนต์ที่ระบุในคำขอ

ปัญหาอยู่ในลำดับ OSC 50 ซึ่งมีไว้สำหรับการกำหนดค่าและให้คำปรึกษา น้ำพุ. หากไม่มีแหล่งที่มาที่กำหนด จะไม่มีการตั้งค่า แต่เป็นแบบสอบถาม จะคืนชื่อที่ตั้งไว้ ไม่สามารถควบคุมอักขระได้ รวมอยู่ด้วย แต่สตริงตอบกลับสามารถลงท้ายด้วย ^G ทิศตะวันออก โดยพื้นฐานแล้วทำให้เรามีพื้นฐานในการส่งคืนข้อความไปยังเทอร์มินัล และลงท้ายด้วย ^G

ไม่สามารถแทรกอักขระควบคุมได้โดยตรง ในชื่อ, แต่สตริงที่ส่งคืนสามารถยุติได้ด้วยลำดับ "^G" ซึ่งใน zsh เมื่อโหมดแก้ไขบรรทัดแบบ vi เปิดใช้งานอยู่ จะทำให้เกิดการดำเนินการขยายรายการ ซึ่งสามารถใช้เพื่อดำเนินการคำสั่งโดยไม่ต้องกดปุ่ม Enter อย่างชัดเจน

สำหรับการโจมตีในกรณีที่ง่ายที่สุด การแสดงเนื้อหาของไฟล์ที่ออกแบบมาเป็นพิเศษก็เพียงพอแล้ว บนหน้าจอ เช่น ใช้ยูทิลิตี cat หรือวางบรรทัดจากคลิปบอร์ด

Debian, Red Hat และอื่น ๆ ปิดการใช้งานแบบอักษรตามค่าเริ่มต้น แต่ผู้ใช้สามารถเปิดใช้งานอีกครั้งได้ ผ่านตัวเลือกหรือเมนูการกำหนดค่า นอกจากนี้ xterm ต้นน้ำยังทำ ไม่ได้ปิดใช้งานตามค่าเริ่มต้น ดังนั้นการแจกแจงบางอย่างจึงรวมถึง การกำหนดค่าเริ่มต้นที่มีช่องโหว่

เพื่อใช้ประโยชน์จากช่องโหว่ให้สำเร็จ ผู้ใช้ต้องใช้เชลล์ Zsh กับตัวแก้ไขบรรทัดคำสั่ง (vi-cmd-mode) ที่เปลี่ยนเป็นโหมด "vi"ซึ่งโดยทั่วไปจะไม่ใช้โดยค่าเริ่มต้นในการแจกแจง

โดยพื้นฐานแล้ว เราต้องการ:
zsh
โหมดแก้ไขบรรทัดที่ใช้งานอยู่ในรูปแบบ vi
คัดลอกข้อความของโทรจันไปยังคลิปบอร์ด
วางใน zsh

สิ่งนี้สามารถทำได้โดยอัตโนมัติ ไซต์จำนวนมากแก้ไขข้อความเมื่อคัดลอกไปยังคลิปบอร์ด ดังนั้นฉันจึงใช้เฉพาะบัฟเฟอร์การเลือก ซึ่งเบราว์เซอร์ไม่สามารถเข้าถึงได้ เฉพาะใน gtk3 และโดยเฉพาะอย่างยิ่ง ff เท่านั้นที่พังอย่างต่อเนื่องด้วยเหตุผลบางประการ มันเหนื่อยมาก

ปัญหาจะไม่ปรากฏขึ้นเมื่อตั้งค่า xterm เป็น allowWindowOps=false หรือ allowFontOps=false. ตัวอย่างเช่น การกำหนดค่า allowFontOps=เท็จ มันถูกตั้งค่าบน OpenBSD, Debian และ RHEL แต่ไม่ถูกบังคับใช้โดยค่าเริ่มต้นบน Arch Linux

ตามบันทึกการเปลี่ยนแปลงและคำชี้แจงของผู้วิจัยที่ระบุประเด็นช่องโหว่ แก้ไขในเวอร์ชัน xterm 375 แต่ตามแหล่งอื่น ๆ ช่องโหว่ยังคงปรากฏอยู่ใน xterm 375 ของ Arch Linux

ซึ่งหมายความว่าในการใช้ประโยชน์จากช่องโหว่นี้ ผู้ใช้จะต้องเป็น
ใช้ Zsh ในโหมดแก้ไขบรรทัด vi (โดยปกติผ่าน $EDITOR ซึ่งมี "vi" อยู่ใน
ของมัน). แม้ว่าจะค่อนข้างคลุมเครือ แต่ก็ไม่เคยได้ยินมาก่อน
การตั้งค่า

ในการตั้งค่านั้น เช่น:
printf "\e]50;i\$(สัมผัส /tmp/hack-like-its-1999)\a\e]50;?\a"> cve-2022-45063
cat cve-2022-45063 # หรือจัดส่งทางอื่นให้ผู้เสียหาย

สุดท้าย เช่นเคย ผู้ใช้ระบบที่ได้รับผลกระทบควรปรับปรุงระบบของตนให้ทันสมัยอยู่เสมอ เพราะอย่างที่คุณทราบเมื่อทราบช่องโหว่ด้านความปลอดภัย นักพัฒนาซอฟต์แวร์ต้องแก้ไขข้อบกพร่องเหล่านี้ เนื่องจากมีการเปิดเผยวิธีการใช้ประโยชน์จากข้อบกพร่องเหล่านี้เป็นส่วนใหญ่

เป็นมูลค่าการกล่าวขวัญว่า ไม่อนุญาตให้ใช้แบบอักษรในการตั้งค่าเริ่มต้นของ xterm ของ ลีนุกซ์บางรุ่น ดังนั้นการแจกแจงทั้งหมดจึงไม่มีแนวโน้มที่จะเกิดข้อผิดพลาดนี้ สำหรับผู้สนใจติดตามการจัดพิมพ์แก้ไขโดยแจกแจงได้ที่หน้าต่อไปนี้ debianRHELFedoraSUSEอูบุนตูArch ลินุกซ์OpenBSDFreeBSDNetBSD.

ถ้าคุณเป็น สนใจที่จะทราบข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้คุณสามารถตรวจสอบรายละเอียด ในลิงค์ต่อไปนี้.


แสดงความคิดเห็นของคุณ

อีเมล์ของคุณจะไม่ถูกเผยแพร่ ช่องที่ต้องการถูกทำเครื่องหมายด้วย *

*

*

  1. ผู้รับผิดชอบข้อมูล: Miguel ÁngelGatón
  2. วัตถุประสงค์ของข้อมูล: ควบคุมสแปมการจัดการความคิดเห็น
  3. ถูกต้องตามกฎหมาย: ความยินยอมของคุณ
  4. การสื่อสารข้อมูล: ข้อมูลจะไม่ถูกสื่อสารไปยังบุคคลที่สามยกเว้นตามข้อผูกพันทางกฎหมาย
  5. การจัดเก็บข้อมูล: ฐานข้อมูลที่โฮสต์โดย Occentus Networks (EU)
  6. สิทธิ์: คุณสามารถ จำกัด กู้คืนและลบข้อมูลของคุณได้ตลอดเวลา