About | Buy Stuff | Industry Watch | Learning Curve | Products | Search | Twitter
Home » Learning Curve

Saving Apple

Apple have proved not that Unix security is weak but that Apple security and Apple security procedures are weak. OS X users are left hanging with little or no information and waiting for security fixes that just don't come.


This article is about 'saving Apple'. It discusses why such a thing should be considered and offers suggestions about what you can do.

1. Why Try?

Apple are today an iPod company. This is evidenced by the fact that over 50% of their revenues come from the sale of iPods - not computers or operating systems.

So why worry about an iPod company?

There are two reasons.

  1. Apple still represent, in the public eye, the single most tangible alternative to Microsoft Windows. Windows is riddled with flaws and is not salvageable. People need better to be able to use the Internet safely. That 'better' is Unix and Apple ostensibly market a 'flavour' of Unix.

  2. The NeXTSTEP technology today owned by Apple is still light years ahead of anything else available and will remain so. This technology represents an increase in value to the casual user as well.

2. What's Wrong?

What's wrong with Apple's 'Unix' is that it today is a 'hodgepodge'. It is no longer the 'clean design' of NeXTSTEP. As Microsoft before them, Apple have deigned to mix older 'standalone' ideas with the 'connected' idea of NeXTSTEP to make OS X - and in so doing have hurt usability and security both.

At the core of the matter is Apple's file system known as HFS. HFS is what happened after Apple gave up on their initial Macintosh file system MFS. It has been updated to the 32-bit world but still suffers from the same design flaws.

To be a good player in the POSIX market, Apple have to have a file system that is POSIX conformant. POSIX is a platform independent definition of 'Unix' - much like the 'von Neumann machine' is a platform independent definition of the instruction oriented computers we use today.

Apple's file system HFS is not POSIX conformant. That means that users of OS X cannot reap the benefits of POSIX when working with OS X - and even can run into danger.

Apple are aware of these inconsistencies and deficiencies, but up to now have taken no steps to remedy the situation.

Apple do offer an alternate file system known as UFS, and it is UFS Apple use on their OS X Server, but UFS is not a straight Unix file system. It is a remake of a Unix file system with HFS functionality. UFS does not recognise the resource fork but the OS X kernel is equipped to regard other special files as substitutes for resource forks. The effect is the same - and UFS is 'frobbed' for server use.

3. What Is 'Open'?

The strength of Unix comes not only from its elegant design but from the fact that development and maintenance today are largely 'open source' projects. 'Open source' does not imply that a product is free - only that its source is 'open' and subject to repair at a moment's notice by anyone - even the casual user.

Open source is considered even by Microsoft to be the 'unbeatable foe': in their now notorious 'Halloween Documents' Microsoft revealed that their own studies have concluded that the 'old' way of developing and maintaining software cannot compete.

Open source also implies 'full disclosure'. This means that as there are no proprietary corporate interests involved, no one tries to keep vulnerabilities a secret. As soon as a hole is found, it is published - and everyone can immediately fix patches for it - either by applying the patch themselves or by waiting a day or two at the most for a revision of the distribution.

Corporations, already clumsy when it comes to developing and maintaining software, are even worse with security bulletins. Most of all it's bureaucracy which plays a part. By the time a bug report filters up through the organisation people can find themselves seriously compromised. The corporation has interests other than the end user and the end user suffers.

Some corporations, such as Apple, even try to 'keep a lid' on vulnerabilities for the simple reason they don't know how to deal with them. And the single most often seen reason for Apple doing this is that they've compromised POSIX and have no easy remedy for what they themselves have done.

4. What's Compromised?

To better understand how Apple painted themselves in a corner it's a good idea to review their technical note 2034. It's available at the following URL. It's about 170 KB.

ftp://rixstep.com/tn2034.pdf

You can also see the article 'A Word on Gruber' to get a summary of the issues.

http://rixstep.com/2/20060403,00.shtml

Or you can just hang in there and read the summary here. What's summarised here are the two salient sections of technical note 2034.

Avoid using resource forks

Mac OS X is intended to be an excellent Web citizen, a player in a networked world where often only 'flat files' are recognised. It must provide access to file systems and network protocols such as WebDAV, NFS, and SMB.

Toward this end, the resource forks of HFS and HFS+ files should not contain resources or any other critical data. Carbon applications should put their resource data in the data fork of separate files (such as .rsrc files). This strategy also makes applications easier to internationalise.

Use file extensions

If your application creates documents, those documents should be saved under the filename extensions claimed by the application in its Info.plist. Your application may use type and creator codes as an additional means of document typing, but extensions are essential because they are more durable. As with resource-fork data, type and creator codes (which are stored in the Finder Info fork) can be stripped off as a file travels between different file systems. Unless a user deliberately removes them, file extensions are left intact. More information here: http://developer/apple.com/techpubs/macosx/ReleaseNotes/FileExtensionGuidelines.html.

5. What's Happened?

What's happened is that Apple, down on their luck and productivity and revenues, courted several vendors for a new operating system to take them into the secure world of 32-bit computing - and ended up with NeXTSTEP.

The decision to 'merge' with NeXTSTEP came a long time before Steve Jobs returned to Apple. Apple had already purchased the operating system and hired on NeXT's key engineers, such as Jon Rubinstein and Avie Tevanian, to take over leadership of the company.

Apple are a company who helped pioneer the 'personal computer' and who helped introduce the 'graphical user interface'. The outward design of their GUI computer the Macintosh was meant to emulate both Alan Kay's Smalltalk-80 and Xerox's Star.

The Star and Smalltalk-80 were in fact vastly different in philosophy but this matter was not considered at the time, the basic plan being to 'just get a GUI on screen'. Apple's first attempt at such a computer was the Lisa which cost $10,000. The price scared people away and it flopped. The Macintosh was designed to retail for only $2,000. At the last minute John Sculley upped the price by $500.

Even so, it was only one quarter the price of the Lisa and so had a better chance on the market. But the key here is in the year: 1984 - the world was not yet close to being connected. Kitchen tables were still used for weird things like eating.

There was no overriding consideration for the ramifications of the internal design of the Macintosh computer. The idea was to get a 'new thing' out the door. As most software engineers will admit, however, the Mac was a mess under the bonnet.

Further, the Apple 'engineers' involved in the Macintosh project were not closely knit with the rest of the programming community. Slaving away at an idea that came from marketing (Steve Jobs) they had to bend and twist to make what seemed obvious actually work.

Apple have never been a sponsor of open source and are generally regarded not even as a computer company. They're a marketing company.

All of this of course in contrast to the move by IBM to break ground in the personal computer market. And in the way NeXT approached the task of creating the 'next' personal computer operating system.

6. What's Changed?

NeXT lucked out. That much can be stated unequivocally. The world wasn't connected back in 1985 when NeXT broke ground in Redwood City. The reason NeXT chose Unix for their 'underbody' was not open source or POSIX or cross platform interoperability. None of that. NeXT chose Unix because their target demographic knew it and because it was a smart way to do things easier.

There was no reason to 'reinvent' the operating system. Citing Brian Kernighan's famous rules of programming and focusing on the third and final aphorism, 'let the other guy do it', they saw that there was no reason to reinvent the wheel. They had a good wheel already.

Instead Avie and friends concentrated on building up a 'GUI' on top of Unix. And because of this clean design they not only lucked out, they won out too.

7. What's Better?

Unix as it's used today around the world on workstations has - or should have - three main GUIs to choose from: GNOME, KDE, and NeXTSTEP. All three are based on the C programming language but there are important differences.

GNOME uses straight C. This is the same as Microsoft Windows. Anyone who's seen the code for Windows knows what this means. There's nothing wrong with C - au contraire - but the essence of C is to abstract up to the application domain without any loss of efficiency, flexibility, or functionality.

This means necessarily hard wiring the mechanisms of event driven programming. It can work - but it's too much work.

KDE uses C++, an 'invention' of one Bjarne Stroustrup who ostensibly does not really feel at home with C and would much prefer things as they were with Pascal. But Pascal is a teaching language, intentionally constrictive and restrictive, and often has been described as a 'straight jacket'. Whether one agrees with the ideas of its creator Niklas Wirth (and most do not) it's not a production language.

C++ is supposed to be an object oriented language, but as Alan Kay quipped:

'I invented the term object orientation, and when I did I certainly did not have C++ in mind.'

C++ is not in fact an object oriented language but a 'hybrid'. It makes certain features of object orientation possible but on the whole fails because of its poor design.

One of the most important features of object orientation is something called 'dynamic binding'. C++ can't do this. C++ programs are tangles of messy code with bugs galore and little hope of finding and eradicating the bugs. It also bloats a great deal.

KDE has been described by many with insight into the project as something that started pretty OK and has successively become more bloated and more wobbly.

NeXTSTEP uses Objective-C which is a 'production model' of Alan Kay's Smalltalk. As such it's the only development environment of the three with a pedigree. And as the only true successor to Smalltalk, it's the obvious winner.

Objective-C uses dynamic binding. This means that the objects - the organisms as Kay described them - can achieve true interactivity and maintain imperviousness to flawed code in remote modules. It also increases usability significantly.

Developers often find project times down to one fifth or less of what they're used to. And the results are often startling. This due not only to the language but also to the 'NeXTSTEP classes' developed by Avie and friends with Objective-C.

Were it not for the fact that Apple Computer 'own' NeXTSTEP today, there would be no reason to think twice about trying to save them.

8. What's Trust?

Trusting the vendor is important - being able to trust the vendor that is. There are already cases of when open source Unix has been compromised. Not too long ago a piece of malfeasant code crept into the Debian source tree. This meant that every build of Debian had the secret trojan hidden inside.

Co-creator of Unix Ken Thompson dropped a bombshell when he revealed he'd kept a back door hidden inside Unix for years. He hid it inside the source code to the C compiler itself. No one is ever 100% safe.

But if one can assume one's vendor has the best of intentions and has no reason to corrupt the source tree, one can manage well. And GNOME and KDE themselves have no opportunity to corrupt the Unix source tree as they're not proprietors of it.

Apple have their own Unix source tree. It is based on what NeXT used to do. NeXT chose FreeBSD Unix for a number of reasons.

  1. It was free and the licence agreement was amiable.
  2. Linux hadn't been invented yet. That would take another seven years.

There is no reason NeXTSTEP can't run on Linux, and in fact this must be a goal of developers in the long run. No matter the turf wars between the BSD people and the Linux people, the systems are essentially the same - enjoying and benefitting from similarities rather than suffering from inconsistencies.

NeXTSTEP used FreeBSD right out of the box but added a microkernel to it for greater stability. This in itself is no cause to not trust.

Apple however corrupted the FreeBSD source tree and even renamed it - something totally unnecessary if their only intention was to use FreeBSD. Worse, Apple's own FreeBSD - renamed 'Darwin' - is not 'open source' in the full extent of the words.

Apple don't take kindly to interference with their Darwin development. They make it nigh on impossible for outsiders to create an entire Darwin build on their own. And they do not make it easy for outsiders to report bugs and propagate code fixes. And this is all against both the spirit and the meaning of open source.

Unix distros using open source benefit from the 'open source' aspect of their distros. OS X users do not benefit in this way at all. Where open source projects get fixes almost always overnight, Apple's Darwin project gets fixes almost always never.

Countless are the severe and serious bugs (vulnerabilities) found in Darwin that Apple just let slide not for days or weeks or months but YEARS. This is not the way open source works, and this doesn't work at all.

To make matters worse, Apple have used their 'closed source' situation to make changes in the FreeBSD tree that introduce incompatibility with Unix at large. In repeated attempts to enhance their GUI (the user experience) they have rewired the FreeBSD source tree - meaning no one outside Apple can help them when things go south, meaning changes are not vetted as they are in the open source world.

This is not the situation with GNOME and KDE: these GUIs cannot by definition corrupt your 'Unix' underbody and put you in danger. Everything they do must of needs go through the same Unix kernel code.

But Apple, with their closed off Unix, deliberately corrupt the kernel to enhance their GUI. Aside from the obvious observation that this is an engineering felony, it's obvious to even the casual user that it opens Pandora's box.

9. Some Examples?

That Apple have been 'asking for it' is not something that suddenly dawned on people in the wake of the recent vulnerability scandals. It's something that's been known for some time - something the Rixstep site has been harping about for years.

You never try to wed two operating systems. Never. And especially two as disparate as Unix and MacOS. Even mouthing something so ludicrous is bound to get you labeled as a fool.

Operating systems don't meld, or blend - especially two as disparate as MacOS and Unix.

And as Unix is the clear winner here, the solution for an ailing planet, and as MacOS is the clear loser, relegated to oblivion by its standalone insecurity and other things, the writing is clearly on the wall, the paint long ago dry.

Again, at the smelly bottom of it all is the file system HFS. HFS is an easily corrupted file system. POSIX has no requirement that file systems may not be easily corrupted, but common sense does. And common sense is not an ingredient in HFS and never was.

Defragmenting an HFS disk is simply never attempted. It is never attempted because the system is too wobbly and defragmentation normally leads to corrupted disks.

HFS - as with most things Apple - has its own 'very peculiar' way of doing things. A description of the inner architecture of HFS is likely to leave the professional engineer gawking and yelping in protest: the ideas therein represented are amongst the most 'cockamamie' in computer science history.

Apple did not use a real Unix file system as NeXT had done because they were keen on retaining as much 'beige box compatibility' as possible. This was a disastrous decision because beige boxes came from an unconnected world and OS X must today be a 'good Web citizen'. Standalone ideas never work in a connected world anyway.

Beige boxes with all their peculiarities are dependent on HFS. But HFS cannot achieve POSIX compliance. Worse still, HFS is one of the few file systems on the planet that cannot adequately emulate POSIX compliance. Even Microsoft's MS-DOS could emulate POSIX compliance in a pinch, as could their NTFS. HFS cannot.

HFS is thus not only at the root of the 'interoperability' issue and the 'open source' issue but at the root of the 'vulnerability' issue as well. HFS leaves the distro off on its own, totally unprotected and unable to get help when needed - and this in addition to its severely decreasing usability.

Some tangible examples:

  1. Apple's 'shell' has two hands, neither of which knows what the other is doing. You can look at a file and think it's one thing, but if you open it you find - to your dismay - that it's something entirely different.

  2. Hard links on HFS get lost forever. This has been known for a very time. There are numerous articles at this site pointing to and explaining this issue. And the proprietors of this site have reported the matter to Apple repeatedly. Their answer? 'It is a known issue.' Note there is no indication or much less promise the issue will be resolved, for to resolve it they would have to gut HFS completely.

  3. Confusion about document application binding. The old HFS creator codes and file types lurk everywhere but are largely inaccessible, making computer use annoying in the best of all possible cases. Rixstep even have three applications to fight this, despite the initial Rixstep promise to stick to 'Unix application domains'.

  4. Confusion in the document controller. The 'recent documents' menu works with POSIX file paths; the file I/O of the very same document controller works with HFS CNIDs. It's a wonder there aren't more frontal collisions than there are.

10. What Can I Do?

In a word: you can file bug reports. If enough OS X users complain, Apple will change. In such case they must change. Right now they're burdened by the pressure of the 'fanboys' - the old 'beige box users' who don't ever want to see anything change.

The OS X user demographic is changing all the time and day by day the 'fanboys' are falling more and more into the minority. If Apple realise this, their policies must of needs change. By filing bug reports you can make them aware of your demands.

As soon as you see something fishy on your OS X system, write to Rixstep. Use the contact sheet at Rixstep to get the address. Don't worry if you're wrong or not - report it anyway. If you're right, you'll get help formulating your bug report to send to Apple.

Bug reports can be sent in two ways: either through the ADC microsite (in which case you have to be a registered developer) or through the product security portal.

http://www.apple.com/support/security/

You can also write directly to the Apple Product Security team here.

product-security@apple.com

You can also write to bug report sites such as Bugtraq, Metasploit, and Full Disclosure.

http://msgs.securepoint.com/bugtraq/
http://lists.grok.org.uk/pipermail/full-disclosure/
http://metasploit.com/projects/Framework/exploits.html

It's not threatening at all if only one individual files 1,000 bug reports, but it is VERY threatening if one thousand individuals each file one bug report. What such an action can do is educate Apple about the 'numbers'.

For it's in the demographic they can see if and when they need to change. No corporation, Apple or otherwise, are ever interested in fixing bugs. They're solely concerned with the bottom line. And if they start to understand that the majority of their users want a change, they'll be forced to make it.


Before installing any application in OS X, be sure the application will not perform any malicious activity.
 - Apple Computer

Exactly how do you propose people do that?
 - Brendon C Bleebwart

Wake up, Neo...
 - Trinity

Knock knock, Neo.
 - Trinity

The idea that Macs can't get viruses is simply absurd and I wanted to highlight that fact. It was pure coincidence that Leap.A had already (been created to) set out to prove that the old wives tale is false. InqTana was more or less an exercise in proving folks wrong about the possibilities of Mac malware.
 - Kevin Finisterre

We OS X users have been living in this great world where we are more vulnerable than other Unixes, but we weren't seeing any attacks because we weren't targeted. I think we are going to see a lot more of this in the next year.
 - Jay Beale, Bastille-Linux & Intelguardians

This is a very very sad day for the Mac platform. I always hoped that this would not happen in my lifetime. [sic] I am almost in shock now. I can't believe this is reality. All because of this bastard with his pics. I am extremely pissed, sad, and scared. This guy needs to pay - this is war IMO.
 - CoMpX at Mac Rumors

See Also
Perimeters
Seeing Double
The Other Shoe
Hyde Park Corner I
The Chocolate Tunnel
OS X: Still Not WYSIWYG
Peeking Inside the Chocolate Tunnel
Apple's 'Unix' Runs Arbitrary Code on Boot?
Input Managers — The Cure

OS X patch faces scrutiny
Trojan flaw persists in OS X
Experts Claim Security Flaw Remains
Apple criticised for persistent Trojan flaw

About | ACP | Buy | Forum | Industry Watch | Learning Curve | Search | Twitter | Xnews
Copyright © Rixstep. All rights reserved.