ช่องโหว่ความปลอดภัยที่เพิ่งค้นพบใน Helm ซึ่งเป็น package manager ยอดนิยมสำหรับ Kubernetes ได้จุดประกายการอภิปรายอย่างเข้มข้นในชุมชนนักพัฒนาเกี่ยวกับความเป็นไปได้ในการโจมตีและผลกระทบด้านความปลอดภัยในวงกว้าง ช่องโหว่นี้ซึ่งได้รับการแก้ไขใน Helm v3.18.4 ช่วยให้ผู้โจมตีสามารถเรียกใช้โค้ดตามต้องการได้โดยการรวมไฟล์ Chart.yaml ที่สร้างขึ้นเป็นพิเศษเข้ากับไฟล์ Chart.lock ที่เป็น symlink
ขั้นตอนการแก้ไขปัญหา:
- อัปเดตเป็น Helm v3.18.4 หรือเวอร์ชันที่ใหม่กว่า
- ตรวจสอบให้แน่ใจว่าไฟล์ Chart.lock ไม่ใช่ symlinks ก่อนที่จะอัปเดต dependencies
- ตรวจสอบ charts จากแหล่งที่ไม่น่าเชื่อถือเพื่อหา symlinks ที่น่าสงสัย
วิธีการทำงานของการโจมตี
ช่องโหว่นี้ใช้ประโยชน์จากกระบวนการอัปเดต dependency ของ Helm ในลักษณะที่ชาญฉลาดแต่ซับซ้อน เมื่อผู้โจมตีสร้างไฟล์ Chart.yaml ที่เป็นอันตรายซึ่งมีโค้ดที่สามารถเรียกใช้ได้ และแทนที่ไฟล์ Chart.lock ด้วย symlink ที่ชี้ไปยังไฟล์ระบบที่สำคัญเช่น .bashrc หรือ shell startup scripts การเรียกใช้ helm dependency update จะเขียนเนื้อหาที่เป็นอันตรายลงในไฟล์เป้าหมาย โค้ดจะถูกเรียกใช้เมื่อเหยื่อเปิด shell หรือเรียกใช้สคริปต์เป้าหมายครั้งถัดไป
ชุมชนได้อภิปรายเกี่ยวกับผลกระทบในทางปฏิบัติของการโจมตีแบบนี้ นักพัฒนาหลายคนตั้งคำถามเกี่ยวกับสถานการณ์ในโลกจริงที่ช่องโหว่นี้อาจถูกใช้ประโยชน์ เนื่องจากต้องการให้ผู้โจมตีมีการเข้าถึงระบบไฟล์ในระดับหนึ่งเพื่อสร้าง symlink ตั้งแต่แรก
ข้อกำหนดของช่องโหว่:
- ไฟล์ Chart.yaml ที่เป็นอันตรายพร้อมเนื้อหาที่สามารถเรียกใช้งานได้
- ไฟล์ Chart.lock ถูกแทนที่ด้วย symlink ไปยังไฟล์ระบบ (เช่น .bashrc)
- เหยื่อเรียกใช้การอัปเดต dependency บน chart ที่เป็นอันตราย
- ไฟล์เป้าหมายต้องถูกเรียกใช้งานในภายหลังเพื่อให้โค้ดทำงาน
การตั้งคำถามเกี่ยวกับสถานการณ์การโจมตี
ส่วนสำคัญของการอภิปรายมุ่งเน้นไปที่ความเป็นไปได้ในทางปฏิบัติของช่องโหว่นี้ นักพัฒนาสับสนเกี่ยวกับสถานการณ์ที่ถูกต้องตามกฎหมายที่ผู้โจมตีสามารถสร้าง symlinks ได้แต่ไม่สามารถแก้ไขไฟล์ระบบโดยตรง การโจมตีต้องการให้เหยื่อเรียกใช้การอัปเดต dependency บน chart ที่มีทั้งเนื้อหาที่เป็นอันตรายและ symlink ที่มีอยู่แล้ว ทำให้บางคนสงสัยว่านี่เป็นปัญหาความปลอดภัยที่แท้จริงหรือเป็นกรณีพิเศษที่มีผลกระทบในโลกจริงจำกัด
ความสับสนเกิดขึ้นบางส่วนจากโมเดลการแจกจ่ายของ Helm Charts มักถูกแบ่งปันเป็นแพ็คเกจ และการรวม symlinks ที่ชี้ไปยังไฟล์ระบบจะทำให้ charts ไม่สามารถใช้งานได้บนเครื่องอื่น ๆ สิ่งนี้ทำให้เกิดคำถามเกี่ยวกับวิธีที่ charts ที่เป็นอันตรายดังกล่าวจะไปถึงเหยื่อในทางปฏิบัติ
ปัญหา Symlink ในวงกว้าง
ช่องโหว่นี้เน้นย้ำถึงปัญหาที่มีมายาวนานของ Helm ในการจัดการ symlinks การอภิปรายของชุมชนเผยให้เห็นว่า Helm ได้ต่อสู้กับความปลอดภัยของ symlink มาหลายปี โดยเคยแก้ไขข้อกังวลที่คล้ายกันในปี 2019 การแก้ไขปัจจุบันมุ่งเป้าไปที่ไฟล์ Chart.lock โดยเฉพาะ แต่นักพัฒนาตั้งคำถามว่าแนวทางที่ครอบคลุมมากขึ้น เช่น การห้าม external symlinks ทั้งหมดใน distributed charts อาจจำเป็น
A chart cannot contain any symlinks outside of its root สมาชิกชุมชนคนหนึ่งแนะนำ โดยเสนอแนวทางที่เข้มงวดมากขึ้นซึ่งจะป้องกันปัญหาที่คล้ายกันในทุกส่วนประกอบของ chart
คำสั่ง Helm ที่ได้รับผลกระทบ:
helm dependency update- เวกเตอร์การโจมตีหลักhelm dependency build- สามารถเขียนไฟล์ lock เมื่อไม่มีไฟล์ดังกล่าวอยู่- Helm SDK downloader Manager - ส่งผลกระทบต่อการใช้งานแบบโปรแกรม
การตอบสนองของชุมชนและบทเรียนที่ได้รับ
ช่องโหว่นี้ยังได้จุดประกายการอภิปรายในวงกว้างเกี่ยวกับรูปแบบไฟล์การกำหนดค่าและแนวปฏิบัติด้านความปลอดภัย ในขณะที่นักพัฒนาบางคนวิพากษ์วิจารณ์ YAML ว่าเป็นปัญหาโดยธรรมชาติ คนอื่น ๆ ชี้ให้เห็นว่าปัญหานี้เกิดจากตรรกะของ Helm มากกว่า YAML เอง การอภิปรายสะท้อนความตึงเครียดอย่างต่อเนื่องในชุมชนนักพัฒนาเกี่ยวกับการสร้างสมดุลระหว่างความสะดวกในการใช้งานกับความปลอดภัย
การแก้ไขที่ดำเนินการใน Helm v3.18.4 ป้องกันการเขียนไปยังไฟล์ Chart.lock ที่เป็น symlink แม้ว่านักพัฒนาบางคนจะโต้แย้งเพื่อการป้องกันที่ครอบคลุมมากขึ้น ในตอนนี้ ผู้ใช้สามารถป้องกันตัวเองได้โดยการตรวจสอบให้แน่ใจว่าไฟล์ Chart.lock ไม่ใช่ symlinks ก่อนที่จะอัปเดต dependencies แม้ว่าความเสี่ยงในทางปฏิบัติสำหรับผู้ใช้ส่วนใหญ่ดูเหมือนจะจำกัดเนื่องจากเงื่อนไขเฉพาะที่จำเป็นสำหรับการใช้ประโยชน์
อ้างอิง: Chart Dependency Updating With Malicious Chart.yaml Content And Symlink