El Capitan should not be booted with rootless=0

First. I believe that Hacking Team (currently offline ROFL) was hacked in late 2014 already, by the Dream Team, and that using rootless=0 as NVRAM/boot-arg is utterly stupid. I mean. Nobody should open ‘a backdoor in OS X’ and rootless=0 helps to protect your filesystem – among others – and so please do not use it with installations that are connected to the Internet. That is all I can say here.

Yes. I can replace your boot.efi with a modified copy of mine and give myself access to all of your files. Trust me. I would never do this, and that is why I urge you to listen to me: Please do NOT boot with rootless=0 Period!!!

Okay. Your hack won’t boot without rootless=0 but hang on. I hear you. This is why I am/will be working with boot loaders developers so that they can fix this. To let your modified kexts load without the need of rootless=0. Without the need of opening a back door. Promised.

Note: You don’t need to replace boot.efi with a legacy boot loader – think Chameleon, Chimera and RevoBoot – to be vulnerable, because boot.efi isn’t used by legacy boot loaders. Not that it really matters, because all* legacy boot loaders are still vulnerable.

Update: RevoBoot and the Enoch branch of Chameleon are no longer vulnerable and can now boot El Capitan without rootless=0 (the ‘all or nothing’ setting.. going away in a next DP).

Update-2: I have not yet been contacted by Clover developers, but then again they might not care about (your) security/privacy.

Update-3: Clover is recently changed and now sets csr-active-config by default similar to rootless=0. Which is, again, utterly stupid.

// CsrActiveConfig
Prop = GetProperty (DictPointer, "CsrActiveConfig");
gSettings.CsrActiveConfig = (UINT32)GetPropertyInteger (Prop, 0x67); //the value 0xFFFF means not set

Note: If Clover has changed, but I missed it, then please let me know so that I can update it here. Thanks!
People who set the NVRAM variable csr-data and/or csr-active-config in a way that it basically disables the System Integrity Protection, that is not in your best interest. What I mean here is that it is better to change as little as possible. Keeping as much protection up and running. Possibly only let unsigned kexts load and let the rest for what it is since that isn't required, and may open a door for exploits.
Advertisement