การแก้ไขระบบควบคุมแหล่งที่มาแบบกระจาย Git 2.24.1, 2.23.1, 2.22.2, 2.21.1, 2.20.2, 2.19.3, 2.18.2, 2.17.3, 2.16.6, 2.15.4 และ 2.14.62.24.1 .XNUMX ซึ่งแก้ไขช่องโหว่ที่อนุญาตให้ผู้โจมตีเขียนเส้นทางที่กำหนดเองในระบบไฟล์ จัดระเบียบการเรียกใช้โค้ดจากระยะไกล หรือเขียนทับไฟล์ในไดเร็กทอรี “.git/” ปัญหาส่วนใหญ่ที่พนักงานระบุ
Microsoft Security Response Center ซึ่งเป็นช่องโหว่ XNUMX รายการจากทั้งหมด XNUMX รายการที่เกิดเฉพาะกับแพลตฟอร์ม Windows
- — คำสั่งสตรีมมิ่ง “feature Export-marks=path” เขียนป้ายกำกับไปยังไดเรกทอรีที่กำหนดเอง ซึ่งสามารถใช้เพื่อเขียนทับเส้นทางที่กำหนดเองในระบบไฟล์เมื่อดำเนินการ "git fast-import" ด้วยข้อมูลอินพุตที่ไม่ได้ตรวจสอบ
- - การหลีกเลี่ยงอาร์กิวเมนต์บรรทัดคำสั่งไม่ถูกต้อง เพื่อเรียกใช้โค้ดของผู้โจมตีจากระยะไกลในระหว่างการโคลนแบบเรียกซ้ำโดยใช้ ssh:// URL โดยเฉพาะอย่างยิ่ง การหลีกเลี่ยงอาร์กิวเมนต์ที่ลงท้ายด้วยแบ็กสแลช (เช่น “test \”) ได้รับการจัดการอย่างไม่ถูกต้อง ในกรณีนี้ เมื่อกำหนดกรอบอาร์กิวเมนต์ด้วยเครื่องหมายคำพูดคู่ เครื่องหมายคำพูดสุดท้ายจะถูกหลีกเลี่ยง ซึ่งทำให้สามารถจัดระเบียบการทดแทนตัวเลือกของคุณในบรรทัดคำสั่งได้
- — เมื่อทำการโคลนโมดูลย่อยแบบวนซ้ำ (“โคลน —recurse-submodules”) ในสภาพแวดล้อม Windows ภายใต้เงื่อนไขบางประการ ทริกเกอร์การใช้ไดเรกทอรี git เดียวกันสองครั้ง (.git, git~1, git~2 และ git~N ได้รับการยอมรับว่าเป็นไดเรกทอรีเดียวใน NTFS แต่สถานการณ์นี้ได้รับการทดสอบสำหรับ git~1 เท่านั้น ซึ่งสามารถใช้ในการจัดระเบียบ เขียนไปยังไดเร็กทอรี ".git" ในการจัดระเบียบการดำเนินการโค้ด ผู้โจมตีสามารถแทนที่สคริปต์ของเขาผ่านตัวจัดการหลังการชำระเงินในไฟล์ .git/config
- — ตัวจัดการสำหรับชื่อไดรฟ์ตัวอักษรในเส้นทาง Windows เมื่อแปลเส้นทางเช่น “C:\” ได้รับการออกแบบมาเพื่อแทนที่ตัวระบุละตินตัวอักษรเดี่ยวเท่านั้น แต่ไม่ได้คำนึงถึงความเป็นไปได้ในการสร้างไดรฟ์เสมือนที่กำหนดผ่าน “ตัวอักษรย่อย:เส้นทาง” . เส้นทางดังกล่าวไม่ได้รับการปฏิบัติเหมือนเป็นสัมบูรณ์ แต่เป็นเส้นทางสัมพัทธ์ซึ่งทำให้เมื่อทำการโคลนพื้นที่เก็บข้อมูลที่เป็นอันตรายสามารถจัดระเบียบบันทึกในไดเร็กทอรีที่กำหนดเองนอกแผนผังไดเร็กทอรีการทำงาน (ตัวอย่างเช่น เมื่อใช้ตัวเลขหรืออักขระยูนิโค้ดในดิสก์ ชื่อ - “1:\what\the\ hex.txt" หรือ "ä:\tschibät.sch")
- — เมื่อทำงานบนแพลตฟอร์ม Windows การใช้สตรีมข้อมูลทางเลือกใน NTFS สร้างขึ้นโดยการเพิ่มแอตทริบิวต์ “:stream-name:stream-type” ให้กับชื่อไฟล์ เขียนทับไฟล์ในไดเร็กทอรี ".git/" เมื่อทำการโคลนพื้นที่เก็บข้อมูลที่เป็นอันตราย ตัวอย่างเช่น ชื่อ ".git::$INDEX_ALLOCATION" ใน NTFS ถือเป็นลิงก์ที่ถูกต้องไปยังไดเรกทอรี ".git"
- — เมื่อใช้ Git ในสภาพแวดล้อม WSL (ระบบย่อย Windows สำหรับ Linux) เมื่อเข้าถึงไดเร็กทอรีการทำงาน การป้องกันการจัดการชื่อใน NTFS (การโจมตีผ่านการแปลชื่อ FAT เป็นไปได้ เช่น “.git” สามารถเข้าถึงได้ผ่านไดเร็กทอรี “git~1”)
- -
เขียนไปยังไดเรกทอรี ".git/" บนแพลตฟอร์ม Windows เมื่อทำการโคลนพื้นที่เก็บข้อมูลที่เป็นอันตรายซึ่งมีไฟล์ที่มีแบ็กสแลชในชื่อ (เช่น "a\b") ซึ่งเป็นที่ยอมรับบน Unix/Linux แต่ได้รับการยอมรับว่าเป็นส่วนหนึ่งของ เส้นทางบน Windows - — การตรวจสอบชื่อโมดูลย่อยไม่เพียงพอสามารถใช้เพื่อจัดระเบียบการโจมตีแบบกำหนดเป้าหมาย ซึ่งหากทำการโคลนแบบวนซ้ำก็อาจเป็นไปได้ เพื่อรันโค้ดของผู้โจมตี Git ไม่ได้ป้องกันการสร้างไดเร็กทอรีโมดูลย่อยภายในไดเร็กทอรีของโมดูลย่อยอื่น ซึ่งโดยส่วนใหญ่แล้วจะทำให้เกิดความสับสนเท่านั้น แต่ไม่ได้ป้องกันเนื้อหาของโมดูลอื่นไม่ให้ถูกเขียนทับในระหว่างกระบวนการโคลนแบบเรียกซ้ำ (เช่น ไดเร็กทอรีโมดูลย่อย "hippo" และ "hippo/hooks" ถูกวางเป็น " .git/modules/hippo/" และ ".git/modules/hippo/hooks/" และไดเร็กทอรี hooks ใน hippo สามารถใช้แยกกันเพื่อโฮสต์ hooks ที่ทริกเกอร์ได้
ผู้ใช้ Windows ควรอัปเดตเวอร์ชันของ Git ทันที และงดเว้นจากการโคลนพื้นที่เก็บข้อมูลที่ไม่ได้รับการยืนยันจนกว่าจะอัปเดต หากยังไม่สามารถอัปเดตเวอร์ชัน Git อย่างเร่งด่วนได้ เพื่อลดความเสี่ยงของการโจมตี ไม่แนะนำให้รัน “git clone —recurse-submodules” และ “git submodule update” ด้วยที่เก็บข้อมูลที่ไม่ได้ตรวจสอบ ไม่ใช้ “git นำเข้าอย่างรวดเร็ว” ด้วยสตรีมอินพุตที่ไม่ได้ตรวจสอบ และไม่ต้องโคลนที่เก็บข้อมูลไปยังพาร์ติชันที่ใช้ NTFS
เพื่อเพิ่มความปลอดภัย รุ่นใหม่ยังห้ามการใช้โครงสร้างของรูปแบบ "submodule.{name}.update=!command" ใน .gitmodules สำหรับการแจกจ่าย คุณสามารถติดตามการเปิดตัวการอัปเดตแพ็คเกจได้จากเพจ ,, , , , , , .
ที่มา: opennet.ru