Archive for the ‘security’ Category

Apple’s TextEdit App. Can Erase Your Files

Tuesday, May 12th, 2009

Icon of the TextEdit Application.Apple’s TextEdit application has a massive design flaw that could potentially erase other files on your computer. Weird, right? Ironically, it’s TextEdit’s safeguard against loss of data that is the culprit of the defect. And the corruption of files isn’t a randomly occurring glitch either — it is caused by a shortcoming of the algorithm used in the Autosave feature.

The Autosave Flaw

When editing a document in TextEdit, a copy of your work is automatically saved every 30 seconds to the hard drive*. This behavior is common in software as it provides a convenient means to recover some of your work should the application unexpectedly quit or crash.

Unfortunately, the means by which TextEdit saves a copy of your work is awfully rudimentary. It simply writes your data to a regular file and gives it the same name as your TextEdit document but with “ (Autosaved)” appended as a suffix (without an extension). And since no verification is performed to see if a file with that particular name already exists, it will overwrite anything that gets in its way with no confirmation or warning!

Example

To better illustrate this flaw, take the following scenario. Suppose, for whatever reason, that I have a file named Craziness (Autosaved) and I create a text document called Craziness.txt in the same directory. In the screenshot below Craziness (Autosaved) is an image file (with the extension removed in order to illustrate my point):

Screenshot of my 2 original files.

When I start editing my Craziness.txt file in TextEdit, the application autosaves my work (as it should), but since my image document has the same name as what TextEdit would call its autosaved file, my image file is overwritten:

Screenshot of TextEdit's autosaved file.

When I’m done editing my Craziness.txt document, TextEdit removes the autosaved copy (as one would expect). However, now my original image file is gone with no real way to recover it (since it’s not moved to the Trash but actually overwritten):

Screenshot showing loss of data caused by TextEdit.

Solutions

Accounting for this file naming issue is so programmatically simple that it’s astounding the defect even exists. The simplest improvement would be to prefix the filename with a period (as in .Craziness (Autosaved)) in order to hide it from the Finder since the chances of having a naming conflict with a hidden file are greatly reduced.

But hiding the file from the user still allows for potential name collisions and as Mac OS X’s default text editor, TextEdit’s naming convention should be even more robust. To start, TextEdit could include either a timestamp or a sequence of random numbers to help make its autosaved filename unique. Most importantly, however, should be to verify if a file would be overwritten and if so, generate a different random number or append an incremental counter. Heck, even my Page Capture widget won’t overwrite files since it uses the same naming convention as Apple’s screencapturing application (File 1, File 2, File 3, etc.)

The Rant

One might argue that the possibility of having a file end with “ (Autosaved)” and not have an extension is pretty slim. So what? My argument is that the possibility of an application deleting other files blindly is a completely unacceptable use case scenario, no matter how rarely it may occur. I think it is more reasonable to expect that a corporation as large as Apple Inc. would produce software that doesn’t delete unrelated files from my hard drive without my knowledge. Especially since OS X is — as Apple claims — the “most advanced operating system in the world.”

*30 seconds is the default. The time interval is configurable and the user is allowed to disable the Autosave feature entirely.

Apple Security Threat

Thursday, November 6th, 2008

A recent occurrence has made me think twice about Apple’s Target Disk Mode boot option. Indeed it can be a very convenient feature, but like most conveniences this one is riddled with security threats. What is most bothersome, though, is how few people realize the problems it poses — not to mention the simplicity of a solution that Apple does not provide…at least not by default.


For those of you not up to speed, most of Apple’s computers allow themselves to be temporarily turned into an external hard drive simply by pressing the corresponding hot key (‘T’) during boot up. If the computer supports this option (most do) it will enter what is called Target Disk Mode (TDM) and allow itself to become a mass storage device and be connected to another computer via an IEEE 1394 interface (aka FireWire, i.LINK, Lynx…whatever).

Yes, this feature is convenient for transferring large amounts of data or if you need a quick makeshift external hard drive (assuming you have a male-male Firewire cable). Unfortunately, the feature also inherently bypasses the OS from ever being started on your computer allowing others access to all sorts of files that you assumed were secure by the OS’s login.

How It Works

When you press the power button on your computer the first thing to come to life is the firmware (a very low level program that lives in the hardware) and it decides what happens next — whether to boot into the installed OS, boot from a CD, boot from a network drive, etc. The decision is based on multiple factors, one of which is to check for certain hot keys on the keyboard.

The Problem

The problem with this convenience is that anyone with a finger has the ability to transform your computer into a large external drive. Yeah, including that person that just walked away with your laptop while you were getting another soy latte at Star Bucks.

Some would argue that if I’m this concerned with the security of my files, that I should enable FileVault in order to encrypt every file on my hard drive. Yeah? Well, I don’t think I should have to enable something that will have incredible amounts of overhead just because a back door exists that can completely circumvent the OS’s login prompt.

Solution (but not really)

Firmware Password Utility ApplicationThe solution is simple: eliminate the hot keys from influencing the firmware’s decision. Welding a steel plate on top of your keyboard would work I guess, but that’s not very convenient. A better idea would be to tell the firmware to not check the hot keys.

Currently, there is no way to disable these hot keys, but it turns out there is a way to password protect the firmware with some extra software. But after reading Apple documentation that states that the firmware password can be circumvented (quite easily), and that it could in fact be hazardous to your system, and that it is temperamental, I disabled it on my machine and don’t recommend it. Way to fuck us over, Apple:

“WARNING: Open Firmware settings are critical. Take great care when modifying these settings and when creating a secure Open Firmware password.”

“An Open Firmware password provides some protection, but it can be reset if a user has physical access to the machine and changes the physical memory configuration of the machine.”

“Open Firmware password protection can be bypassed if the user changes the physical memory configuration of the machine and then resets the PRAM three times (by holding down Command, Option, P, and R keys during system startup).”

The Rant

First of all, I think that the extra Firmware Password Utility (not included in a default installation…but available from the software installation disc (/Applications/Utilities/) and online) should not be necessary. I think there should be a simple check box in the System Preferences that enables/disables whether or not the keyboard is “heard” by the firmware.

I also think that the hot keys should be disabled by default. Apple is all about an ‘out of the box, ready to go’ mentality so I suspect they leave the feature enabled by default because that makes it more convenient for their users to make use of the TDM functionality. We’ve seen this same behavior before, but I think the security threat outweighs the convenience factor. Tisk, tisk Apple.