สรุปสั้น

ทีม Varonis Threat Labs ของบริษัท Varonis แสดงให้เห็นว่าบัญชีฐานข้อมูลสิทธิ์จำกัดบน Snowflake Postgres ซึ่งเป็นบริการ PostgreSQL แบบ managed ของบริษัท Snowflake สามารถยกระดับจนควบคุมเซิร์ฟเวอร์ที่รันฐานข้อมูลได้ นักวิจัยร้อยฟีเจอร์ในตัวของ PostgreSQL หลายตัวเข้าด้วยกันจนรันคำสั่งระดับระบบปฏิบัติการได้ ทั้งที่ Snowflake บล็อกช่องทางทั่วไปสำหรับรันคำสั่งและเข้าถึงไฟล์ผ่าน SQL ไว้แล้ว จุดเริ่มต้นคือบัญชี snowflake_admin ซึ่งไม่ใช่ superuser แต่มีสิทธิ์ CREATEROLE ที่ลำพังตัวเองไม่ได้ให้อำนาจควบคุมฐานข้อมูลทั้งหมด แต่กลับเปิดทางผ่านฟีเจอร์อื่นที่ฐานข้อมูลไว้วางใจ

Varonis รายงานต่อ Snowflake เมื่อ 31 พฤษภาคม 2569 Snowflake รับทราบวันที่ 1 มิถุนายน และยืนยันเมื่อ 9 มิถุนายนว่าการรันโค้ดภายในเครื่องเสมือนของ Snowflake Postgres ถือเป็นการข้ามขอบเขตความปลอดภัย บริษัทแก้ไขฝั่งเซิร์ฟเวอร์แล้วก่อนงานวิจัยเผยแพร่เมื่อ 17 ตุลาคม 2569 ลูกค้าจึงไม่ต้องดำเนินการเพิ่มเติม และการทดสอบทั้งหมดอยู่ในสภาพแวดล้อมแบบ single-tenant ของนักวิจัยเอง ไม่มีรายงานว่าข้อมูลลูกค้าถูกเข้าถึง

รายละเอียดข่าว

เว็บไซต์ GBHackers รายงานเมื่อวันที่ 19 ตุลาคม 2569 ว่า งานวิจัยนี้ไม่ได้เกี่ยวกับมัลแวร์หรือช่องโหว่ใหม่เพียงจุดเดียว แต่เป็นห่วงโซ่ของพฤติกรรมของ PostgreSQL ที่ทำงานตามที่ออกแบบไว้ เมื่อนำมาต่อกันจึงกลายเป็นเส้นทางยกระดับสิทธิ์ ข้อสรุปสำคัญคือการบล็อกฟังก์ชันที่รู้จักกันดีสำหรับเชื่อม SQL กับระบบปฏิบัติการอาจไม่เพียงพอ หากความสามารถที่เกี่ยวข้องยังเข้าถึงได้จากเส้นทางอื่น

ประเด็นนี้สำคัญสำหรับบริการฐานข้อมูลแบบ managed เพราะผู้ให้บริการควบคุมเซิร์ฟเวอร์และระบบปฏิบัติการ แต่ลูกค้ายังเป็นผู้กำหนดว่าจะให้ role ใดแก่ใคร Varonis ระบุว่าความเสี่ยงแบบเดียวกันจากฐานข้อมูลสู่เซิร์ฟเวอร์เคยปรากฏในบริบทอื่นมาแล้ว เช่น ช่องโหว่รันโค้ดใน PostgreSQL และช่องโหว่รันคำสั่ง shell ใน pgAdmin

รายละเอียดช่องโหว่

ห่วงโซ่การยกระดับสิทธิ์มีขั้นตอนดังนี้

  1. CREATEROLE → อ่านเขียนข้อมูลทั้งหมด — ใช้สิทธิ์ CREATEROLE มอบ role ในตัว pg_read_all_data และ pg_write_all_data ให้บัญชีเริ่มต้น ซึ่งให้สิทธิ์เข้าถึงตารางและ system catalog อย่างกว้าง
  2. แก้งานตั้งเวลาใน pg_cron — ใช้สิทธิ์เขียนแก้รายการใน pg_cron (ส่วนขยายตั้งเวลารันงาน) ให้งานหนึ่งรันในนามบัญชี postgres ที่มีสิทธิ์สูงสุด
  3. SECURITY DEFINER → superuser — งานตั้งเวลาสร้างฟังก์ชันแบบ SECURITY DEFINER ซึ่งรันด้วยสิทธิ์ของเจ้าของแทนผู้เรียก นักวิจัยใช้ฟังก์ชันนี้ได้สิทธิ์ superuser โดยไม่ต้องใช้การเปลี่ยน role โดยตรงที่ Snowflake บล็อกไว้
  4. ผูกฟังก์ชัน C ในตัวกลับมา — สิทธิ์ superuser ยังไม่เท่ากับคุมเซิร์ฟเวอร์ เพราะ Snowflake บล็อกคำสั่งอ่านไฟล์ แก้การตั้งค่าระบบ และรันโปรแกรมผ่าน SQL ไว้ แต่ภาษาภายในของ PostgreSQL ผูกชื่อฟังก์ชันใหม่เข้ากับฟังก์ชัน C ที่มีอยู่แล้วในซอฟต์แวร์เซิร์ฟเวอร์ได้ จึงได้ฟังก์ชันอ่านเขียนไฟล์ที่ถูกบล็อกกลับมาภายใต้ชื่ออื่น
  5. archive_command → รันคำสั่ง OS — ใช้ฟีเจอร์ large object เขียนลงไฟล์คอนฟิก เปลี่ยนค่า archive_command ซึ่งรันคำสั่ง shell ทุกครั้งที่ PostgreSQL archive ไฟล์ write-ahead log (WAL) เมื่อคำสั่งทำงาน นักวิจัยก็ได้การรันคำสั่งระดับระบบปฏิบัติการในนามบัญชีระบบ postgres

ผลกระทบ

หากผู้โจมตีได้สิทธิ์ลักษณะเดียวกัน อาจแก้ไขหรือทำลายไฟล์ฐานข้อมูล ขัดขวางการกู้คืน หรือแก้ไขล็อกบนเครื่องได้ และเนื่องจากกิจกรรมระดับระบบปฏิบัติการไม่ได้ผ่านคำสั่ง SQL ปกติ บันทึก audit ของฐานข้อมูลอาจไม่เห็นภาพทั้งหมด

สำหรับลูกค้า Snowflake Postgres ปัญหานี้ปิดไปแล้ว แต่องค์กรที่ดูแล PostgreSQL เองควรมองว่าเป็นบทเรียนโดยตรง เพราะสิทธิ์อย่าง CREATEROLE มักถูกมอบให้บัญชีแอปพลิเคชันโดยไม่ได้คิดว่าเป็นสิทธิ์ความเสี่ยงสูง และผู้ให้บริการ managed database รายอื่นที่ใช้วิธีบล็อกฟังก์ชันเป็นรายตัวก็อาจมีช่องว่างแบบเดียวกัน

คำแนะนำ

  • ถือว่า CREATEROLE เป็นสิทธิ์ความเสี่ยงสูง และถอดออกจากบัญชีแอปพลิเคชันที่ไม่จำเป็นต้องใช้
  • ตรวจการมอบ role โดยเฉพาะ pg_read_all_data และ pg_write_all_data ที่ไม่คาดคิด
  • ตรวจงานใน pg_cron และฟังก์ชัน SECURITY DEFINER หาการเปลี่ยนแปลงที่ไม่ได้ตั้งใจ
  • จำกัดผู้ที่สร้างฟังก์ชันภาษา internal หรือภาษา C ได้ และปกป้องไฟล์คอนฟิกของฐานข้อมูล รวมถึงเฝ้าระวังการเปลี่ยนค่า archive_command
  • แยกบริการฐานข้อมูลออกจากการเข้าถึงเครือข่ายที่ไม่จำเป็น และเก็บล็อกระดับระบบปฏิบัติการแยกจาก audit log ของฐานข้อมูล

แหล่งอ้างอิง