{
	"id": "6d07a185-65a3-4588-85d9-b981f6c08ca6",
	"created_at": "2026-04-06T00:12:08.766641Z",
	"updated_at": "2026-04-10T13:12:24.816346Z",
	"deleted_at": null,
	"sha1_hash": "dd477d7227fb5d82157c2e3bfb4e0fcdb4671721",
	"title": "High Sierra's 'Secure Kernel Extension Loading' is Broken",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2341275,
	"plain_text": "High Sierra's 'Secure Kernel Extension Loading' is Broken\r\nArchived: 2026-04-05 12:40:26 UTC\r\nHigh Sierra's 'Secure Kernel Extension Loading' is Broken\r\n› a new 'security' feature in macOS 10.13, is trivial to bypass\r\n09/05/2017\r\nlove these blog posts? support my tools \u0026 writing on patreon! Mahalo :)\r\nBackground\r\nWith each new release of macOS, Apple introduces new 'built-in' security enhancements...and macOS High Sierra\r\n(10.13) is no exception.\r\nIn this blog post we'll take a brief look at High Sierra's somewhat controversial \"Secure Kernel Extension\r\nLoading\" (SKEL) feature. Unfortunately while wrapped in good intentions, in it's current implementation, SKEL\r\nmerely hampers the efforts of the 'good guys' (i.e. 3rd-party macOS developers such as those that design security\r\nproducts). Due to flaws in its implementation, the bad guys (hackers/malware) will likely remain unaffected.\r\nWhile many respected security researchers, system administrators, and macOS developers have voiced this\r\nconcern, here we'll prove this by demonstrating a 0day vulnerability in SKEL's implementation that decisively\r\nbypasses it fully:\r\n$ kextstat\r\nIndex Refs Size   Wired    Name\r\n1     90   0x9e30 0x9e30   com.apple.kpi.bsd\r\n2     8    0x3960 0x3960   com.apple.kpi.dsep\r\nhttps://objective-see.org/blog/blog_0x21.html\r\nPage 1 of 7\n\n...\r\n130   0    0x4b00 0x4b000  com.un.approved.kext\r\nDocumented in Apple's Technical Note TN2459, Secure Kernel Extension Loading, is \"a new feature that requires\r\nuser approval before loading new third-party kernel extensions.\" Other good overviews of SKEL include:\r\n\"Kextpocalypse - High Sierra and Kexts in the Enterprise\"\r\n\"Kernel extensions and macOS High Sierra\"\r\nWhile we might initially assume that that the main attack vector SKEL attempts to thwart is the (direct) loading of\r\nmalicious kernel extensions (i.e. rootkits), I believe this is not the case. First, observe that (AFAIK), we have yet\r\nto see any signed kernel-mode macOS malware! Since OS X Yosemite, any kexts have to be signed with a kernel\r\ncode-signing certificate. And unlike user-mode Developer IDs, Apple is incredibly 'protective' of such kernel\r\ncode-signing certificates - only giving out a handful to legitimate 3rd-party companies that have justifiable reasons\r\nto create kernel code. As security features are often costly to implement, they are generally introduced to\r\nreactively address widespread issues. (Unless they are introduced as a control mechanism, under the guise of a\r\n'security feature' (*cough cough*)).\r\nInstead the main (security) goal of SKEL is to block the loading of legitimate but (known) vulnerable kexts. Until\r\nApple blacklists these kexts via the OSKextExcludeList dictionary (in\r\nAppleKextExcludeList.kext/Contents/Info.plist), attackers can simply load such kexts, then exploit them to gain\r\narbitrary code execution within the context of the kernel. Note that such blacklisting is often is delayed as it can\r\nbadly break legitimate functionality until the user has upgraded to a non-blacklisted version of the kext.\r\nAbout a year ago I discussed this attack vector in my DefCon talk, \"I got 99 Problems, but Little Snitch ain’t one!\"\r\n(note: this is a well known attack vector to bypass kernel code-signing requirements on both Windows and\r\nmacOS):\r\nIn my talk, I discussed an exploitable kernel heap-overflow in LittleSnitch's kernel driver, LittleSnitch.kext. While\r\nthis bug could to be abused to escalate privileges on Macs that had LittleSnitch installed, once the vulnerability\r\nwas patched the bug didn't die. Instead, as shown on the slide, local privileged attackers could still utilize the\r\nvulnerable driver to bypass macOS's kernel code-signing requirements. The steps for this attack are as follows:\r\nhttps://objective-see.org/blog/blog_0x21.html\r\nPage 2 of 7\n\n1. With root privileges, load a vulnerable copy of the LittleSnitch.kext (versions \u003c 3.61)\r\nThis would be allowed as the vulnerable driver was still validly signed.\r\n2. Exploit the heap-overflow to gain arbitrary code execution within the kernel.\r\nHere in the kernel, one can bypass SIP, load unsigned kexts, and much more!\r\nWhile yes, \"Secure Kernel Extension Loading\" can also block the direct loading of maliciously signed kexts, it\r\nseems its main aim is to thwart the loading of known vulnerable drivers for malicious purposes.\r\nSecure Kernel Extension Loading\r\nSo what happens when a user (or installer, or malware) tries to a load a signed 3rd-party kernel extension on High\r\nSierra for the first time? Well, it will be blocked by SKEL and the user will be alerted, unless it:\r\nwas \"already installed at the time of upgrading to macOS High Sierra.\"\r\nis signed with the same Team ID as a previously approved extension.\r\nis \"replacing a previously approved extension.\"\r\n(I'm guessing based on cryptographically verifiable information such as the Team ID).\r\nis being loaded on a Mac that is enrolled with an MDM solution.\r\nFor example, here we try to manually load the latest version of LittleSnitch.kext on pristine VM instance of High\r\nSierra. Even though the kext is signed with a legitimate (non-revoked) kernel-mode signing certificate and is not\r\nblacklisted, SKEL will block it:\r\n# kextload LittleSnitch.kext\r\nLittleSnitch.kext failed to load - (libkern/kext) system policy prevents loading; check the system/kernel logs for\r\nerrors or try kextutil(8).\r\nOnce the system has blocked the kext from loading, it will also generate an alert to user:\r\nIf we monitor file system I/O during this process, we can see both the kext (LittleSnitch.kext) and what appears to\r\nbe a 'kernel policy' database, are accessed by the system policy daemon, syspolicyd:\r\nhttps://objective-see.org/blog/blog_0x21.html\r\nPage 3 of 7\n\n# fs_usage -w -f filesystem\r\n...\r\nlstat64  /Users/user/Desktop/LittleSnitch.kext  syspolicyd.11844\r\nstat64  /private/var/db/SystemPolicyConfiguration/KextPolicy  syspolicyd.11844\r\nIf we dump the 'kext policy' database (/private/var/db/SystemPolicyConfiguration/KextPolicy), we can see the\r\nLittleSnitch kext has been added to the 'kext_policy' table, but currently it is disallowed ('allowed' is set to 0):\r\n# sqlite3 /private/var/db/SystemPolicyConfiguration/KextPolicy '.dump kext_policy'\r\nCREATE TABLE kext_policy ( team_id TEXT, bundle_id TEXT, allowed BOOLEAN, developer_name TEXT,\r\n...);\r\nINSERT INTO kext_policy VALUES('MLZF7K7B5R','at.obdev.nke.LittleSnitch',0,'Objective Development\r\nSoftware GmbH',4);\r\nAs was stated in the alert shown to the user, assuming they want the (signed) kernel extension to load, they have to\r\nnow manually approve it. This is done by launching the System Preferences application (/Applications/System\r\nPreferences.app), navigating to the 'Security \u0026 Privacy' pane, and in the 'General' tab, clicking 'Allow':\r\nhttps://objective-see.org/blog/blog_0x21.html\r\nPage 4 of 7\n\nOnce the user has allowed the kext to load, the system updates the entry in the 'kext policy' database ('allowed' is\r\nset to 1) and allows the kext to load:\r\n# sqlite3 /private/var/db/SystemPolicyConfiguration/KextPolicy '.dump kext_policy'\r\nCREATE TABLE kext_policy ( team_id TEXT, bundle_id TEXT, allowed BOOLEAN, developer_name TEXT,\r\n...);\r\nINSERT INTO kext_policy VALUES('MLZF7K7B5R','at.obdev.nke.LittleSnitch',1,'Objective Development\r\nSoftware GmbH',4);\r\nExploitation\r\nNow, let's crush Secure Kernel Extension Loading 😈 Why? Not because we dislike Apple, but rather to illustrate\r\nthat in its current implementation the 'bad' guys will have no problem bypassing it. IMHO, this is important for\r\nApple to understand!\r\nOur goal here is to programmatically load a signed kext that has never been installed or loaded on the High Sierra\r\nsystem. This kext could either be a malicious, or more likely a vulnerable one that afford an attacker unfettered\r\nkernel access via exploitation. Of course, both of these attacks should be blocked by SKEL. Alas, they are not.\r\nhttps://objective-see.org/blog/blog_0x21.html\r\nPage 5 of 7\n\nIt's important to note that while it is trivial bypass SKEL, Apple did put at least a little effort into thwarting\r\nobvious bypasses.\r\nFor example, if an attacker could directly modify the 'kext policy' database, obviously they could simply 'pre-approve' kexts. In order prevent this, Apple protects the database with system integrity protection (SIP):\r\n# ls -aOl /private/var/db/SystemPolicyConfiguration/KextPolicy\r\n-rw-r--r-- 1 root wheel restricted /private/var/db/SystemPolicyConfiguration/KextPolicy\r\nAs this database falls under SIP, this means even if an attacker has root privileges they cannot subvert it:\r\n# echo \"some data\" \u003e\u003e /private/var/db/SystemPolicyConfiguration/KextPolicy\r\nsh: /private/var/db/SystemPolicyConfiguration/KextPolicy: Operation not permitted\r\nAnother obvious attack vector would be to interact with the UI, perhaps programmatically sending a mouse click\r\nevent to the 'Allow' button in the System Preferences' 'Security \u0026 Privacy' pane. However this pane (and other\r\nsensitive UI components such as security alerts) are designed to thwart such (simulated/programmatic)\r\ninteractions in recent versions of macOS. For example, below we can see the OS blocking an apple script which\r\nattempts to interact with the 'Security \u0026 Privacy' pane:\r\n# osascript ~/Desktop/iteractWithUI.scpt\u003ebr\u003e iteractWithUI.scpt:467:472: execution error: System Events got an\r\nerror: osascript is not allowed assistive access. (-1719)\r\nSurprisingly (to me), even if one tries to grab a screen capture of the 'Security \u0026 Privacy' pane window (via\r\nGrab.app, Capture-\u003eWindow) this fails:\r\nSo good news (for Apple), obvious attacks against SKEL fail.\r\nOf course though, as attackers we have the easier job - a single implementation flaw in SKEL may allow us to\r\nfully bypass it. Apple on the other hand, has to protect against everything. So, we're always going to\r\nwin...sometimes after just 20 minutes of poking :P\r\nWhile at this time I cannot release technical details of the vulnerability, here's a demo of a full SKEL bypass. As\r\ncan be seen below in the iTerm window below, after dumping the version of the system (High Sierra, beta 9) and\r\nshowing that SIP is enabled and that kernel extension we aiming to load (LittleSnitch.kext) is not loaded, nor is in\r\nhttps://objective-see.org/blog/blog_0x21.html\r\nPage 6 of 7\n\nthe 'kext policy' database, something magic happens. In short, we exploit an implementation vulnerability in\r\nSKEL that allows us to load a new unapproved kext, fully programmatically, without any user interaction:\r\nConclusion\r\nIn this blog post, we briefly discussed High Sierra's \"Secure Kernel Extension Loading\" (SKEL) and\r\ndemonstrated a new 0day vulnerability that can be exploited to fully bypass this new 'security' feature.\r\nUnfortunately when such 'security' features are introduced - even if done so with the noblest of intentions - they\r\noften just complicate the lives of 3rd-party developers and users without affecting the bad guys (who don't have to\r\nplay 'by the rules'). High Sierra's SKEL's flawed implementation is a perfect example of this.\r\nOf course if Apple's ultimate goal is simply to continue to wrestle control of the system away from it users, under\r\nthe guise of 'security', I'm not sure any of this even matters :(\r\nlove these blog posts \u0026 tools? you can support them via patreon! Mahalo :)\r\nSource: https://objective-see.org/blog/blog_0x21.html\r\nhttps://objective-see.org/blog/blog_0x21.html\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://objective-see.org/blog/blog_0x21.html"
	],
	"report_names": [
		"blog_0x21.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434328,
	"ts_updated_at": 1775826744,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/dd477d7227fb5d82157c2e3bfb4e0fcdb4671721.pdf",
		"text": "https://archive.orkl.eu/dd477d7227fb5d82157c2e3bfb4e0fcdb4671721.txt",
		"img": "https://archive.orkl.eu/dd477d7227fb5d82157c2e3bfb4e0fcdb4671721.jpg"
	}
}