Truy tìm tệp thực thi mà không có quyền đọc


17

Tôi đã tìm thấy một số hành vi đáng ngạc nhiên trên Ubuntu 14.04 khi sử dụng stracetrên một tệp thực thi mà tôi không có quyền đọc. Tôi tự hỏi nếu đây là một lỗi, hoặc nếu một số tiêu chuẩn bắt buộc hành vi tối nghĩa này.

Trước tiên hãy xem điều gì xảy ra khi tôi bắt đầu thực thi thông thường trong nền và đính kèm với nó. Như mong đợi điều này hoạt động:

$ /bin/sleep 100 &
[2] 8078
$ strace -p 8078
Process 8078 attached
restart_syscall(<... resuming interrupted call ...>

Tiếp theo tôi thử với một tệp thực thi mà tôi không có quyền đọc trên:

---x--x--x 1 root root 26280 Sep  3 09:37 sleep*

Đính kèm với quy trình chạy này không được phép:

$ ./sleep 100 &
[1] 8089
$ strace -p 8089
strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted

Đây cũng là những gì tôi mong đợi. Cấp quyền thực thi mà không có quyền đọc sẽ không có tác dụng gì nhiều, nếu tôi có thể chỉ cần đính kèm trình gỡ lỗi vào quy trình và thực sự có quyền đọc trên tệp thực thi theo cách đó.

Nhưng nếu tôi bắt đầu thực thi theo một quy trình đã được theo dõi, tôi được phép làm như vậy:

$ strace ./sleep 100
execve("./sleep", ["./sleep", "100"], [/* 69 vars */]) = 0
brk(0)                                  = 0x9b7a000

Điều này là bất ngờ đối với tôi. Đây có phải là một lỗi bảo mật, hay nó là một tính năng được ủy quyền bởi một tiêu chuẩn?


3
@ StéphaneChazelas: Vấn đề là anh ta có thể điều chỉnh nó, bằng cách đơn giản sử dụng nó làm đối số để sải bước. Nguyên nhân gốc dường như là trên execvecác cuộc gọi, quyền đọc của tệp được thực thi sẽ không được kiểm tra lại nếu quá trình đã được theo dõi. Câu hỏi của anh là liệu đó là lỗi bảo mật hay là một tính năng bắt buộc (nếu sau này, tôi vẫn coi đó là lỗi bảo mật, chỉ là lỗi bảo mật của thông số kỹ thuật).
celtschk

@celtschk, xin lỗi, tôi đọc câu hỏi quá nhanh.
Stéphane Chazelas

1
Các EPERMdường như đến từ get_dumpable()(dùng cũng để kiểm tra xem lõi bán phá giá được cho phép, do đó "dumpable") được gọi là từ __ptrace_may_access()gọi từ ptrace_attach()trên kernel/ptrace.c.
ninjalj

Khi một chương trình đang chạy, sẽ có đủ thông tin cho trình gỡ lỗi để tạo một tệp thực thi có thể chạy được chứa mã của nó hay trình tải chương trình sẽ loại bỏ những thứ như sửa lỗi di dời cần thiết để làm cho chương trình thực sự hoạt động?
supercat

@supercat Theo như tôi biết, trình gỡ lỗi có quyền truy cập vào một bước thông qua tất cả các mã chế độ người dùng đang được thực thi, bao gồm cả mã di dời. Với mức độ truy cập đó, sẽ không quá khó để tạo lại một tệp thực thi hoạt động.
kasperd

Câu trả lời:


7

Đây không phải là một câu trả lời, thay vào đó là một tập hợp các liên kết và suy nghĩ trong trường hợp người khác cũng muốn nghiên cứu. Bởi vì đây là một điều khá thú vị.

Câu trả lời liên quan trên Unix & Linux có đề cập đến nó (hoặc là, không thể kiểm tra với nhân vanilla ngay bây giờ) có thể kết xuất chỉ đọc nhị phân theo cách này.

Grsecurity đã cố gắng sửa tùy chọn cấu hình này và bản vá ( chính nó có thể đã thay đổi kể từ đó)

Cam kết này thực sự làm cho có vẻ như, các nhà phát triển hạt nhân thực sự chỉ quan tâm đến việc bán phá giá nhị phân.

Nhưng thực sự từ dòng này, tôi đoán kernel muốn ngăn chặn việc bỏ các tệp nhị phân không thể đọc được về trạng thái SUID. Và dòng này gợi ý rằng các nhị phân không thể đổ được không nên truy nguyên được.

Vì vậy, ngay từ cái nhìn đầu tiên, có vẻ như bạn đã tìm thấy một lỗi trong kernel có ý nghĩa bảo mật. Nhưng tôi không phải là nhà phát triển kernel, vì vậy tôi không thể chắc chắn. Tôi sẽ hỏi về LKML.

Chỉnh sửa: thêm một phát hiện nữa, liên quan đến trình gỡ lỗi, được đề cập trong các bình luận cho bài đăng gốc - từ bước nhanh chóng (một lần nữa) đối với tôi, gdb sử dụng các nhị phân theo dõi và /proc/<pid>/mem. Một khi nhị phân đang chạy không thể đọc được, cat /proc/<pid>/memtrả về EPERM. Nếu nhị phân có thể đọc được, nó sẽ trả về EIO. (Đã thử nghiệm điều này trên Ubuntu 14.10, chạy một số bản vá bảo mật, do đó, điều này có thể khác với nhân vanilla. Một lần nữa tôi không có nhân vanilla chạy ở bất cứ đâu tiện dụng :()

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.