سلام چطورین؟
یه مقدار اومدیم امروز درباره linux seccomp یا همون secure computing حرف بزنیم که اصلا چی هست.در واقع یه مکانیزمیه برای محدود کردن system call هایی که یه process میتونن کال کنن.
مثلا وقتی کد زیر اجرا میشه:
int fo = open("mamad.txt",O_RDONLY);توی این بخش یه سیسکال صدا زده میشه که
openat هستش و کارش حالا باز کردن فایله و شماره سیستکال که داره 257 هستش (توی x86_x64) و بخوایم یه مقدار دیپ تر بشیم
openat(AT_FDCWD, "mamad.txt", O_RDONLY)اجرا میشه که آرگومان های مربوط به این سیستکال هستش.
مشکل امنیتی ما چیه؟
فرض میکنیم یه نرم افزاری به اسم pdf parser ورژن mamad.2.0.2 داریم (در دست ابداع) و سیستکال هایی که درواقع این برنامه به اون نیاز داره میشه گفت چیزایی هستن که این زیر مینویسم:
read
write
openat
close
mmap
munmap
exit
شاید حالا چیزای بیشتری هم باشن ولی به نظر شما اومدن سیستکال mount , reboot , socket توی این برنامه عادیه؟
اینجاست که seccomp توی عمل میاد و میتونیم به کرنل بگیم که چه چیزهایی ALLOW و DENY هستن مثل بخش زیر:
read → ALLOW
write → ALLOW
openat → ALLOW
close → ALLOW
mmap → ALLOW
exit → ALLOW
execve → DENY
ptrace → DENY
mount → DENY
reboot → DENY
در نتیجه اگه مهاجم داخل process بیاد داداشمون
()execve صدا بزنه کرنل اون رو طبق policy که داره محدود میکنه.
در واقع seccomp چیزی نیست که توی userspace باشه و در kernel enforce میشه.(بین خودمون باشه LD_PRELOAD میشه دور زد )
یه توضیح ریز درباره LD_PRELOAD بدم و بریم برای ادامه . در واقع این یه sandboxing سمت userspace هستش که dynamic linker میگه قبل اینکه کتابخونه های معمولی بارگزاری کنی این کتابخونه هایی که میگمو بارگزاری کن و در نتیجه توابعی که در اون کتابخانه تعریف شدن override توابع اصلی می‌شن. dynamic linker چیه؟
در واقع ما دو تا linking داریم . یکی static , dynamic هستن . static میاد تمام کد و توابع داخل یه برنامه تعریف میکنه و آخر یه فایل حجم بالا بهمون میده ولی dynamic اینطور نیست و در واقع اینطوریه که من مثلا یه printf میخوام صدا بزنم پس کد
printf توی یه فایل جداگانه به اسم
libc.so.6 قرار داره و همه برنامه‌ها با هم ازش استفاده می‌کنن خب حالا LD_PRELOAD چیکار میکنه؟ این فایل so. رو قبل از libc صدا میزنهو اینطوریه:
$ LD_PRELOAD=/path/to/my.so ./myprogram
ترتیب بارگزاریش به شکل زیره:
1. ld.so اجرا میشه
2. ld.so اول my.so رو بارگذاری میکنه ← اینجا
3. ld.so بعدش libc.so.6 رو بارگذاری میکنه
4. وقتی برنامه دنبال open می‌گرده:
- اول توی my.so می‌گرده
- اگه پیدا کرد → از my.so استفاده میکنه
- اگه پیدا نکرد → میره سراغ libc
و درواقع اگه توی
my.so تابعی به اسم
open تعریف کنیم جایگزین
open اصلی میشه ولی بیاین خیلی شیک با assembly دورش بزنیم:
// bypass_preload.c
#include <sys/syscall.h>
#include <unistd.h>
int main() {
long fd = syscall(SYS_openat, AT_FDCWD, "secret.txt", O_RDONLY);
long fd2;
__asm__ volatile (
"mov $257, %%rax\n" // syscall number: openat
"mov $-100, %%rdi\n" // AT_FDCWD
"mov %1, %%rsi\n" // pathname
"mov $0, %%rdx\n" // O_RDONLY
"mov $0, %%r10\n" // mode
"syscall\n"
"mov %%rax, %0\n"
: "=r"(fd2)
: "r"("secret.txt")
: "rax", "rdi", "rsi", "rdx", "r10"
);
return 0;
}
در نتیجه
LD_PRELOAD هیچ کاری نمی‌تواند بکند چون در این مسیر، تابع
open() glibc اصلاً صدا زده نمی‌شود. مستقیم به kernel میره.
از بحث اصلی دور شدیم خواستم یکم به قدرت seccomp پی ببریم ;)
ادامه seccomp که گفته بودیم کلا توی kernel enforce میشه . seccomp می‌تواند از classic BPF برای بررسی syscall استفاده کنه و Kernel اطلاعاتی درباره syscall در اختیار filter قرار می‌دهد.
اینجا seccomp فقط اسم سیستکال هارو برسی نمیکنه و و اونا رو با syscall number میشناسه.
تا اینجا توضیخ بود و چطوریه و چیکار میکنه . الان میخوایم ببینیم چطور کار میکنه اصلا. یه جدول کوچیک پایین میکشیم یه نگاهی بهش بکنین:
sandbox.c
│
├── fork()
│
└── Child
│
├── install seccomp
│
└── execve()
│
▼
pdf-parser
بعد کد زیر اجرا میکنیم :
./sandbox ./pdf-parser malicious.pdf
داخل sandbox ما این بخشا رو داریم:
