ทำไมรหัสนี้มีความเสี่ยงที่จะบัฟเฟอร์การโจมตีล้น?

int func(char* str)
{
   char buffer[100];
   unsigned short len = strlen(str);

   if(len >= 100)
   {
        return (-1);
   }

   strncpy(buffer,str,strlen(str));
   return 0;
}

รหัสนี้มีความเสี่ยงต่อการโจมตีแบบ buffer overflow และฉันพยายามหาสาเหตุ ฉันคิดว่ามันเกี่ยวกับlenการได้รับการประกาศshortแทนที่จะเป็นintแต่ฉันไม่แน่ใจจริงๆ

ความคิดใด ๆ

ในคอมไพเลอร์ส่วนใหญ่ค่าสูงสุดของunsigned shortคือ 65535

ค่าใด ๆ ข้างต้นที่ล้อมรอบดังนั้น 65536 กลายเป็น 0 และ 65600 กลายเป็น 65

ซึ่งหมายความว่าสายยาวที่มีความยาวถูกต้อง (เช่น 65600) จะผ่านการตรวจสอบและล้นบัฟเฟอร์

ใช้size_tเพื่อเก็บผลลัพธ์strlen()ไม่ใช่unsigned shortและเปรียบเทียบlenกับนิพจน์ที่เข้ารหัสขนาดbufferโดยตรง ตัวอย่างเช่น:

char buffer[100];
size_t len = strlen(str);
if (len >= sizeof(buffer) / sizeof(buffer[0]))  return -1;
memcpy(buffer, str, len + 1);

ปัญหาอยู่ที่นี่:

strncpy(buffer,str,strlen(str));
                   ^^^^^^^^^^^

หากสตริงมากกว่าความยาวของบัฟเฟอร์เป้าหมาย strncpy จะยังคงคัดลอกไป คุณกำลังอ้างอิงจำนวนอักขระของสตริงเป็นหมายเลขที่จะคัดลอกแทนขนาดของบัฟเฟอร์ วิธีที่ถูกต้องในการทำเช่นนี้มีดังนี้:

strncpy(buffer,str, sizeof(buff) - 1);
buffer[sizeof(buff) - 1] = '\0';

สิ่งนี้ทำคือ จำกัด จำนวนข้อมูลที่คัดลอกไปยังขนาดที่แท้จริงของบัฟเฟอร์ลบหนึ่งสำหรับอักขระที่ยกเลิก null จากนั้นเราจะตั้งค่าไบต์สุดท้ายในบัฟเฟอร์ให้เป็นอักขระ null เพื่อเป็นการป้องกันเพิ่มเติม เหตุผลนี้เป็นเพราะ strncpy จะคัดลอกไม่เกิน n ไบต์รวมถึงการยกเลิก null ถ้า strlen (str) <len - 1 ถ้าไม่เช่นนั้น null จะไม่ถูกคัดลอกและคุณมีสถานการณ์ความผิดพลาดเพราะตอนนี้บัฟเฟอร์ของคุณมีการทำลาย เชือก

หวังว่านี่จะช่วยได้

แก้ไข: เมื่อตรวจสอบเพิ่มเติมและป้อนข้อมูลจากผู้อื่นการเข้ารหัสที่เป็นไปได้สำหรับฟังก์ชั่นดังต่อไปนี้:

int func (char *str)
  {
    char buffer[100];
    unsigned short size = sizeof(buffer);
    unsigned short len = strlen(str);

    if (len > size - 1) return(-1);
    memcpy(buffer, str, len + 1);
    buffer[size - 1] = '\0';
    return(0);
  }

เนื่องจากเราทราบความยาวของสตริงเราจึงสามารถใช้ memcpy เพื่อคัดลอกสตริงจากตำแหน่งที่อ้างอิงโดย str ลงในบัฟเฟอร์ โปรดทราบว่าในหน้าคู่มือสำหรับ strlen (3) (บนระบบ FreeBSD 9.3) จะมีการระบุสิ่งต่อไปนี้:

 The strlen() function returns the number of characters that precede the
 terminating NUL character.  The strnlen() function returns either the
 same result as strlen() or maxlen, whichever is smaller.

ซึ่งฉันตีความว่าเป็นความยาวของสตริงที่ไม่รวมถึงโมฆะ นั่นคือเหตุผลที่ฉันคัดลอก len + 1 ไบต์เพื่อรวม null และการทดสอบตรวจสอบเพื่อให้แน่ใจว่าความยาว <ขนาดของบัฟเฟอร์ - 2 ลบหนึ่งเพราะบัฟเฟอร์เริ่มต้นที่ตำแหน่ง 0 และลบอีกหนึ่งเพื่อให้แน่ใจว่ามีที่ว่าง สำหรับ null

แก้ไข: ปรากฎขนาดของบางสิ่งเริ่มต้นด้วย 1 ในขณะที่การเข้าถึงเริ่มต้นด้วย 0 ดังนั้น -2 ก่อนหน้านี้ไม่ถูกต้องเพราะมันจะส่งกลับข้อผิดพลาดสำหรับอะไร> 98 ไบต์ แต่ควร> 99 ไบต์

แก้ไข: แม้ว่าคำตอบสั้น ๆ ที่ไม่ได้ลงชื่อจะถูกต้องเนื่องจากความยาวสูงสุดที่สามารถแสดงได้คือ 65,535 ตัวอักษร แต่ก็ไม่สำคัญเพราะหากสตริงยาวกว่านั้นค่าจะตัดไป มันเหมือนกับเอา 75,231 (ซึ่งคือ 0x000125DF) และปิดบัง 16 บิตแรกที่ให้คุณ 9695 (0x000025DF) ปัญหาเดียวที่ฉันเห็นด้วยกับเรื่องนี้เป็น 100 ตัวอักษรแรกที่ผ่านมา 65,535 การตรวจสอบความยาวจะช่วยให้คัดลอกแต่จะคัดลอกขึ้นไป 100 ตัวอักษรแรกของสตริงในทุกกรณีและ null ยุติสตริง ดังนั้นแม้จะมีปัญหาการตัดผ่านบัฟเฟอร์ยังคงไม่ถูกโอเวอร์โฟลว์

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

แม้ว่าคุณจะใช้strncpyความยาวของการตัดยอดจะขึ้นอยู่กับตัวชี้สตริงที่ส่งผ่าน คุณไม่รู้เลยว่าสตริงนั้นยาวแค่ไหน (ตำแหน่งของตัวสิ้นสุดเทอร์มินัลที่สัมพันธ์กับตัวชี้นั่นคือ) ดังนั้นการโทรstrlenเพียงอย่างเดียวจะเปิดช่องโหว่ให้คุณ หากคุณต้องการที่จะเป็นความปลอดภัยมากขึ้น, strnlen(str, 100)การใช้งาน

แก้ไขรหัสเต็มจะเป็น:

int func(char *str) {
   char buffer[100];
   unsigned short len = strnlen(str, 100); // sizeof buffer

   if (len >= 100) {
     return -1;
   }

   strcpy(buffer, str); // this is safe since null terminator is less than 100th index
   return 0;
}

คำตอบที่ถูกต้องถูกต้อง แต่มีปัญหาฉันคิดว่าไม่ได้กล่าวถึงถ้า (len> = 100)

ถ้าเลนจะเท่ากับ 100 เราจะคัดลอก 100 องค์ประกอบแล้วเราจะไม่ได้ตามท้าย \ 0 ชัดเจนว่าจะหมายถึงฟังก์ชั่นอื่น ๆ ขึ้นอยู่กับสตริงสิ้นสุดที่เหมาะสมจะเดินเกินกว่าอาร์เรย์เดิม

สตริงที่เป็นปัญหาจาก C นั้นไม่สามารถกู้คืนได้ IMHO คุณควรมีข้อ จำกัด ก่อนการโทรเสมอ แต่ถึงแม้จะไม่ช่วยก็ตาม ไม่มีการตรวจสอบขอบเขตดังนั้นบัฟเฟอร์โอเวอร์โฟลว์สามารถทำได้และน่าเสียดายที่จะเกิดขึ้น ....

นอกเหนือจากปัญหาด้านความปลอดภัยที่เกี่ยวข้องกับการโทรstrlenมากกว่าหนึ่งครั้งโดยทั่วไปแล้วไม่ควรใช้วิธีสตริงในสตริงที่มีความยาวเป็นที่รู้จักอย่างแม่นยำ [สำหรับฟังก์ชั่นสตริงส่วนใหญ่มีเพียงกรณีแคบจริง ๆ ที่ควรใช้ - บนสตริงที่มีค่าสูงสุด สามารถรับประกันความยาวได้ แต่ไม่ทราบความยาวที่แน่นอน] เมื่อทราบความยาวของสตริงอินพุตและทราบความยาวของบัฟเฟอร์เอาต์พุตแล้วควรทราบว่าควรคัดลอกพื้นที่ขนาดใหญ่เท่าใดจากนั้นใช้memcpy()เพื่อดำเนินการคัดลอกที่เป็นปัญหา แม้ว่าอาจเป็นไปได้ที่strcpyอาจมีประสิทธิภาพสูงกว่าmemcpy()เมื่อคัดลอกสตริงเพียง 1-3 ไบต์หรือมากกว่านั้น แต่ในหลาย ๆ แพลตฟอร์มmemcpy()มีแนวโน้มว่าจะเร็วกว่าสองเท่าเมื่อจัดการกับสตริงที่มีขนาดใหญ่กว่า

แม้ว่าจะมีบางสถานการณ์ที่การรักษาความปลอดภัยจะมาที่ค่าใช้จ่ายของการทำงานนี้เป็นสถานการณ์ที่วิธีการรักษาความปลอดภัยเป็นยังเร็วขึ้นหนึ่ง ในบางกรณีอาจมีเหตุผลที่จะเขียนโค้ดที่ไม่ปลอดภัยกับอินพุตที่มีพฤติกรรมแปลก ๆ หากโค้ดที่ป้อนอินพุตสามารถมั่นใจได้ว่าพวกเขาจะทำงานได้ดีและหากการปกป้องอินพุตที่ไม่ดี เพื่อให้มั่นใจว่าเชือกยาวมีการตรวจสอบเพียงครั้งเดียวช่วยเพิ่มทั้งประสิทธิภาพและความปลอดภัย แต่สิ่งที่พิเศษอย่างใดอย่างหนึ่งที่สามารถทำได้เพื่อช่วยเหลือพนักงานรักษาความปลอดภัยแม้ในขณะที่การติดตามความยาวสายด้วยตนเอง: สตริงซึ่งคาดว่าจะมี null ต่อท้ายทุกเขียน null ต่อท้ายอย่างชัดเจนมากกว่า กว่าที่คาดหวังว่าจะมีซอร์สสตริง ดังนั้นหากมีคนเขียนstrdupเทียบเท่า:

char *strdupe(char const *src)
{
  size_t len = strlen(src);
  char *dest = malloc(len+1);
  // Calculation can't wrap if string is in valid-size memory block
  if (!dest) return (OUT_OF_MEMORY(),(char*)0); 
  // OUT_OF_MEMORY is expected to halt; the return guards if it doesn't
  memcpy(dest, src, len);      
  dest[len]=0;
  return dest;
}

โปรดสังเกตว่าโดยทั่วไปคำสั่งสุดท้ายจะถูกละเว้นหาก memcpy ประมวลผลเป็นlen+1ไบต์ แต่เป็นเธรดอื่นเพื่อแก้ไขสตริงต้นทางผลลัพธ์อาจเป็นสตริงปลายทางที่ไม่สิ้นสุด NUL