ylai@lemmy.ml to cybersecurity@infosec.pubEnglish · 8 months agoMicrosoft waited 6 months to patch actively exploited admin-to-kernel vulnerabilitywww.theregister.comexternal-linkmessage-square7fedilinkarrow-up167arrow-down15
arrow-up162arrow-down1external-linkMicrosoft waited 6 months to patch actively exploited admin-to-kernel vulnerabilitywww.theregister.comylai@lemmy.ml to cybersecurity@infosec.pubEnglish · 8 months agomessage-square7fedilink
minus-squareThe Stoned Hacker@lemmy.worldlinkfedilinkEnglisharrow-up2·8 months agodepends, they can also loaded via dkms which may not require it
minus-squareSkull giver@popplesburger.hilciferous.nllinkfedilinkEnglisharrow-up2·8 months agodeleted by creator
minus-squareThe Stoned Hacker@lemmy.worldlinkfedilinkEnglisharrow-up2·8 months agoIt kinda depends, on custom kernels DKMS can be incredibly helpful. Like for a hardened kernel, a lot of drivers may be loaded via DKMS.
minus-squareJustin@lemmy.jlh.namelinkfedilinkEnglisharrow-up1·8 months agoYeah, it actually looks like Ubuntu leaves the module signing key accessible to root on the filesystem: https://wiki.ubuntu.com/UEFI/SecureBoot#Security_implications_in_Machine-Owner_Key_management So root access basically gives you kernel access, if you just sign a malicious kernel module with the MOK.
depends, they can also loaded via dkms which may not require it
deleted by creator
It kinda depends, on custom kernels DKMS can be incredibly helpful. Like for a hardened kernel, a lot of drivers may be loaded via DKMS.
Yeah, it actually looks like Ubuntu leaves the module signing key accessible to root on the filesystem:
https://wiki.ubuntu.com/UEFI/SecureBoot#Security_implications_in_Machine-Owner_Key_management
So root access basically gives you kernel access, if you just sign a malicious kernel module with the MOK.