تیمی از دانشگاه مینه سوتا جزئیاتی را در مورد تغییرات مخرب ارسال شده فاش کرده است.

پس از یک نامه عذرخواهی سرگشاده، گروهی از محققان دانشگاه مینه سوتا تغییرات در هسته را پذیرفتند. Linux که گرگ کروه-هارتمن دسترسی به آن را مسدود کرده بود، اطلاعات دقیقی در مورد وصله‌های ارسال شده به توسعه‌دهندگان هسته و مکاتبات با نگهدارنده‌های مربوط به این وصله‌ها را فاش کرد.

قابل ذکر است که تمامی وصله های مشکل دار به ابتکار نگهبانان رد شد و حتی یک پچ نیز تایید نشد. این واقعیت روشن می کند که چرا گرگ کروه-هارتمن اینقدر خشن عمل کرد، زیرا مشخص نیست که اگر پچ ها توسط نگهبانان تأیید می شد، محققان چه می کردند. در گذشته، آنها ادعا کردند که قصد داشتند یک باگ را گزارش کنند و اجازه نمی‌دادند وصله‌ها به Git بروند، اما مشخص نیست که واقعاً چه کاری انجام می‌دهند و تا کجا ممکن است پیش رفته باشند.

در مجموع، در آگوست ۲۰۲۰، از آدرس‌های ناشناس acostag.ubuntuپنج وصله به آدرس‌های @gmail.com و jameslouisebond@gmail.com ارسال شد (ایمیل از طرف جیمز باند بود): دو وصله صحیح (۱، ۲) و سه وصله شامل خطاهای پنهان (۱، ۲، ۳) که شرایط را برای آسیب‌پذیری‌ها ایجاد می‌کردند. هر وصله فقط شامل ۱ تا ۴ خط کد بود. ایده اصلی پشت وصله‌های اشتباه این بود که رفع نشت حافظه می‌تواند به دلیل آزادسازی دوگانه، آسیب‌پذیری ایجاد کند. یک هفته بعد، با توسعه‌دهندگان هسته تماس گرفته شد تا در مورد امکان تبلیغ آسیب‌پذیری‌ها تحت پوشش رفع نشت حافظه بی‌اهمیت صحبت شود، اما هیچ اشاره‌ای به تلاش‌های قبلی برای ارسال وصله‌های مخرب نشد.

اولین وصله مشکل ساز نشت حافظه را با افزودن یک فراخوانی به kfree() قبل از بازگشت کنترل در صورت بروز خطا برطرف کرد، اما شرایطی را برای دسترسی به ناحیه حافظه پس از آزاد شدن (استفاده پس از آزاد شدن) ایجاد کرد. این پچ توسط نگهدارنده (Jiri Slaby) رد شد، او مشکل را شناسایی کرد و اشاره کرد که یک سال پیش شخصی قبلاً سعی کرده بود تغییر مشابهی را پیشنهاد کند و در ابتدا پذیرفته شد، اما پس از شناسایی شرایط آسیب‌پذیری کنار گذاشته شد. > p2 = p1[n] = kmalloc_array(64, sizeof(u16)، GFP_KERNEL); > - اگر (!p2) بازگشت -ENOMEM; > + if (!p2) { > + kfree(p1); > + بازگشت -ENOMEM. > + }

وصله دوم همچنین شامل شرایطی برای مشکل استفاده پس از رایگان بود. پچ مشخص شده توسط نگهدارنده (دان کارپنتر) پذیرفته نشد، او به دلیل مشکل دیگری با list_add_tail پچ را رد کرد، اما متوجه نشد که نشانگر "chdev" در تابع put_device آزاد می شود که در زیر در تماس استفاده می شود. dev_err(&chdev ->dev..). با این حال، این وصله پذیرفته نشد، اگرچه به دلایلی غیر مرتبط با آسیب‌پذیری. if (ret < 0) { + put_device(&chdev->dev); dev_err(&chdev->dev, DRV_NAME ": kfifo_alloc شکست\n"); ret = -ENOMEM; goto err_fifo;

پچ سوم نیز توسط نگهدارنده (Miquel Raynal) به دلیل باگ دیگری که مربوط به آسیب پذیری نبود (دوباره برای قرار دادن برای pdev) پذیرفته نشد. if (!window->virt) { printk(KERN_ERR MOD_NAME ": ioremap(%08lx, %08lx) شکست\n", window->phys, window->size); + pci_dev_put(pdev); بیرون رفتن } ... if (!map) { printk(KERN_ERR MOD_NAME ": kmalloc شکست خورد"); + pci_dev_put(pdev); بیرون رفتن } memset(map, 0, sizeof(*map)); ... if (mtd_device_register(map->mtd, NULL, 0)) { map_destroy(map->mtd); map->mtd = NULL; + pci_dev_put(pdev); بیرون رفتن }

جالب اینجاست که در ابتدا تصور می شد از هر 4 وصله 5 مورد مشکل داشته باشد، اما خود محققین اشتباه کردند و در یکی از وصله ها که مشکل ساز بود، به نظر آنها یک راه حل درست پیشنهاد شد، بدون اینکه شرایط مورد انتظار برای استفاده از حافظه پس از رخ دادن رایگان وجود داشته باشد. err = pci_request_mem_regions (pdev, nitrox_driver_name); if (err) { pci_disable_device(pdev); + dev_err(&pdev->dev, "در خواست مناطق mem انجام نشد!\n"); بازگشت خطا؛ }

منبع: opennet.ru

خرید هاست قابل اعتماد برای سایت های دارای حفاظت DDoS، سرورهای VPS VDS 🔥 خرید هاستینگ معتبر با محافظت در برابر حملات DDoS، سرورهای VPS و VDS | ProHoster