But what do you have to hide?

Excellent movie I had already seen, but I figured I wanted to share with people who feel less strongly about this.

Oh help, iPhones are evil!

News has hit digg that Apple receives iPod Touch / iPhone IMEI numbers when someone queries the Calculator, Stocks, or Weather applications on the aforementioned devices. What I am about to tell you might be too harsh, but consider it fueled by the thousands of comments streaming in about “… fanboys justifying this …” and “if Microsoft did this!…”.

Operators of cellphone networks use IMEI numbers, or model-specific serial numbers, to track subscriptions, usage, and identity of devices on the network. It’s in the specification for GSM and UMTS. You IMEI is transmitted at every communication with every cell tower in your vicinity. And now people are crying wolf that Apple might or might not service you Weather and Stocks if your IMEI number isn’t valid? Ladies and gentlemen, this is a standard part of a standardized specification that is over 20 years old. Get over it.

“Classic”; Security in Leopard goes leaps and bounds.

It’s a word we’ve been associating with OS 9. OS X has a ‘Classic’ mode to run legacy OS 9 applications, but we’re looking at a whole new ‘classic’ now.

Security in Leopard has had a roadmap of its own - after several developer builds in 2006, it became apparent that there was a lot of attention from Apple to invest in security; perhaps following the Month of Apple Bugs, but, most likely, to prove that now OS X is gaining is it’s user base, is still ‘the most secure desktop operating system’.

After WWDC ‘07, a few things have become more clear to me. What first was a loosely affiliated set of securing elements, has become an extremely intuitive addition to the standard way of doing things. A good example of how flawless these new security-improving additions are, I’ll take an example that’s just freshly new. In Tiger, we get a dialog when we open an application for the first time. It’s an informative dialogue, but it’s not really helping us in terms of finding out where the hell we got it. In Leopard, as you might have seen, there is a new downloading system. Downloads are placed in a new ‘downloads’ folder and in a download stack in the Dock, and even cooler, once you open a downloaded application for the first time, it pops up the same familiar dialogue. However, this time, it also shows where you downloaded it, and when. With a minimal addition, the user’s ability to stay secure has gained a lot.

Another good example are InputManagers. The ‘classic’ Tiger hacks that allow you to modify code at runtime, are disabled by default in Leopard. However, placing an InputManager file in the correct folder prompts you if you want to enable them. Safe by default, perhaps quite to the contrary when you compare it with Tiger.

Overall, there are a lot of things I don’t want to mention or cannot mention because they haven’t been shown in the SteveNote or otherwise broadly carried by the blogosphere. Some of these are so non-obvious that people just don’t bother to find out, I guess. But I can guarantee you that you’re in for a completely new experience once you switch from Tiger to Leopard. And it won’t be like going from XP to Vista; you’ll actually feel like you’re more in control, all the while clicking less buttons to achieve that feeling.

Apple has a very clear message; I think that once Apple is around to releasing Leopard, you can go ahead and write malware; see if it works. In an OS that has code-signing, sandboxing, and other fantastic new hardening efforts all built-in, we’re safe. I think I’ll have some vacation instead of having to write a new “A more secure OS X before 10.6″ ;).

Juicy Leopard Security details on Apple.com

The new Apple Leopard page lists a specific tab under “Technology” about security. Some interesting points are there, and I must say, some promising developments on this front.

We’ve seen the sandbox daemon in the Leopard preview builds, but while I pointed out that there were some default services running that were subject to exploitation, it seems Leopard will have some protection to these ‘problems’. From the Apple site:

“Helper applications in Leopard — including the network time daemon and the Spotlight indexer — are sandboxed to guard against attackers.“

Now that’s a good improvement. But there’s more.

“…files downloaded using Safari, Mail, and iChat are screened to determine if they contain applications. If they do, Leopard alerts you, then warns you the first time you open one.”

There’s one less avenue for malicious content being automatically opened. Given the track record of Mac users buying the upgrade of their favorite OS, we’ll see a lot more secure population in October. But wait, there is, indeed, one more thing.

“Leopard can use digital signatures to verify that an application hasn’t been changed since it was created.”

Why of course it can! After all, didn’t it use ZFS? Which does has the ability to checksum everything. We can also use Filevault, which isn’t really discussed on the Apple site, but uses a new encryption scheme, of which details are unknown at the time of writing. Fortunately;

“The Disk Utility tool in Leopard helps you create encrypted disk images using 128-bit or even stronger 256-bit AES encryption.”

And Apple Mail already supports signing certificates and authorities. This is getting a great OS for using the many facilities of securing your digital life. Strong new encryption possibilities are great. On Apple’s security page, they underline their commitment to keeping the kernel open-source, which, in my opinion, is also a critical part of the security and integrity of OS X.

That was it for now. If some of my fellow developers come back, I’ll have the penetration tests on the beta ready for everyone.

IPv6: Unforeseen Consequences.

You know, Iljitsch van Beijnum posted here today, and it reminded me of a funny thing that keeps coming up if I speak to some people that took my how-to on securing your Mac serious. Iljitsch does a lot of articles on IPv6 over at Ars Technica and he’s written up quite a lot on it (in print too). Check out is website and his books.

For the uninitiated; we use IP numbers on a network as an address. The number space of IPv4 has shown to be too limited for our growth (if you want to read more into this, check this out).
IPv6 is, for the semi-geek, an extremely scary concept because it makes them feel like all their knowledge of networking will become obsolete. The ‘long and complex’ number system and all of it’s features (that are really, really much nicer to use than the old decimal ones once you get around it) are subject to much critique in any IPv6-related Slashdot post. Over and over again, it’s supposed ‘pitfalls’ are exposed. I was extremely surprised to find that when I spoke to some people that followed my how-to (which Iljitsch put on Ars Technica appropriately as “Make your Mac more secure (than you can stand)” ), that when I brought up using IPv6 with IPSec-enabled services is quite secure - more so than conventional IPv4, of course, they pointed me to my how-to, that told them to disable IPv6. I really slapped myself to the forehead when I heard that from more than three people who took it to the heart.

What I suggested is that you disable IPv6 if you don’t use it. IPv6 is pretty cool. It’s not a gaping security hole, but I touched on any hypothetical avenue for attack that you can take away from the default configuration. Who knows, there might be a zero-day exploit out there that does do nasty stuff but breaks if you disable IPv6 (which I strongly doubt - but it’s a quantum universe we live in). Please don’t hesitate to adopt IPv6 if you feel like learning about it. It’s knowledge that you will, no doubt, have to use in the future anyway.

So apparently, IPv6 has some identity issues. We really need to get rid of the negative image. KAME has been doing that well, as well as the “ASCII Star Wars in your terminal” server towel.blinkenlights.nl. However, let’s keep showing people that IPv6 isn’t all that scary, but i
t’s a great step into the future of our communication technologies. For that, a little icon.

Isn’t this hilarious?

OK, it only affects some older Macs, but a lot of people still use iBooks. I hope they didn’t find this because I told them to put a firmware password on there ;).

Via waffle; Open Firmware Password not recognized when beginning with capital “U”. (apple.com)

I do find this incredible. I mean, I really have to think quite hard how you are going about things if you manage to create a password scheme that can produce such bugs. It’s all the more important to know that you can bypass firmware passwords by changing memory configuration - something quite effortless on most portables these days. That goes for EFI and OpenFirmware.

On an unrelated side note, RSS reader icons with jet fighters flying over kick ass.

Portmap. You fiend.

Portmap, a UNIX daemon made to supposedly make it easier for everyone to find out what ports services are listening on, seems to be dead essential in ad-hoc Ethernet-to-Ethernet networking with a static IP. I always give my home boxes IP’s in the strictly forbidden IP range 10.x.x.x (I’d be better off taking 192.168.x.x) and connect them with a CAT5E cable (for gigabit speeds or at least half of it) whenever I feel like it. I was dumbfounded to find that two Macbooks, one my own and one out of the box, will simply completely drown in an ocean of confusion when the daemon isn’t running on the serving system.

The context-sensitive autoconfigurator for network settings in OS X didn’t like it at all. I also have strict rules against named (the DNS server), bonjour (zeroconf) and I let in AFP with a temporary rule. No catch. The connecting party couldn’t find services, and the link refused to establish in most cases (i.e. jumping from self-assigned 144. addresses to my own 10.x range). I could disable the firewall. OK, still nothing. Obviously, this isn’t related to my nazi ipfw configuration. Could it be that I have stopped some services from running in the first place? Yup. I had portmap disabled. Bonjour was fired up and restricted with ipfw because Aperture throws a fit without it running (Read: it gives an error message with the rather descriptive text: “Error. 2.“.), which is a bit insane as I haven’t found it to be a nice enough app to go share my photo collection over the network with bonjour, which iPhoto does for free.

Nearing the end of this rant, it’s obvious what I am telling. Hardening always gives you trouble to get into your own computer. You know, that really the way I like it. But I don’t consider acquiring a link a real security issue, so I’ll have to fix this. Strangely, whatever security measure I took in the how-to’s I served, did not affect these problems. Rather, it was the portmap daemon that ships with OS X that seems to be much more essential to it’s networking than I thought. I’ll look into this, because portmap has it’s history, especially with RHEL. I don’t know what those guys in Cupertino were thinking when they were soldering in portmap with liquid steel, but I’d rather just run without a whole lot of services.

Interview with Obdev, creators of Little Snitch.

Since it has been a bit silent on the security side of the blog lately, I have been working on some additions that are in line with the original nature of the blog. This week an interview with Johannes Tiefenbrunner, developer at Obdev in Austria, known for the premier Mac firewalling program Little Snitch, that protects you against potential trojans, outgoing connections (applications phoning home) and lately, even code injection. Obdev is also known for Launchbar, a very popular launcher application for OS X.
So, here’s the interview, in which I ask them about those cool features like code injection prevention, the future and past of Little Snitch (like Leopard) and even it’s icon. We also touch on OS X as a secure platform and it’s future.

1. Cocoia: Hello! You’re the developers behind the widely used security program for the Mac, Little Snitch. Could you tell a bit about your company?

Obdev: We kind of stepped into the Mac area via the side door: We’ve been developing software for the NeXT platform - e.g. LaunchBar actually started on the NeXT. When NeXT and Apple joined and the NeXT (OpenStep) technology became “Cocoa”, we were able to use our rich experience for the Mac.

We also develop for other *nix based platforms - our SMB network client Sharity supports several *nix flavors and our WebCMS WebYep, being PHP based, is cross platform anyway.

But we definitely can say that developing for the Mac is incomparably more joyful ;-).

2. Cocoia: Little Snitch has been among us for quite some while. What was the initial impulse to begin development on Little Snitch? How old is it now, exactly?

Obdev: The first version of Little Snitch was released in February 2003.

The idea of such application came up when we installed a new version of a well known application from one of the big software companies. There were rumors that this new version phones home, but nobody had definitive information since ordinary users weren’t able to verify this at that time. Curious as we are, we dove down into the Unix level of Mac OS X and by running some network sniffing tools found that the rumors were true.

We did not like the idea that any application can send data anywhere without our knowledge. The user should be informed and be able to decide. That’s why we created Little Snitch.

3.Cocoia: Have there been specifically hard points for you, like OS transitions and uneasy development challenges?

Obdev: Every Mac OS transition has the potential of requiring severe redesigns of Little Snitch - working in close contact with the lower levels of the operating system results in a greater dependency to that system’s implementation details.

But on the other hand this also makes it more challenging than the “usual” Mac OS application. Covering the whole area, from the kernel level up to the GUI, makes Little Snitch a very interesting project.

4. Cocoia: I have noticed that the latest versions of Little Snitch have improved protection from other, slightly related security issues like code injection. That’s quite a feat. What prompted the addition of this feature, and do you plan more extensive features like this in Little Snitch for the future versions?

Obdev: We have no plans to make Little Snitch into an “all-round security tool” with virus scanner, malware detection, firewall etc. - these things are not Little Snitch’s job. But whenever Little Snitch itself is endangered by some security problem, like it was by the code injection issue, we will protect it.

5. Cocoia: Little Snitch’s icon has had some criticism by bloggers and commenters on websites alike. What are your thoughts on this?

Obdev: To be honest: This is totally new to us. We actually have seen very positive response to Little Snitch’s icon - like on Starry Hope.
But this of course is a subject of taste. We currently do not have any plans to change the icon, but the upcoming Little Snitch 2 (currently in closed beta) will include improvements also on the visual side as well as in usability and functionality.

6. Cocoia: Is there a special version of Little Snitch for Leopard in the works? Is there anything you can divulge about this?

Obdev: With every new pre-release build of Leopard we adapt the current beta of Little Snitch 2. When Leopard is officially released, we will have a compatible version ready.

7. Cocoia: What are your thoughts, as a developer of premier security software for the Mac, as OS X’s security status? Do you think the future is grim, or do you have faith in the strength of a well-designed OS?

Obdev: We think that with Mac OS X Apple has a very good chance to offer the best and also most secure desktop operating system available. As always, there’s room for improvement, but beside other advantages, Apple has one big pro: They always had the guts to redesign core parts of their OS whenever they found a better solution instead of clubfooted dragging old designs into new OS version just for the sake of compatibility.

8. Cocoia: All right, thanks for the interview!

Obdev: Our pleasure - good bye!

I want to thank Johannes for this great interview and taking the time for having it.

Debunking MacLockPick.

SubRosaSoft announced the release of MacLockPick recently. It’s supposedly a product for law enforcement agencies (supposedly, because there is no ‘try before you buy’ - quite a jump to take for a 600-dollar app, cough, memory stick) and it’s claimed to ‘crack any password on a Mac’.

When clicking further than the all too speculative headlines from news websites, you quickly discover some facts about MacLockPick; 1.) It’s entire working is apparently based, according to their site, to the default setting of the OS X keychain to be ‘opened’ to use. This means anyone serious enough about computer security will be able to harden themselves against it. To quote SubRosaSoft;;

MacLockPick takes advantage of the fact that the default state of the Apple Keychain is open, even if the system has been put to sleep.It also makes use of the openly readable settings files used to keep track of your suspect’s contacts, activities and history. These data sources even include items that your suspect may have previously deleted or has migrated from previous Mac OS X computers.

Oh my, we got a disaster on our hands! Macs are insecure by default! Want to prevent nasty government agencies from stealing your keychain? Read up on UNIX. Oh yeah, that advice I gave about ten times in one of the most popular OS X security how-to’s on the web also stands; any standard non-admin user will not be able to get access to those logs.

While all these statements are made here, I can honestly say I don’t know how the supposed agencies will be able to simply parse the keychain passwords to disk. If you have the keychain open, and an application tries to fetch passwords, the Keychain Agent will ask you if you want to allow access. I suppose one could automate with OSA to just ‘allow everything’, but that would really mean our implementation of the Keychain is flawed. You could also think in the sense of the InputManagers and other injection hacks that can replace such system services with their customized code (actually working example at the bottom of the page). Anyway, I’d love to get my hands on this software to see if it exploits a fundamental weakness in OS X. I am still quite sure, however, that if you follow the advice I have given in my how-to, there won’t be a slim chance in hell that MacLockPick is able to retrieve a single password from your computer. They’d have to bruteforce it.

Little Snitch deserves a post on it’s own.

Little Snitch, together with Glowworm FW got a mention on my “Secure OS X” article. When I started doing more work on a PowerMac G4 of a company, which had Little Snitch installed, I wanted to inject an F-Script workspace into Praetorian for some clean testing. Little Snitch amazed me.

I don’t know how it achieves this (trapping system calls, most likely) but it’s quite a feat to be able to stop an arbitrary code injection like that. Firewall? No, this has gone beyond and above firewall. This is a program for security-oriented users. How’s that for being in control?

If these people start adding even more features (and I have no doubt that they will) I will become a great, great fan of Little Snitch. Now, if only the icon were better. But there are designers like me and other far greater people (Adam Betts, I’m talking to you!) who love to design replacement icons. I think both firewall programs, in general, could use more interface and icon design love. But they already provide excellent, stable functionality. Go check them out.