คีส์คุก ฉันทำบล็อกโพสต์ที่ ได้แจ้งความกังวลเกี่ยวกับกระบวนการแก้ไขข้อผิดพลาด ต่อเนื่องในสาขาเสถียรของเคอร์เนลลินุกซ์และนั่นก็คือ ระบุว่ามีการแก้ไขประมาณร้อยครั้งต่อสัปดาห์ ในสาขาที่เสถียรซึ่งมากเกินไปและต้องใช้ความพยายามอย่างมากในการรักษาผลิตภัณฑ์ที่ใช้เคอร์เนลของ Linux
ตามที่ Kees, ข้ามกระบวนการจัดการข้อผิดพลาดเคอร์เนลและ เคอร์เนลขาดนักพัฒนาเพิ่มเติมอย่างน้อย 100 คน เพื่อทำงานประสานกันในด้านนี้ นอกเหนือจากการกล่าวว่าผู้พัฒนาเคอร์เนลรายใหญ่มักจะแก้ไขจุดบกพร่อง แต่ไม่มีการรับประกันว่าการแก้ไขเหล่านี้จะมีผลกับตัวแปรเคอร์เนลของบริษัทอื่น
ในการทำเช่นนั้น เขากล่าวว่าผู้ใช้ผลิตภัณฑ์ต่างๆ ที่ใช้เคอร์เนล Linux นั้นไม่มีทางควบคุมว่าจุดบกพร่องใดที่ได้รับการแก้ไข และเคอร์เนลใดที่ใช้บนอุปกรณ์ของพวกเขา ในท้ายที่สุด ผู้ขายมีหน้าที่รับผิดชอบต่อความปลอดภัยของผลิตภัณฑ์ของตน แต่ต้องเผชิญกับแพตช์ที่มีอัตราสูงมากในเคอร์เนลที่เสถียร พวกเขาต้องเผชิญกับทางเลือกในการโยกย้ายแพตช์ทั้งหมด เลือกโยกย้ายแพตช์ที่สำคัญที่สุด หรือเพิกเฉยต่อแพตช์ทั้งหมด .
นักพัฒนาเคอร์เนลต้นน้ำสามารถแก้ไขจุดบกพร่องได้ แต่พวกเขาไม่สามารถควบคุมสิ่งที่ผู้จำหน่ายดาวน์สตรีมเลือกที่จะรวมเข้ากับผลิตภัณฑ์ของตนได้ ผู้ใช้ปลายทางสามารถเลือกผลิตภัณฑ์ของตนได้ แต่โดยทั่วไปแล้วพวกเขาไม่สามารถควบคุมได้ว่าจุดบกพร่องใดที่ได้รับการแก้ไขหรือเคอร์เนลใดที่ใช้ (ปัญหาในตัวของมันเอง) ในท้ายที่สุด ผู้ขายมีหน้าที่รับผิดชอบในการรักษาความปลอดภัยของแกนผลิตภัณฑ์ของตน
คีส์คุก แนะว่าวิธีแก้ไขที่ดีที่สุดคือการถ่ายโอนเฉพาะการแก้ไขและจุดอ่อนที่สำคัญที่สุดเท่านั้นแต่ปัญหาหลักคือการแยกข้อผิดพลาดเหล่านี้ออกจากกระแสทั่วไป เนื่องจากปัญหาที่เกิดขึ้นส่วนใหญ่เป็นผลมาจากการใช้ภาษา C ซึ่งต้องใช้ความระมัดระวังอย่างมากเมื่อทำงานกับหน่วยความจำและตัวชี้
ที่แย่กว่านั้นคือ การแก้ไขช่องโหว่ที่อาจเกิดขึ้นจำนวนมากไม่ได้ติดแท็กด้วยตัวระบุ CVE หรือไม่ได้รับตัวระบุ CVE สักระยะหลังจากแพทช์ออกวางจำหน่าย
ในสภาพแวดล้อมเช่นนี้ ผู้ผลิตจะแยกการแก้ไขเล็กน้อยออกจากปัญหาด้านความปลอดภัยที่สำคัญได้ยาก จากสถิติพบว่าช่องโหว่มากกว่า 40% จะถูกลบออกก่อนการกำหนด CVE และโดยเฉลี่ยแล้วความล่าช้าระหว่างการแก้ไขและการกำหนด CVE คือสามเดือน
เป็นผลให้ ไม่มีสาขาแยกพร้อมแก้ไขจุดอ่อน และไม่ได้รับข้อมูลเกี่ยวกับการเชื่อมต่อกับความปลอดภัยของปัญหานี้ ผู้ผลิตผลิตภัณฑ์ที่ใช้เคอร์เนล Linux ต้องถ่ายโอนการแก้ไขทั้งหมดอย่างต่อเนื่อง ของสาขาใหม่ที่มั่นคง แต่งานนี้ต้องใช้แรงงานจำนวนมากและต้องเผชิญกับการต่อต้านจากบริษัทต่างๆ เนื่องจากกลัวว่าจะมีการเปลี่ยนแปลงแบบถดถอยที่อาจขัดขวางการทำงานปกติของผลิตภัณฑ์
คีย์ส คุก เชื่อว่าทางออกเดียวที่จะรักษาเคอร์เนลให้ปลอดภัยด้วยราคาที่สมเหตุสมผลในระยะยาวคือการย้ายวิศวกรแพตช์ เพื่อสร้างเคอร์เนลที่บ้าคลั่งl เพื่อทำงานร่วมกันในลักษณะที่ประสานกัน เพื่อรักษาแพทช์และช่องโหว่ในเคอร์เนลต้นน้ำ ผู้ขายหลายรายไม่ได้ใช้เคอร์เนลเวอร์ชันล่าสุดในผลิตภัณฑ์ของตนและการแก้ไขแบ็คพอร์ตด้วยตนเอง กล่าวคือ ปรากฏว่าวิศวกรจากบริษัทต่างๆ ทำซ้ำงานของกันและกัน เพื่อแก้ปัญหาเดียวกัน
ตัวอย่างเช่น ถ้าบริษัท 10 แห่ง โดยแต่ละแห่งมีวิศวกรสนับสนุนการแก้ไขแบบเดียวกัน เปลี่ยนเส้นทางวิศวกรเหล่านี้เพื่อแก้ไขจุดบกพร่องที่ต้นทาง แทนที่จะย้ายโปรแกรมแก้ไขเพียงรายการเดียว พวกเขาสามารถแก้ไขจุดบกพร่องที่แตกต่างกัน 10 รายการเพื่อประโยชน์โดยรวมหรือมารวมกันเพื่อตรวจสอบจุดบกพร่อง . และหลีกเลี่ยงการรวมรหัสบั๊กกี้ในเคอร์เนล ทรัพยากรยังสามารถใช้เพื่อสร้างเครื่องมือวิเคราะห์และทดสอบโค้ดใหม่ที่จะตรวจพบคลาสข้อผิดพลาดทั่วไปในระยะเริ่มต้นโดยอัตโนมัติซึ่งเกิดขึ้นซ้ำแล้วซ้ำอีก
คีย์ส คุก ยังเสนอให้ใช้การทดสอบอัตโนมัติและ fuzzing อย่างแข็งขันมากขึ้น โดยตรงในกระบวนการพัฒนาเคอร์เนล ใช้ระบบการรวมอย่างต่อเนื่อง และละทิ้งการจัดการแบบโบราณของการพัฒนาผ่านอีเมล
Fuente: https://security.googleblog.com