พบช่องโหว่ของ Shellshock Bash อย่างไร

เนื่องจากข้อผิดพลาดนี้ส่งผลกระทบต่อแพลตฟอร์มจำนวนมากเราอาจเรียนรู้บางอย่างจากกระบวนการที่พบช่องโหว่นี้: มันเป็นช่วงเวลาεὕρηκα (ยูเรก้า) หรือผลลัพธ์ของการตรวจสอบความปลอดภัยหรือไม่

เนื่องจากเรารู้ว่าStéphaneพบข้อผิดพลาดของ Shellshock และคนอื่น ๆ อาจรู้จักกระบวนการเช่นกันเราจึงสนใจในเรื่องราวของวิธีที่เขามาหาข้อผิดพลาด

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

ฉันไม่สามารถพูดได้ว่าฉันจำได้ว่ารถไฟแห่งความคิดของฉันในเวลานั้น

นั่นมากหรือน้อยนั้นมาจากการไตร่ตรองเกี่ยวกับพฤติกรรมบางอย่างของซอฟต์แวร์บางตัวที่ฉันพบว่าอันตราย (พฤติกรรมไม่ใช่ซอฟต์แวร์) พฤติกรรมแบบไหนที่ทำให้คุณคิดว่ามันฟังดูไม่ดีนัก

ในกรณีนี้ผมก็สะท้อนให้เห็นถึงการตั้งค่าทั่วไปของ SSH ที่ช่วยให้การส่งผ่านตัวแปรสภาพแวดล้อม unsanitised LC_จากลูกค้าที่มีให้เริ่มต้นชื่อของพวกเขาด้วย ความคิดคือเพื่อให้ผู้คนสามารถใช้ภาษาของตัวเองเมื่อsshเข้าไปในเครื่องอื่น ๆ เป็นความคิดที่ดีจนกระทั่งคุณเริ่มพิจารณาว่าการจัดการโลคัลไลเซชั่นมีความซับซ้อนโดยเฉพาะอย่างยิ่งเมื่อนำ UTF-8 มาใช้ในสมการ

ย้อนกลับไปในเดือนกรกฎาคม 2557 ฉันได้รายงานช่องโหว่ในการจัดการ glibc ซึ่งรวมกับการกำหนดค่านั้นsshd และพฤติกรรมอันตรายอีกสองอย่างของbashเชลล์ ทำให้ผู้โจมตี (รับรองความถูกต้อง) ทำการแฮ็คเข้าสู่เซิร์ฟเวอร์ git หากพวกเขาสามารถอัพโหลดไฟล์bashได้ เป็นเชลล์ล็อกอินของผู้ใช้ git unix (CVE-2014-0475)

ฉันคิดว่ามันอาจเป็นความคิดที่ดีที่จะใช้bashเป็นเชลล์ล็อกอินของผู้ใช้ที่ให้บริการผ่าน ssh เนื่องจากมันค่อนข้างซับซ้อนเชลล์ (เมื่อสิ่งที่คุณต้องการคือการแยกวิเคราะห์บรรทัดคำสั่งที่ง่ายมาก) และได้สืบทอดการออกแบบผิดส่วนใหญ่ ของ ksh เนื่องจากฉันได้ระบุปัญหาเล็กน้อยเกี่ยวกับbashการใช้ในบริบทนั้น (เพื่อตีความ ssh ForceCommand) ฉันจึงสงสัยว่าอาจมีมากกว่านั้นหรือไม่

AcceptEnv LC_*ช่วยให้ตัวแปรใด ๆ ที่มีชื่อขึ้นต้นด้วยLC_และผมมีความทรงจำที่คลุมเครือว่าbash ฟังก์ชั่นการส่งออก (เป็นอันตรายแม้ว่าในเวลาคุณลักษณะที่มีประโยชน์) ได้ใช้ตัวแปรสภาพแวดล้อมที่มีชื่อเป็นสิ่งที่ชอบ myfunction()และถูกสงสัยว่าถ้ามีไม่ใช่สิ่งที่น่าสนใจที่จะดูที่มี

ฉันกำลังจะยกเลิกมันบนพื้นดินที่สิ่งที่แย่ที่สุดที่เราสามารถทำได้คือการกำหนดคำสั่งใหม่LC_something ที่ไม่สามารถเป็นปัญหาได้จริง ๆ เพราะสิ่งเหล่านั้นไม่ใช่ชื่อคำสั่งที่มีอยู่ แต่แล้วฉันก็เริ่มสงสัยว่าbash การนำเข้าตัวแปรสภาพแวดล้อมเหล่านั้นอย่างไร

เกิดอะไรขึ้นถ้าตัวแปรถูกเรียกLC_foo;echo test; f()เช่น? ดังนั้นฉันจึงตัดสินใจที่จะมองใกล้

A:

$ env -i bash -c 'zzz() { :;}; export -f zzz; env'
[...]
zzz=() {  :
}

เปิดเผยว่าการจำของฉันผิดที่ตัวแปรไม่ได้ถูกเรียกmyfunction()แต่myfunction(และเป็น ค่าที่ขึ้นต้นด้วย())

และทดสอบอย่างรวดเร็ว:

$ env 'true;echo test; f=() { :;}' bash -c :
test
bash: error importing function definition for `true;echo test; f'

ได้รับการยืนยันความสงสัยของฉันที่ชื่อตัวแปรที่ไม่ได้ปรุงแต่งและรหัสที่ถูกประเมินเมื่อเริ่มต้น

ที่เลวร้ายยิ่งกว่านั้นคือมูลค่าก็ไม่ได้ถูกทำให้บริสุทธิ์เช่นกัน:

$ env 'foo=() { :;}; echo test' bash -c :
test

นั่นหมายความว่าตัวแปรสภาพแวดล้อมใด ๆอาจเป็นเวกเตอร์

นั่นคือเมื่อฉันตระหนักถึงขอบเขตของปัญหายืนยันว่ามันเป็นประโยชน์ผ่าน HTTP เช่นกัน ( HTTP_xxx/ QUERYSTRING... env vars), อื่น ๆ เช่นบริการประมวลผลจดหมาย DHCP ภายหลัง (และอาจเป็นรายการยาว) และรายงาน (อย่างระมัดระวัง) .