SECURITY ALERT: Mac OS X 10.5.2 subverts FileVault

May 10th, 2008

I apologize for not posting this earlier. I’ve been extremely busy lately, and I had discussed the issue with someone who said that he or she (he) was going to post about it (but hasn’t).

The security alert is for FileVault users running Mac OS X 10.5.2. You thought that FileVault encrypted your personal data, right? Wrong! In Mac OS X 10.5.2, the location of the CFNetwork caches was moved from ~/Library/Caches, which is within your home directory and thus encrypted, to /private/var/folders, which is not within your home directory and thus not encrypted. This means that anyone with physical access to your hard drive could, for example, determine which URLs you’ve loaded, even if your computer is shut down.

Note that nothing about this change was mentioned in the Mac OS X 10.5.2 release notes.

For further reference on this issue, see the thread that began in the WebKit SDK mailing list and was moved by me to the Macintosh Network Programming mailing list. Thanks to Eric Long, who noticed the change in the first place, and Ron Hunsinger, who performed testing that I was too lazy to do. (In my defense, I haven’t yet migrated my FileVault account from Tiger to Leopard, so the issue doesn’t affect me directly.)

Posted in Apple, Unix | 1 Comment »

Cocoa Blogs free, as in beer

March 30th, 2008

Wait, beer is not free! Or so my bartender yelled last night as I ran out the door. (I also had one bourbon and one scotch.) The front page of Cocoa Blogs was already free, but the syndicated feed has only been free to contributors — kind of like Congress. Now Scott has decided (he is the decider) to make the feed available for free too. Indeed, new items are appearing in the feed. Remember, folks, you heard it here first. This is your Number 1 source for news, rumors, and outright lies.

My own long list of Cocoa blogs, including the Cocoa Blogs feed, can be downloaded for free from the “Favorite Feeds” link in the sidebar of my blog. The list is in convenient .opml format for import into your favorite free feed reader. There seem to be many choices nowadays. (Too bad that they all suck. Mine sucks the least, though.) The contents of my web site have been and always shall be free, as in loader. If I asked for contributions, that would just embolden the terrorists. Last call!

Posted in Cocoa, Personal, Vienna | 2 Comments »

Stabs is deprecated

March 9th, 2008

This post is dedicated to E. Gary Gygax, the second greatest corrupter of youth in history. It’s about D&D, that is, DWARF and dSYM. As of 2008-02-27, the STABS debugging symbols format has been deprecated by Apple. The default value for the DEBUG_INFORMATION_FORMAT build setting in Xcode projects had been stabs, but now it’s time to move on. (I’m talking to you, Justin Long.) Our other options are dwarf or dwarf-with-dsym. Also cake or death.

With STABS, you could build the release version of your app with debugging symbols, make a copy of the executable MyApp.app/Contents/MacOS/MyApp to keep, strip the executable for shipping, and then use the unstripped executable for symbolizing crash reports by giving a space-separated list of stack trace addresses to the command-line tool atos. Unfortunately, atos cannot currently serve this purpose with DWARF. Unlike STABS, DWARF does not include the debugging symbols in the executable itself but merely includes references to the intermediate object files, which do contain debugging symbols. You can usually find these .o files in a sub-directory of the build/MyApp.build directory. If you delete the object files after building with dwarf, you won’t be able to step through your app’s code. (With stabs, the object files are refuse.) You also won’t be able to step through the code if you strip debugging symbols from your app, even if you keep the object files, because the references to the object files will be gone from the executable.

To avoid losing the debugging symbols for your app after stripping, you want to use the option dwarf-with-dsym. The DWARF with dSYM option performs an additional step beyond ordinary DWARF: it creates a separate MyApp.app.dSYM file that contains all of the debugging symbols for your app. In fact, the DWARF with dSYM option allows you to step through your code regardless of whether the executable is stripped! This is possible because gdb will look for the .dSYM file in the same directory as your app. It doesn’t need to know the name or location of the object files. If you don’t strip debugging symbols, you can use either the .o files or the .dSYM file for debugging, but for the local debug build of your app there’s no point in using dSYM, since that would just prolong your build time. You have better things to do than wait for builds, such as writing comments on Slashdot.

The trouble with atos is that it does not reliably find debugging information in .dSYM files for stripped executables. Although Apple’s documentation (as of 2007-04-02) says, “If you’re using DWARF dSYM files, you must be using the version of atos included in Xcode 3 (Mac OS X version 10.5)”, Apple’s engineers say, “The underlying framework that atos uses doesn’t support loading symbol names from dSYM files in Leopard.” In my testing, however, there doesn’t seem to be a difference between Leopard and Tiger, at least not with Xcode 2.5 on Tiger. On both Leopard and Tiger, atos successfully loads symbol names from .dSYM files (I deleted the .o files) for unstripped executables. For stripped executables, in contrast, atos frequently fails to load the symbol names, or even gives inaccurate results.

The CrashReporter Technical Note suggests loading your app and its .dSYM in gdb to translate stack trace addresses from crash reports. That’s like having to start your car in order to read the odometer. (Oh wait, I have to do that, Nissan!) An alternative method is the command-line tool dwarfdump. It requires only the .dSYM file, not a copy of your app, and its --lookup option will do the same job as gdb without the overhead.

Please note that by breathing, blinking, or moving at all, even to command-w this page, you thereby register your agreement not to disclose or discuss this information anywhere with anyone at any time, no matter the duress, torture, or water-boarding you may undergo to extract it. This agreement holds despite the fact that the information is publicly available on the internet for every person in the world to read. Failure to uphold this agreement will result in multiple, painful cat scratches, in certain cases leading to cat scratch fever.

Posted in Apple, Unix, Xcode | 3 Comments »

The beach is open

March 1st, 2008

I know that March may be too early to think about going to the beach, but Code Beach does not require a tan, six-pack abs (so-called because beer drinkers usually have nice abs), or even swim trunks. No, it’s not for nudists, it’s for Mac developers! Nudist Mac developers, use your own discretion. The goal of Code Beach is to create a central repository where Mac developers can share pieces of useful code (like custom controls, formatters, categories) which is easier to search/use than forums or mailing lists. Brought to you by Briksoftware, Code Beach could use more traffic and more code. Don’t worry, there’s only one Shark, mostly harmless.

Posted in Cocoa | Comments Off

NSScrollView in a key view loop (or Fembot in a wet T-shirt)

February 20th, 2008

Now that the Pats have won the Super Bowl, Rudy has won the GOP nomination, and the Jedi have won the Clone Wars, all is right with the world (and the galaxy), so we can focus again on our lives, on our families, and most important, on Cocoa. If you’re a Cocoa developer, you are morally required to open System Preferences, Keyboard & Mouse, Keyboard Shortcuts and select All controls in Full keyboard access. This is not optional. If you do not comply, you will be driven out of the Continuum and forced to spend the rest of your pitiful mortal existence writing kernel extensions.

With the mandatory preference setting, you will observe the full Cocoa key view loop. Actually, it doesn’t have to be a loop: it could be a key view cul-de-sac. Anyway, Apple clearly wants developers to “leave the driving to us”, i.e.,

-[NSWindow setAutorecalculatesKeyViewLoop:YES]

because configuring and updating the key view loop can be a pita — like training a cat. The docs make it sound oh so easy, but that’s only because the docs don’t cover the complex or problematic cases. Suppose, for example, that you have a scroll view enclosing a view that contains multiple controls. You want the key view loop to follow a particular route both outside and inside the scroll view. How should you hook up the views in Interface Builder? (Or in code, when you’re working without a nib.)

I believe that the proper way to handle an NSScrollView in a key view loop is to ignore it. Walk by quickly without making eye contact. Whatever you do, don’t engage in conversation! Otherwise you’ll get invited to coffee or lunch. The reason you can ignore NSScrollView is that it never actually becomes the firstResponder of an NSWindow. The scroll view returns YES from acceptsFirstResponder if its documentView does, but if you then call -[NSWindow makeFirstResponder:] with the scroll view as argument, the window’s first responder will end up being not the scroll view itself but rather its document view.

This behavior is adequate if the document view is a single control such as an NSTableView or an NSTextView (though maddeningly, an NSTextView tends to interpret the tab key as, well, a tab). In the window nib, you can simply include the scroll view in the window’s key view loop, ignoring the document view, and when the window loads, the scroll view will automatically rearrange the key view loop to make its NSClipView the nextKeyView, followed by the document view and then the scroll view’s original nextKeyView. The scroll view and the clip view are superfluous in the key view loop, however, because only the document view becomes the first responder when tabbing through the window.

This behind-the-curtain key-view wizardry may seem impressive, but the scroll view is really deaf, dumb, and blind. It has no idea about any loop you’ve defined within the document view. There is no way to inform the scroll view of the beginning and end points of the ‘sub-loop’. If you attempt to insert the scroll view containing your sub-loop into the window’s key view loop, it will turn into either a key view dead end within the scroll view or a key view overpass, depending on the configuration.

To avoid these problems, simply connect your views together in the key view loop as if the scroll view did not even exist. You know, like Mac OS X Tiger. (Of course the keyboard firmware update requires Quick Look and Time Machine!) Only the views that become first responder — as opposed to becomeFirstResponder — need to be hooked up. When a cat is lying on the trackpad, you will be thankful for setting the key view loops in your app, and so will your users. Cat-friendliness is in fact the most crucial consideration for designing both software and hardware.

I am saying that I will neither aspire to nor accept — I repeat, I will neither aspire to nor accept — the positions of President of the State Council and Commander in Chief. I will, on the other hand, host the Tonight Show if asked. Hasta la vista!

Posted in Apple, Cocoa | Comments Off

FUD from Rixstep: NSDocumentController in Leopard

February 2nd, 2008

At the risk of provoking their ire and being branded a moron, I wish to dispute a claim that has been made several times by Rixstep about a supposed security vulnerability in Leopard’s NSDocumentController: Cocoa’s document controller overrides file system permissions without authentication. As far as I can tell, this claim is false.

I should note at the outset that I have nothing personal against Rixstep. Their syndicated feed has long been among my (numerous) favorites that I subscribe to in Vienna, as you can see by downloading the exported opml from my blog. I welcome legitimate criticism of Apple, and I have found Rixstep’s articles entertaining in the past, though of late they have become overly juvenile. As far as the whole ‘Cross-Platform Bait & Switch’ incident is concerned, I can’t comment on the legality of reproducing the quotations, because I’m not a lawyer, but I don’t think that Rixstep can be accused of misquoting or quoting out of context in this case.

Anyway, I’ve included the full text below of the email I sent to Rixstep a month ago. Retraction was perhaps too much to hope for, but I thought they would at least stop making the false claim after reading my email. They haven’t, which is why I’m now ‘going public’. (This should knock Britney off the front page.)

Hi. I read your article at <http://rixstep.com/2/1/20071227,00.shtml>, and it got me a little worried, so I did some testing. My results are that NSDocumentController in Leopard does not allow you to override Unix permissions. In fact, NSDocumentController in Leopard is more strict than the Unix permissions: it won’t allow you to save a writable document when you don’t have write permissions for the enclosing directory.

You are correct that saving a document always deletes the existing file and creates a new one with a different inode, and you are also correct that some of the user-visible NSDocumentController warning messages are misleading. However, if you don’t have write permissions for a directory, then NSDocumentController won’t let you delete or add a file, and even if you do have write permissions for the directory, NSDocumentController won’t let you delete someone else’s file or add a file with the same name if the sticky bit is set.

Thus, I believe that the ramifications for system administrators are negligible. With certain Unix permissions, it has always been possible to delete a file in a directory and replace it with a new file of the same name. Leopard has not changed that at all, so system administrators should take the same precautions against this scenario that they have always taken.

-Jeff

You don’t have to take my conclusions for granted, though. In a matter of minutes, you should be able to throw together a bare-bones document-based application suitable for testing the behavior yourself.

I have no desire to discourage criticism of Apple or Leopard. There are major problems in Leopard, and I don’t yet find it acceptable for use as my primary operating system. I just think that this spurious security issue obscures the real issue of whether the new Leopard NSDocumentController behavior is desirable.

P.S. If you really want to talk about a waste of precious disk space, /Applications/Mail.app/Contents/Resources is an astounding 277 MB on Leopard.

Posted in Apple, Cocoa, Unix | 5 Comments »

News Flash: Vienna brings down the mighty NewsGator

January 9th, 2008

In an obvious gesture of defeat, NewsGator has announced that they — is a company a collective or an individual? — are no longer attempting to charge money for NetNewsWire. Their cover story is some mumbo-jumbo about “enterprise”. Sure, and Leopard was delayed by the iPhone. ;) What they would never admit publicly is that they realized it was pointless to compete against the best Mac RSS utility on the planet. Who would pay for NetNewsWire when Vienna is free? Not to mention open source! (Oops, I just mentioned it. I take it back.)

Let it not be said, however, that we are without pity for the downtrodden. On behalf of the Vienna developers, I apologize for destroying the commercial feed reader market. What else can I say? Ya gotta do what ya gotta do. Give the fans what they want. The battle has certainly made great entertainment, the classic David vs. Goliath tale. Once again, David (actually Jeff) has overcome insurmountable obstacles, beat overwhelming odds, leapt over tall buildings in a single bound, to emerge victorious. It’s always a thrill to see the underdog win … except the Miami Dolphins.

Yet I shall only allow myself a moment to rest on my laurels, to savor the sweet smell of success. (It smells a little like tequila, actually.) For I’ve already chosen my next target: outliners. Look out, OmniGroup!

Posted in Personal, Vienna | 4 Comments »

Logging in Leopard

January 6th, 2008

The release of Leopard has given third-party developers a lot to do: attempting to restore features lost from Tiger, for instance. (By the way, where is the second party, and why am I never invited?) My friend Rainer Brockerhoff has provided a way, or Quay, to display hierarchical popup menus in the Dock again. One of my most missed features in Leopard is using NSLog to spew output exclusively to Xcode’s console log. When you debug or run your app in Xcode on Tiger, you can put NSLog calls everywhere without worrying about polluting console.log. In my opinion, console.log is only for important messages and errors. I frequently ask users to consult it if they’re experiencing a problem with an app. Either that or the Oracle at Delphi.

Leopard dispenses completely with console.log, though there is a “Console Messages” database query in Console. Whereas on Tiger stdout and stderr standardly go to console.log, on Leopard they boldly go to system.log (as well as to the “Console Messages” query). On either version of Mac OS X, Xcode redirects stdout and stderr to its own console log, so they don’t appear in Console at all.

According to the documentation, NSLog sends a message to stderr. This is true for Tiger, and it’s also true for Leopard, but Leopard’s NSLog has the additional behavior of sending a message to system.log regardless of whether stderr is redirected. Thus, when you debug or run your app in Xcode (these may amount to the same thing in Xcode 3), messages from NSLog appear both in Xcode’s console log and in system.log! Curiously, there is no duplication of NSLog messages in system.log when stderr is not redirected.

If you prefer to keep your debug output out of system.log, the workaround for this new NSLog behavior is to abandon NSLog for debugging purposes on Leopard. :-( After much experimentation with asl, I realized that our old faithful printf would work. Since printf writes to stdout, its output is redirected by Xcode. Plus, when you’re debugging your app in Xcode you don’t really need NSLog to tell you the name of your app, the date, or your shoe size.

A limitation of printf is that it doesn’t handle the format specifier %@ for an Objective-C object. With Cocoa, therefore, we want an Objective-C wrapper around printf (like, um, NSLog). If you add the following code to your target’s .pch file, you’ll have an Objective-C debug logging function JJLog available throughout your target’s code. To enable logging in your app’s debug build, just add JJLOGGING to the GCC_PREPROCESSOR_DEFINITIONS setting (AKA “Preprocessor Macros”) in the debug build configuration.


#ifdef __OBJC__
	#import <Cocoa/Cocoa.h>
	#ifdef JJLOGGING
		#define JJLog(...) (void)printf("%s:%i %s: %s\n", __FILE__, __LINE__, __PRETTY_FUNCTION__, [[NSString stringWithFormat:__VA_ARGS__] UTF8String])
	#else
		#define JJLog(...)
	#endif
#endif

In your app’s release build, the debug function is a NOP that the compiler will almost certainly optimize out. This conditional code should not cause problems when using GCC_PRECOMPILE_PREFIX_HEADER, because Xcode already generates a separate precompiled prefix header for each build configuration. See the .pch.gch.hash-criteria files in /Library/Caches/com.apple.Xcode.###/SharedPrecompiledHeaders.

You can send gobs of gab to JJLog without repercussion or remorse. However, you’ll still want to use NSLog (sparingly, please) for runtime errors in your release build. Now to continue in the spirit of this post, I’ll redirect the epilogue to /dev/null.

Posted in C, Cocoa, Unix, Xcode | 5 Comments »

Behind the firewall

December 29th, 2007

Some people are apparently under the impression that firewall rules are the be-all and end-all of Mac OS X security. Deny all from any to me in. Before you spend days composing the perfect ipfw ruleset, however, take a look at sysctl. (You could spend days looking at sysctl.) One of the biggest misconceptions about Mac OS X — a misconception encouraged by the System Preferences UI — is that the firewall is not enabled out of the box. Nonsense!

net.inet.ip.fw.enable: 1

Admittedly, it’s a fairly flammable firewall (allow ip from any to any), but it’s enabled. More important, the default sysctl settings do provide at least a modest level of protection. For example:


net.inet.icmp.timestamp: 0
net.inet.icmp.maskrepl: 0

These prevent your machine from responding to ping -M time and ping -M mask requests. What time is it? Where the party at?

By Mac OS X herein I shall mean Leopard and Tiger. (Panther is not yet abandonware, but at this point it merely receives Christmas cards.) When you ‘start’ the firewall in System Preferences, Tiger adds a number of rules to ipfw. Leopard, on the other hand, includes a new Apple-designed firewall that mostly replaces ipfw. Though Leopard respects custom ipfw rulesets, it adds no rules to ipfw when you choose to block incoming connections. I don’t know much about how the Leopard firewall works; presumably it protects you somehow or other.

Leopard does still employ ipfw for “Stealth Mode”. If you turn that on, both Leopard and Tiger add the rule deny icmp from any to me in icmptypes 8. Curiously, Stealth mode prevents you from ‘pinging yourself’ in Leopard but not in Tiger. For fun (according to a rather loose definition of fun), try ping localhost. Somebody bring me a mirror! The difference in behavior is due to the Tiger-only rule allow ip from any to any via lo* that precedes all other rules.

Looking at the ipfw rules, you might think that Stealth Mode is overrated, like Notre Dame football and most wines over three dollars. If you want to learn its true value, you need to consult sysctl.


net.inet.tcp.blackhole: 2
net.inet.udp.blackhole: 1

With these settings, your computer mercilessly crushes attackers into singularities, as well as dropping their packets without response when sent to closed ports.

It would be nice if Bonjour wasn’t so talkative, broadcasting its greetings to your entire LAN. Bonjour also complains loudly when told to shut up by the firewall. On the other hand, you’re going to have to broadcast anyway for DHCP. Moreover, your LAN will see your internet traffic, especially on wireless.

Whoa, I suddenly realized after all these years that if you’re a grown man who lives in an attic, hangs out with high school students, has an ‘office’ in the bathroom, and is known for one syllable utterances, you’re not cool. You’re a loser.

Posted in Apple, Unix | Comments Off

How not to fix a build warning

December 22nd, 2007

The Hollywood writers strike continues, and the desperation grows for alternative sources of entertainment. Fortunately, we programmers can find entertainment in our own sources. I’ve got some reality programming for you! The following snippet of code is taken from an actual CVS commit. (Yes, CVS. Don’t laugh. Do cry for me, Argentina.) This build warning ‘fix’ was made by some contractor for some project that I worked on at some point in time for some company. To protect the innocent and/or guilty, I won’t say who, what, when, or where. As for why, I wish I knew. Or maybe not.


NSEnumerator* fileEnum = [fileArray objectEnumerator];
NSDictionary* aDict = nil;
//Changed to Remove the Build Warnings
//while(aDict = [fileEnum nextObject])
while(aDict == [fileEnum nextObject])

Let this example serve as a lesson. Not for programmers — the one who wrote it is probably hopeless — but rather for managers. Please do not just hire the lowest bidder!

Posted in C, Cocoa | 17 Comments »

« Older Entries
Newer Entries »