|Home » Learning Curve
Odd Corruption Launch Error 10.9.4
As you sow so shall you reap.
EVERYWHERE (Rixstep) — Truly it's a wonder that Unix - from the back thoughts of Ken Thompson, through the counseling of Joe Osanna and Doug McIlroy and the teamwork of Dennis Ritchie, through the first interpretive implementation, through the birth of the world's only 94% machine-independent systems programming language, through the Berkeley Software Distribution under Ken's sabbatical, through Unix System Laboratories, through all the subsequent flavours, more than Baskin-Robbins, through thousands more with the birth of Linux - could possibly survive this long without Apple's code-signing and walled garden.
Truly it's also a wonder that Microsoft systems - despite all such hysterical precautions - continue to be an embarrassment.
Unix of course went through growing pains. But Unix was built from the ground up with the right things in mind. Working in a small area of the big building in Murray Hill, Ken and Den understood their system would be used (and abused) by another two dozen PhD hackers. The 'personal computer' hadn't been invented; all operating systems were 'real' operating systems. Nobody touted a 'disk operating system' as Apple and later Microsoft would do. What the users did was private and couldn't be accessed by anyone else without their express permission; the wild and wacky code those users ran couldn't interfere with other things on the system. The system had to protect them from each other, protect itself from all of them, and finally protect itself from itself.
This was standard operating procedure until IBM introduced the PC with a 'system' based on a sketch by Tim Paterson of Seattle Computer Products. And the world started to cave in around 1995 when Microsoft put such a system onto the World Wide Web.
Unix was never the issue - Microsoft systems were. The Redmond company dominated the personal computer market with Bill Gates, more proficient at marketing than programming, understanding that if you leveraged the API everyone else used for their software, you owned them all.
Apple came back out of the rubble like a phoenix, suddenly touting a FreeBSD under the bonnet. Then gradually, more and more since 1996 when this first occurred, Apple kept surreptitiously looking in the direction of Washington state.
And it looks like a bad move - and certainly it is from an engineering standpoint - but then one forgets the profits angle. What Apple effectively have done is create a protection racket - 'do it our way or suffer the consequences'. And for all the years Apple's OS X ran side by side with Microsoft's obscenely expensive Windows, the world watched as catastrophe after catastrophe whacked Windows users whilst Apple users were simply not affected.
That's the Power of Unix™ - or rather the Weakness of Windows™.
But that wasn't good enough for some. Claiming the unassailable OS X must be better protected (but against what, they couldn't say) Apple introduced code-signing - a way to digitally verify the contents of an executable bundle. Microsoft did this too, but at their end, working with IP holders, they demand hardware components manufacturers intentionally degrade signal quality so bulk copies fail. Then too, Microsoft are always trying something new to secure their insecure disk operating system.
Code-signing is eminently easy to defeat on OS X as things stand. The extra data is added to the executable as a new section; defeating code-signing is simply a matter of removing that new section. This is a process that could easily be automated - for example, by a hacker or a malware organisation or both.
Code-signing only works, as on Apple mobile devices - when the OS kernel demands it. Then the system can refuse to launch anything lacking a cryptographic seal or proving to have been corrupted.
This was a heck of a move for the Apple iP* teams who started things off, unbelievably enough, by running all processes as root (and prompting the Gruber to screech that they must know that they're doing).
But this was also the move - security be damned - that established the computer protection racket: Apple seal all apps with their own root certificate, their mobile OS kernels demand a seal to launch, all ISVs have to go through Apple to reach their market and pay dearly for the privilege.
Things look great for the oblivious mobile device user: it's just 'tap tap tap' and you have Angry Birds ready to run. Apple clean up - they take three times the commission of traditional software sites and demand registration fees as well.
And if there's something wrong with a product? Paying clients might have to wait forever for a fix, for ISVs have to go through the same ridiculous process all over again.
And it's absolutely heartbreaking to see how fanatical Apple users gawk at it all, cap in hand, and debate the different aspects of the walled garden, with none of them having the balls to suggest there be no walled garden at all.
You Make It, You Fix It
There are myriad examples throughout computer science history of how poor design and code make a situation spiral out of control. Sony once entertained the idea of embedding Windows rootkits on audio CDs - insert the medium once and you were owned and could no longer copy out the contents.
Of course Ed Felten's crew found that the procedure could be defeated by simply holding down a shift key when inserting; but more importantly, malware organisations found that Sony's rootkit was the perfect place to hide their code.
Sony had a bad idea, and that bad idea had ramifications far beyond what they originally intended.
Computer training organisations using Apple's OS X demanded special procedures which coincidentally opened the system to attack; the result was Opener, a proof of concept script shepherded by a frustrated system administrator that showed just how bad things could get.
And so forth. The latest in this seemingly endless stream of bad code riding piggyback on poor design are the errors now cropping up in Apple code-signing. Anthony from the Rixstep Forum has the word.
After upgrading my Mac Mini from Lion to Mavericks Mac OS X 10.9.4 I encountered an odd error when attempting to launch CLIX from a fresh install of the ACP10.9 Changelog 2014-05-09.
Upon launch a dialog came up saying that CLIX was corrupted and the dialog offered to move it to the Trash. In the Console logs, there were a couple errors around the same time of the launch attempt along the lines of:
CoreServicesUIAgent: Error SecAssessmentCreate: The operation couldn't be completed. (OSStatus error -67030).
com.apple.launchd.peruser.UUIDOfUser: xxx.com.rixsteop.CLIX[xxx] Exited: Killed: 9
In addition, Xfile hung upon launch.
One of the troubleshooting steps I tried was to delete the Rixstep .plist files in ~/Library/Preferences to do with these two programs, but this did not resolve the problem.
To make a long story short, to workaround the problem, which from doing some web searches sounds like an issue related to Gatekeeper, I did the following:
1. In System Preferences -> Security & Privacy -> under the General tab I set the 'Allow apps downloaded from:' radio button from 'Mac App Store and identified developers' to 'Anywhere'.
2. CLIX successfully launched afterwards.
3. After setting Allow apps downloaded from:' back to 'Mac App Store and identified developers' CLIX continued to launch successfully as did Xfile.
Another symptom which perhaps may be potentially related to this issue is that running 'spctl --assess --verbose --raw ~/Applications/ACP10.9/CLIX.app' in the Terminal results in the following error in the output:
'invalid Info.plist (plist or signature have been modified)'
For comparison, running the same command on /bin/ls results in 'accepted' being output followed by a printout of an XML file.
From what I came across in my web searches it sounds like the root cause could either be a corrupted Gatekeeper-related database in /var/db/SystemPolicy or a code-signing issue.
If it's of interest, here are some links:
OsiriX will no longer launch. Console message
Fix OS X wrongly reporting an application is corrupted (OSStatus error 99999)
Restoring the Default Gatekeeper Database:
'Minecraft is Damaged' - incorrect code signature
'When you download Minecraft on a default-configured Mac (Gatekeeper on) and try to open it, the system will report that the application is 'damaged' and cannot be opened. This cannot be overridden by using Finder's Open contextual menu item, as is possible with unsigned applications. This is because the launcher is signed, but the code signature is incorrect.'
Manage Gatekeeper from the Command Line in Mountain Lion
Unix is a secure system. This is the system Apple touted for years as the 'Rock-Solid Foundation'.
There may be 'flavours' of Unix - such as OpenBSD - that are more secure, but the differences are infinitesimal compared to the frightening gap to Microsoft Windows. OS X, despite its foibles, remains essentially a 'Unix' system, with all the inherent benefits accruing to a system built the correct way from the beginning.
OS X does not need, never has needed, and never will need code-signing to make its users secure. But the cash flow from the Apple Store into the bursting Cupertino coffers is perhaps too great a counterargument.
The Technological: Sony's Ship of Fail
Learning Curve: Rootkits Roam the World of Windows
Industry Watch: Barely Legal
The Technological: Re: 'How the %#@! did I miss this?'
Red Hat Diaries: A Genuine Destruction of Culture
The Technological: Australia's Internet Industry Association
Industry Watch: The Legend of Oompa Loompa
Industry Watch: The Chocolate Tunnel
Learning Curve: Son of Input Manager
Developers Workshop: Apple: When Closed Systems Don't Work
The Technological: The Not So Sinister Finisterre
Industry Watch: Opener 3.9
Learning Curve: Input Managers - The Cure
Developers Workshop: Trojans for Nothing
Developers Workshop: The Hackers Handbook - Propagation
The Technological: Effective UID: 0
The Technological: Alpine Dottie
Red Hat Diaries: iPhone and Security
Red Hat Diaries: iPhone and the Media
Developers Workshop: iPhone OS X System Architecture
Learning Curve: Peeking Inside the Chocolate Tunnel
Industry Watch: The Story of Renepo
Developers Workshop: Hacking C0d3 S1gN
Red Hat Diaries: Code Sign of the Times
Industry Watch: Mac Developer Program Update
Industry Watch: Steve Jobs to App Store for Mac: 'Nope'
Industry Watch: Mac Developer Program Update II
Red Hat Diaries: The Steve Gambit
Learning Curve: The Key to Gatekeeper