Có phải hành vi “tấn công cấu trúc” không được xác định về mặt kỹ thuật không?

Điều tôi đang hỏi là thủ thuật "thành viên cuối cùng của cấu trúc có độ dài thay đổi" nổi tiếng. Nó đi một cái gì đó như thế này:

struct T {
    int len;
    char s[1];
};

struct T *p = malloc(sizeof(struct T) + 100);
p->len = 100;
strcpy(p->s, "hello world");

Do cách cấu trúc được trình bày trong bộ nhớ, chúng ta có thể phủ cấu trúc lên một khối lớn hơn cần thiết và coi thành viên cuối cùng như thể nó lớn hơn khối đã 1 charchỉ định.

Vì vậy, câu hỏi đặt ra là: Liệu kỹ thuật này có phải là hành vi không xác định về mặt kỹ thuật không? . Tôi mong đợi điều đó đúng, nhưng tò mò không biết tiêu chuẩn nói gì về điều này.

Tái bút: Tôi biết về cách tiếp cận C99 cho điều này, tôi muốn câu trả lời cụ thể vào phiên bản của thủ thuật như được liệt kê ở trên.

Như Câu hỏi thường gặp về C nói:

Không rõ nó hợp pháp hay xách tay, nhưng nó khá phổ biến.

và:

... một cách giải thích chính thức đã cho rằng nó không hoàn toàn phù hợp với Tiêu chuẩn C, mặc dù nó dường như hoạt động theo tất cả các cách triển khai đã biết. (Các trình biên dịch kiểm tra giới hạn mảng cẩn thận có thể đưa ra cảnh báo.)

Lý do đằng sau bit 'tuân thủ nghiêm ngặt' là trong thông số kỹ thuật, phần J.2 Hành vi không xác định , bao gồm trong danh sách các hành vi không xác định:

• Một chỉ số con của mảng nằm ngoài phạm vi, ngay cả khi một đối tượng rõ ràng là có thể truy cập được với chỉ số con đã cho (như trong biểu thức giá trị a[1][7]được đưa ra khai báo int a[4][5]) (6.5.6).

Đoạn 8 của Phần 6.5.6 Các toán tử cộng có một đề cập khác rằng quyền truy cập vượt quá giới hạn mảng đã xác định là không xác định:

Nếu cả toán hạng con trỏ và kết quả đều trỏ đến các phần tử của cùng một đối tượng mảng hoặc một phần tử vượt qua phần tử cuối cùng của đối tượng mảng, thì phép đánh giá sẽ không tạo ra lỗi tràn; nếu không, hành vi là không xác định.

Tôi tin rằng về mặt kỹ thuật đó là hành vi không xác định. Tiêu chuẩn (có thể cho là) ​​không đề cập trực tiếp đến vấn đề này, vì vậy tiêu chuẩn này thuộc "hoặc do bỏ qua bất kỳ định nghĩa rõ ràng nào về hành vi." mệnh đề (§4 / 2 của C99, §3.16 / 2 của C89) nói rằng đó là hành vi không xác định.

"Có thể cho là" ở trên phụ thuộc vào định nghĩa của toán tử chỉ số mảng. Cụ thể, nó nói: "Một biểu thức hậu tố theo sau là một biểu thức trong dấu ngoặc vuông [] là một ký hiệu được chỉ định dưới dạng ký hiệu của một đối tượng mảng." (C89, §6.3.2.1 / 2).

Bạn có thể lập luận rằng "của một đối tượng mảng" đang bị vi phạm ở đây (vì bạn đang viết chỉ mục bên ngoài phạm vi đã xác định của đối tượng mảng), trong trường hợp đó, hành vi (một chút nữa) là không xác định rõ ràng, thay vì chỉ không xác định lịch sự của không có gì hoàn toàn xác định nó.

Về lý thuyết, tôi có thể tưởng tượng một trình biên dịch thực hiện kiểm tra giới hạn mảng và (ví dụ) sẽ hủy bỏ chương trình khi / nếu bạn cố gắng sử dụng chỉ số con nằm ngoài phạm vi. Trên thực tế, tôi không biết có một thứ như vậy đang tồn tại và với sự phổ biến của kiểu mã này, ngay cả khi một trình biên dịch cố gắng thực thi các chỉ số phụ trong một số trường hợp, thật khó để tưởng tượng rằng có ai đó sẽ làm như vậy trong tình huống này.

Vâng, đó là hành vi không xác định.

Báo cáo Lỗi Ngôn ngữ C # 051 đưa ra câu trả lời dứt khoát cho câu hỏi này:

Thành ngữ, trong khi phổ biến, không hoàn toàn phù hợp

http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_051.html

Trong tài liệu Cơ sở lý luận C99, Ủy ban C bổ sung:

Tính hợp lệ của cấu trúc này luôn bị nghi ngờ. Trong phản hồi cho một Báo cáo Lỗi, Ủy ban đã quyết định rằng đó là hành vi không xác định vì mảng p-> các mục chỉ chứa một mục, bất kể có tồn tại không gian hay không.

Cách thực hiện cụ thể đó không được xác định rõ ràng trong bất kỳ tiêu chuẩn C nào, nhưng C99 có bao gồm "struct hack" như một phần của ngôn ngữ. Trong C99, thành viên cuối cùng của một cấu trúc có thể là một "thành viên mảng linh hoạt", được khai báo là char foo[](với bất kỳ kiểu nào bạn muốn thay thế char).

Đó không phải là hành vi không xác định , bất kể bất kỳ ai, quan chức hay người khác , nói gì, bởi vì nó được định nghĩa bởi tiêu chuẩn. p->s, ngoại trừ khi được sử dụng làm giá trị, đánh giá một con trỏ giống hệt với (char *)p + offsetof(struct T, s). Đặc biệt, đây là một charcon trỏ hợp lệ bên trong đối tượng malloc'd và có 100 (hoặc nhiều hơn, phụ thuộc vào việc cân nhắc căn chỉnh) địa chỉ kế tiếp ngay sau nó, cũng có giá trị như charcác đối tượng bên trong đối tượng được cấp phát. Thực tế là con trỏ được tạo ra bằng cách sử dụng ->thay vì thêm rõ ràng phần bù vào con trỏ được trả về malloc, ép kiểu char *, là không liên quan.

Về mặt kỹ thuật, p->s[0]là một phần tử duy nhất của charmảng bên trong cấu trúc, một vài phần tử tiếp theo (ví dụ: p->s[1]thông qua p->s[3]) có thể là các byte đệm bên trong cấu trúc, có thể bị hỏng nếu bạn thực hiện gán cho toàn bộ cấu trúc nhưng không phải nếu bạn chỉ truy cập riêng lẻ các thành viên và phần còn lại là không gian bổ sung trong đối tượng được cấp phát mà bạn có thể tự do sử dụng theo cách bạn muốn, miễn là bạn tuân theo các yêu cầu về căn chỉnh (và charkhông có yêu cầu về căn chỉnh).

Nếu bạn lo lắng rằng khả năng chồng chéo với các byte đệm trong cấu trúc bằng cách nào đó có thể gọi ra quỷ mũi, bạn có thể tránh điều này bằng cách thay thế 1in [1]bằng một giá trị đảm bảo rằng không có phần đệm ở cuối cấu trúc. Một cách đơn giản nhưng lãng phí để làm điều này là tạo một cấu trúc với các thành viên giống hệt nhau ngoại trừ không có mảng nào ở cuối và sử dụng s[sizeof struct that_other_struct];cho mảng. Sau đó, p->s[i]được xác định rõ ràng là một phần tử của mảng trong struct for i<sizeof struct that_other_structvà như một đối tượng char tại một địa chỉ theo sau phần cuối của struct for i>=sizeof struct that_other_struct.

Chỉnh sửa: Trên thực tế, trong thủ thuật trên để có được kích thước phù hợp, bạn cũng có thể cần đặt một liên hợp chứa mọi kiểu đơn giản trước mảng, để đảm bảo rằng bản thân mảng bắt đầu với căn chỉnh tối đa thay vì ở giữa phần đệm của một số phần tử khác . Một lần nữa, tôi không tin rằng bất kỳ điều nào trong số này là cần thiết, nhưng tôi đang cung cấp nó cho những luật sư ngôn ngữ hoang tưởng nhất ngoài kia.

Chỉnh sửa 2: Sự chồng chéo với các byte đệm chắc chắn không phải là vấn đề, do một phần khác của tiêu chuẩn. C yêu cầu rằng nếu hai cấu trúc đồng ý trong một dãy con ban đầu của các phần tử của chúng, các phần tử ban đầu chung có thể được truy cập thông qua một con trỏ tới một trong hai kiểu. Do đó, nếu một cấu trúc giống hệt struct Tnhưng có mảng cuối cùng lớn hơn được khai báo, thì phần tử s[0]sẽ phải trùng với phần tử s[0]trong struct Tvà sự hiện diện của các phần tử bổ sung này không thể ảnh hưởng hoặc bị ảnh hưởng khi truy cập các phần tử chung của cấu trúc lớn hơn bằng cách sử dụng một con trỏ tới struct T.

Vâng, đó là hành vi không xác định về mặt kỹ thuật.

Lưu ý rằng có ít nhất ba cách để thực hiện "struct hack":

(1) Khai báo mảng theo sau với kích thước 0 (cách "phổ biến" nhất trong mã kế thừa). Đây rõ ràng là UB, vì khai báo mảng kích thước 0 luôn không hợp lệ trong C. Ngay cả khi nó biên dịch, ngôn ngữ này không đảm bảo về hành vi của bất kỳ mã vi phạm ràng buộc nào.

(2) Khai báo mảng với kích thước hợp pháp tối thiểu - 1 (trường hợp của bạn). Trong trường hợp này, bất kỳ nỗ lực nào để lấy con trỏ đến p->s[0]và sử dụng nó cho số học con trỏ vượt ra ngoài p->s[1]là hành vi không xác định. Ví dụ: triển khai gỡ lỗi được phép tạo ra một con trỏ đặc biệt với thông tin phạm vi được nhúng, con trỏ này sẽ mắc bẫy mỗi khi bạn cố gắng tạo một con trỏ vượt quá p->s[1].

(3) Khai báo mảng có kích thước "rất lớn" như 10000 chẳng hạn. Ý tưởng là kích thước được khai báo phải lớn hơn bất cứ thứ gì bạn có thể cần trong thực tế. Phương pháp này không có UB liên quan đến phạm vi truy cập mảng. Tuy nhiên, trong thực tế, tất nhiên, chúng tôi sẽ luôn phân bổ lượng bộ nhớ nhỏ hơn (chỉ nhiều khi thực sự cần thiết). Tôi không chắc về tính hợp pháp của điều này, tức là tôi tự hỏi việc phân bổ ít bộ nhớ cho đối tượng hơn kích thước đã khai báo của đối tượng là hợp pháp như thế nào (giả sử chúng ta không bao giờ truy cập vào các thành viên "không được cấp phát").

Tiêu chuẩn khá rõ ràng rằng bạn không thể truy cập những thứ bên cạnh phần cuối của một mảng. (và đi qua con trỏ không giúp ích gì, vì bạn không được phép tăng thậm chí con trỏ qua một sau khi kết thúc mảng).

Và để "làm việc trong thực tế". Tôi đã thấy trình tối ưu hóa gcc / g ++ sử dụng phần này của tiêu chuẩn, do đó tạo ra mã sai khi gặp C không hợp lệ này.

Nếu một trình biên dịch chấp nhận một cái gì đó như

typedef struct {
  int len;
  char dat [];
};

Tôi nghĩ khá rõ ràng rằng nó phải sẵn sàng chấp nhận một chỉ số phụ trên 'dat' vượt quá độ dài của nó. Mặt khác, nếu ai đó mã một cái gì đó như:

typedef struct {
  int bất cứ điều gì;
  char dat [1];
} HƯỚNG DẪN CỦA TÔI;

và sau đó truy cập somestruct-> dat [x]; Tôi sẽ không nghĩ rằng trình biên dịch có bất kỳ nghĩa vụ nào phải sử dụng mã tính toán địa chỉ sẽ hoạt động với các giá trị lớn của x. Tôi nghĩ nếu một người muốn thực sự an toàn, mô hình phù hợp sẽ giống như:

#define LARGEST_DAT_SIZE 0xF000
typedef struct {
  int bất cứ điều gì;
  char dat [LARGEST_DAT_SIZE];
} HƯỚNG DẪN CỦA TÔI;

và sau đó thực hiện malloc gồm (sizeof (MYTHER) -LARGEST_DAT_SIZE + mong muốn_array_length) byte (lưu ý rằng nếu mong muốn_array_length lớn hơn LARGEST_DAT_SIZE, kết quả có thể không được xác định).

Ngẫu nhiên, tôi nghĩ quyết định cấm mảng độ dài bằng 0 là một điều không may (một số phương ngữ cũ hơn như Turbo C hỗ trợ nó) vì mảng độ dài bằng 0 có thể được coi là dấu hiệu cho thấy trình biên dịch phải tạo mã sẽ hoạt động với các chỉ số lớn hơn .