Guarding Fort Knox

Before Houdini.

Get It Try It

CLIXchange (Rixstep) — The following was written as the fifth newsletter for the fourteenth year of publication of Xnews, back in 2010. It was published 4 July and rediscovered just the other day.

The announcements herein regarding CLIX seem to predate the advent of Houdini by several years.

Already back then, CLIX was impervious to attack. But Houdini made attack impossible. Apple code-signing (CodeResources) seals from the outside - supplemental executable headers - and can be removed, even programmatically. Houdini seals from the inside and cannot be removed.

----------------------------------------
[0001] Guarding Fort Knox

Too much work is spent defending Fort Knox. CLIX outsources your password. This almost made sense back when CLIX commands could be exactly the same as console command lines. But they can't be anymore. sudo introduced this '-S' switch which is necessary in non-terminal situations but can't be used in terminal situations. So command lines have to be doctored when moving from the one to the other anyway.

And it's too much code wasted trying to defend that password. I bet half our code is about it. We have so much stuff in there. We watch through the IO Kit to see if the box is going to sleep - and then start zapping vestiges of the password everywhere. From the sheet (if it's open) and from memory - and then just for good measure, we kill the sudo time stamp as well.

Each CLIX command comes with an unseen prefix and an unseen suffix. The prefix zaps the time stamp so you will always detect when sudo is being invoked if that's what you want. A second thread runs asynchronously after every CLIX command to kill the sudo time stamp as well. And the kill operations don't stop at CLIX - they kill timestamps for all TTYs for your own safety. (This is the basis of the two command line utilities sudokill and sudokill2.)

The CLIX binary is protected in an ingenious way - a way I'm proud of myself as it took six months of not giving up to find it, even when everybody told me it wasn't necessary and probably impossible and things would be fine without it. But it takes a lot of work. It takes about 20 minutes to prepare any CLIX binary before the danged thing will even run. That's a lot of work if you want to update the total of SIX different versions of this essentially free program we have out there.



There is a special check inside CLIX anytime anything critical wants to happen. None of the critical operations will complete if something is wrong, if something has been compromised. Try this as an experiment: copy out the CLIX binary, make a copy of the copy, then go in with a binary editor and change just ONE BYTE of it, then copy it back into the CLIX bundle. Dead meat. Now copy the secure copy of the copy back and all works again. That takes a lot of work.

We discovered two further possible avenues of attack the other week and have been working like the blazes on them ever since. These scenarios are so remote - they require an in-house spy who gets to steal to a computer unseen now and again - but they work and we've seen them work. The odds these will happen are less than zero in practice but it doesn't matter - they happen in theory. And thus the overtime frantic work to find a way to guard against them.

We're now checking the integrity of NIBs as well. We could apply a certificate to the entire bundle but then again we've already demonstrated that a certificate can be removed from a bundle and the application won't know the difference. So that's no protection either without a Steve Jobs walled garden OS kernel that won't run anything without a root certificate. And we're not going to get a root certificate anyway - not for a free bloody app. That's ridiculous.

No one to this day has figured out how we can run sudo commands without an embedded command line module (in Resources) but we can assure you that it is there even if you can't see it or find it. And this technique (technology?) is something we're pretty sure no one ever thought of before and we're using this in a number of projects and yes, it works great, we think. Thank you.

And we're also going into process tables (yes kernel calls) to make sure any calls from sudo are actually coming from the 'real' sudo (/usr/bin/sudo). And we're also checking that any sudo process prompting for a password is actually a subprocess of our own. We're counting the number of times sudo is invoked. We're disallowing situations where sudo is running more than once at any given time - admittedly sudo runs for only milliseconds otherwise but still and all. We're defending Fort Knox.

And we know that there will always be a new hack idea for every additional protection. So why bother? Apple have their authorisation services and those services are well protected and as we know it's us calling them then we're OK, right? So all we'd have to do is introduce a 'sudo' tick box on the command sheet. Not something that stays with the records but something you can set each time you run the command. And then 'security' is 1) up to the user; and 2) up to Apple's authorisation services - and we don't have to do ANYTHING about security ever again.

The snag is the FILE * channel given to the calling process by the authorisation services. This won't match what we otherwise use. This means two threads of code where neither one can ever know if it's being used and the other one is not being used. Perhaps the authorisation services can be set to run things as the ordinary user, whereby the user won't be prompted at all.

Then there's the buffering. A bitch. The current one works wonderfully - has for all these years. Working on a new one isn't totally cool. An alternative is that the module called uses the distributed notification system like Tracker and Xframe - this will probably work better on 10.6 and the successors anyway.

But there comes a time when complexity begs to be transcended. Look at Power architecture. Do they make Power even more monster-like? No - they use Powers in Cell architecture instead. The only way to move forward is to synthesise and simplify. That's what I think we want to do with CLIX.

About Rixstep

Stockholm/London-based Rixstep are a constellation of programmers and support staff from Radsoft Laboratories who tired of Windows vulnerabilities, Linux driver issues, and cursing x86 hardware all day long. Rixstep have many years of experience behind their efforts, with teaching and consulting credentials from the likes of British Aerospace, General Electric, Lockheed Martin, Lloyds TSB, SAAB Defence Systems, British Broadcasting Corporation, Barclays Bank, IBM, Microsoft, and Sony/Ericsson.

Rixstep and Radsoft products are or have been in use by Sweden's Royal Mail, Sony/Ericsson, the US Department of Defense, the offices of the US Supreme Court, the Government of Western Australia, the German Federal Police, Verizon Wireless, Los Alamos National Laboratory, Microsoft Corporation, the New York Times, Apple Inc, Oxford University, and hundreds of research institutes around the globe. See here.

All Content and Software Copyright © Rixstep. All Rights Reserved.