לפני זמן מה יצא לי לקרוא על BADBIOS - מדובר על נוזקה שמדביקה את UEFI ו BIOS ומספר חוקרים טענו שבעוד שהנוזקה אפשרית (טכנית) הם מפקפקים בדיווח ,
אתמול ידידי שלח לי קישור מעניין על BADUSB שבסופו של יום מדובר על שיטה להחזיק נוזקות על התקני USB ולמשתמשהפשוט (בנינו רוב המשתמשים) אין ממש שום דרך להתגונן כנגד זה.
ואז נזכרתי שגם בהפצה שלי אין הרבה מה לעשות פרט למניעה פיזית של הדבר הזה , כלומר נכון שיש את polkit ואת sudo אבל כל זה חסר משמעות אם מתקבלת גישה זהה למשתמש הנוכחי.
בגלל שיש לי די הרבה מקרים שנדבקים בכל מני נוזקות (רשת תאגידית מסוימת שידועה בהדבקות שם) ,חשבתי לכל הפחות להתגונן קצת.
חשבתי לאסור על מודלים מסוימים לעלות לקרנל מה שחשבתי עליו הוא (שזה אמור לחסום כמעט הכל יעזור רק אם לא תתבצע טעינה משנית (ההארה של צפריר) :
ולשנות חוקי udev שימנעו העלאה של תהליכים אחרים.
ב wired דיווחו כי כביכול אחת הדוברת אמרה בהקשר של הפיטצר המדובר :
Liz Nardozza responded in a statement. “Consumers should always ensure their devices are from a trusted source and that only trusted sources interact with their devices,”
אתמול ידידי שלח לי קישור מעניין על BADUSB שבסופו של יום מדובר על שיטה להחזיק נוזקות על התקני USB ולמשתמש
ואז נזכרתי שגם בהפצה שלי אין הרבה מה לעשות פרט למניעה פיזית של הדבר הזה , כלומר נכון שיש את polkit ואת sudo אבל כל זה חסר משמעות אם מתקבלת גישה זהה למשתמש הנוכחי.
בגלל שיש לי די הרבה מקרים שנדבקים בכל מני נוזקות (רשת תאגידית מסוימת שידועה בהדבקות שם) ,חשבתי לכל הפחות להתגונן קצת.
חשבתי לאסור על מודלים מסוימים לעלות לקרנל מה שחשבתי עליו הוא (
blacklist rndis_host blacklist rndis_wlan blacklist cdc_ether blacklist ohci_hcd blacklist ehci_hcd blacklist ehci_pci blacklist gspca_main blacklist cdc_phonet blacklist cdc_acm blacklist cdc_ether blacklist usbfs blacklist usbnet blacklist usbhid blacklist usbcore
עריכה -
1. צפריר אומר שזה לא יפתור את הבעיה של מניעת עליית מודולים (ראו תגובה מצורפת)
2. קולגה נוסף מסר שההתקפה זו איננה חדשה (Netragard ביצעו זאת בעבר) ומניעת עליית מודולים תקפה רק עבור התקפות ברמת מערכת הפעלה, זה לא יפתור התקפות שעובדות מתחת למערכת ההפעלה (הסבר שלי דוגמה כמו בהתקפות DMA או הגנה מפני גניבה )
ולשנות חוקי udev שימנעו העלאה של תהליכים אחרים.
ב wired דיווחו כי כביכול אחת הדוברת אמרה בהקשר של הפיטצר המדובר :
Liz Nardozza responded in a statement. “Consumers should always ensure their devices are from a trusted source and that only trusted sources interact with their devices,”
2 תגובות:
הרבה יותר פשוט - אל תעבוד עם sudo.
מקבלים גישה זהה למשתמש הנוכחי, אם הגישה שלו לא מאפשרת sudo, הם יכולים לפגוע במשתמש, אבל לא בשאר המערכת.
הודעה שמעביר דרך מייל
Blacklisting a module does not prevent it from loading. It merely
prevents it from being loaded as an alias on a bus. For instance, on my
system:
$ lspci -knn | tail -n3
0c:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme
BCM5761 Gigabit Ethernet PCIe [14e4:1681] (rev 10)
Subsystem: Dell Device [1028:053d]
Kernel driver in use: tg3
$ /sbin/modinfo tg3 | grep 1681
alias: pci:v000014E4d00001681sv*sd*bc*sc*i*
That is, the driver claims to attempt to handle PCI devices with vendor
ID 14E4 and device ID 1681 (and with and sub-vendor ID, sub-device ID,
and I'm not sure what bc, sc and i are, but at least some of them should
be related to device class).
OTOH, when this module loads, it pulls some other modules with it:
$ /sbin/modinfo tg3 | grep depends:
depends: libphy
If you blacklist tg3, an attempt to modprobe
'pci:v000014E4d00001681sv*sd*bc*sc*i*' will do nothing. But a direct
modprobe of tg3 will load it. If you blacklist libphy it would have no
effect as tg3 depends on it by a direct name and not on any alias of it.
If you want to prevent a module from loading, use something along the
lines of:
# or should it be 'false' instead?
install libphy /bin/true
Note that modprobe.d(5) claims that this option is deprecated. .
הוסף רשומת תגובה