on
นักวิจัย Brad Spengler ผู้พัฒนาโปรแกรมด้านความปลอดภัยชื่อ grsecurity ได้เปิดเผยโค้ดใน mailing list แห่งหนึ่ง ที่เมื่อรันแล้วจะแสดงให้เห็นถึงช่องโหว่ของคอมไพเลอร์ ซึ่งเกิดจากข้ามขั้นตอนการตรวจสอบการ de-referent ของ NULL พอยน์เตอร์หลังจากโค้ดถูกแปลงเป็นไบนารี่โค้ดแล้ว (ดังนั้นผู้เขียนโปรแกรมไม่มีทางรู้แน่ๆ เนื่องจากมันไม่ได้ปรากฏอยู่ในโค้ดที่เขียน) ทำให้เคอร์เนลของลินุกซ์พยายามที่จะอ่านหรือเขียนข้อมูลตำแหน่งหน่วยความจำที่ 0x00000000 เปิดโอกาสให้ผู้ไม่ประสงค์ดีสามารถมีสิทธิ์เข้าควบคุมในระดับ root ได้จากจุดนี้ (ลองอ่านเพิ่มเติมได้ใน ComputerWorld)
โดยลินุกซ์ที่ได้รับผลกระทบคือ 2.6.30 และ 2.6.18 (ทั้งระบบปฏิบัติการ 32 และ 64 บิต) โดยเคอร์เนล 2.6.18 นั้นถูกใช้อยู่ใน Red Hat Enterprise Linux 5
นอกจากนั้นยังสามารถใช้การประมวลผล arbitrary code เพื่อยกเลิกฟีเจอร์ด้านความปลอดภัย อาทิ การ auditing ใน Security-Enhanced Linux (SELinux), AppArmor และ Linux Security Module ได้ด้วย โดยนักวิจัยผู้นั้นได้กล่าวว่าหากใช้ SELinux กลับจะช่วยให้ผลกระทบจากข้อผิดพลาดดังกล่าว "รุนแรงขึ้น"
ข้อคิดเห็นผู้เขียนข่าวลง Blognone: ตามที่ผมเข้าใจ ปัญหานี้เป็นปัญหาร่วมกันระหว่างคอมไพเลอร์กับลินุกซ์ที่ "อาจ" ไปเชื่อใจการทำงานของคอมไพเลอร์มากเกินไป โดยปล่อยให้คอมไพเลอร์ทำการตรวจสอบให้ แล้วเคอร์เนลของลินุกซ์ก็ทำหน้าที่ประมวลผลไปตามนั้นอย่างเดียว เทียบกับระบบปฏิบัติการวินโดวส์ที่จะมีการตรวจสอบด้วย อาทิ ฟีเจอร์ Data Execution Prevention (DEP) ที่ทำงานร่วมกับฮาร์ดแวร์ หรือ Pretected Mode ในอินเทอร์เน็ตเอกซ์พลอเรอร์ เป็นต้น
ที่มา: C|Net, SANS Internet Storm Center ผ่าน ComputerWorld
ผมอ่านแล้
mk Wed, 07/22/2009 - 10:04
ผมอ่านแล้วยังไม่เข้าใจว่า เนื้อข่าวมันเกี่ยวอะไรกับ zero-day flaw อ่านที่อธิบายการทำงานของช่องโหว่นี้ ยังไม่เข้าใจว่ามันทำงานอย่างไร ลองปรับแก้ให้อ่านเข้าใจง่ายดู
แก้แล้วคร
nuntawat Wed, 07/22/2009 - 10:40
In reply to ผมอ่านแล้ by mk
แก้แล้วครับ ลองดูครับ
ป.ล.1 ผมลืมคำว่า "ช่องโหว่" ไปเลย นึกอยู่ตั้งนาน ^^"
ป.ล.2 พอดีผมก็ไม่ได้ใช้งานลินุกซ์ซะด้วย คำศัพท์บางคำถ้าพูดแล้วอาจต้องอธิบายกันยาว (ต้องอธิบายให้ตัวเองเข้าใจก่อนด้วย) เช่น ในเนื้อหาความบอกปัญหาจะเกิดในส่วนของ net/tun implementation ผมก็คงต้องมานั่งไล่เรียงกันอีกว่ามันคืออะไร ก็เลยขอสรุปเอาไว้ที่น่าจะเข้าใจ (ตามที่แก้) แล้วกันครับ
ตามความเข
mk Wed, 07/22/2009 - 11:09
In reply to แก้แล้วคร by nuntawat
ตามความเข้าใจของผม zero-day มักจะใช้ในกรณีที่มีการโจมตีเกิดขึ้นโดยที่ผู้พัฒนาซอฟต์แวร์ไม่รู้ ซึ่งในกรณีนี้ไม่ได้มีการโจมตีที่ประสงค์ร้าย เป็นแค่การเตือนของผู้เชี่ยวชาญด้านความปลอดภัยภายนอกเท่านั้น
และเท่าที่เช็คจากแหล่งข่าวตามลิงก์ที่ให้มา มีเพียง CNET เท่านั้นที่ใช้คำว่า zero-day แถมพูดเพียงครั้งเดียวและไม่ได้เป็นหัวข่าวด้วย ผมเลยเห็นว่าหัวข่าวปัจจุบันเสี่ยงที่จะ misleading พอสมควรครับ (เพราะมันเป็นแค่ช่องโหว่ธรรมดา อีกประเด็นคือข่าวทำนองนี้มีให้เห็นบ่อยมากในวงการ security ไม่เกี่ยวกับความ "อินเทร็นด์" ตามหัวข่าวแรก "ลินุกซ์อินเทรนด์ มี "zero-day flaw" กับเขาด้วย!" แม้แต่น้อย)
แก้แล้วคร
nuntawat Wed, 07/22/2009 - 11:21
In reply to ตามความเข by mk
แก้แล้วครับ ลองดูครับ
ผมพยายามอ
lew Wed, 07/22/2009 - 11:40
In reply to แก้แล้วคร by nuntawat
ผมพยายามอ่านเรื่องนี้อีกทีแล้วยังไม่แน่ใจนักว่าตกลงแล้วปัญหาของเรื่องนี้อยู่ที่ไหนกันแน่ เพราะลินุกซ์นั้นไม่ใช่คอมไพลเลอร์ครับ
โค้ดของลินุกซ์เองสามารถคอมไพล์ด้วยคอมไพล์เลอร์อื่นได้ (Intel C++ Compuiler น่าจะคอมไพล์ผ่าน) แม้ว่าส่วนใหญ่แล้วนิยมคอมไพล์ด้วย GCC (ซึ่งอยู่ใต้ FSF ไม่เกี่ยวกับลินุกซ์)
LewCPE
ผมลองเพิ่
nuntawat Wed, 07/22/2009 - 12:04
In reply to ผมพยายามอ by lew
ผมลองเพิ่มในข่าวแล้ว ลองดูครับ
ผมเลยตามไ
mk Wed, 07/22/2009 - 19:07
In reply to ผมพยายามอ by lew
ผมเลยตามไปอ่านด้วย ในแหล่งข่าวไม่ได้ระบุว่าใช้คอมไพเลอร์อะไร เดาเอาเองว่าน่าจะเป็นธรรมชาติของคอมไพเลอร์ทุกตัว คาดว่าสาเหตุคงเป็น "ความซวย" เอ้ย เป็นสาเหตุร่วมกันระหว่างเคอร์เนลกับคอมไพเลอร์มากกว่า (ถ้ามีอย่างใดอย่างหนึ่งจะไม่เป็นปัญหา)
ถ้าเรา
ZetaSolid Wed, 07/22/2009 - 15:37
ถ้าเรา dereference null pointer นี่ มันไม่เกิด segmentation fault หรือครับ ที่ผมเคยลองมันก็ segmentation fault นะครับ ???
หรือข่าวจะบอกว่า kernel ของ linux มันไม่ได้เช็ค address ใน pointer ครับ ตัวโปรแกรมอื่นจึงสามารถ แก้ interupt vector
ที่ตำแหน่ง 0x00000000 ได้ งงอ่ะครับ ?
โค้ดตัวที
luckyman Wed, 07/22/2009 - 21:35
โค้ดตัวที่เกิดปัญหาครับ
struct sock *sk = tun->sk; // initialize sk with tun->sk
…
if (!tun)
return POLLERR; // if tun is NULL return error
ตัว optimizer ของ gcc กวาดบรรทัดด้านล่างทิ้งครับ
if (!tun)
return POLLERR;
เพราะเห็นว่า
tunไม่มีทางเป็น NULL เนื่องจากใช้ initialize ตัวแปร sk ตอนต้นฟังก์ชันไปแล้วโอ
ZetaSolid Wed, 07/22/2009 - 22:37
In reply to โค้ดตัวที by luckyman
โอ ขอบคุณครับ
เพิ่มอีกน
luckyman Thu, 07/23/2009 - 01:28
In reply to โอ by ZetaSolid
เพิ่มอีกนิด
struct sock *sk = tun->sk;จริงๆ แล้วคือ
struct sock *sk = *(tun + offsetof(*tun, sk))ดังนั้น ตำแหน่งจริงๆ จะอยู่ถัดจาก NULL มานิดหน่อย
เทคนิคที่ใช้ exploit คือ mmap หน่วยความจำ page 0
แต่ทำยังไงถึง map ได้นี่ ไม่เข้าใจเหมือนกันครับ
คือ
ZetaSolid Mon, 07/27/2009 - 09:25
In reply to เพิ่มอีกน by luckyman
คือ ก็ยังงงอยู่ดี เพราะถ้าเราแค่ assign ค่าของ pointer อ่ะ โอเคครับ แต่ทันทีที่ทำการ dereference มันควรจะเกิด exception ขึ้นมาทันทีนี่ครับ นั่นก็หมายความว่า ชี้น่ะได้
แต่ไม่น่าจะทำอะไรกับ ข้อมูลที่มันชี้อยู่ได้นะครับ ? ผมเข้าใจผิดหรือเปล่าครับ