Yesterday I booted up my Dell Mini 9, and got the message "No Airport Card installed". Huh. It's running Mac OS X, but haven't had a problem at all. After trying a few things, and doing some searches, this finally worked for me (original thread at http://www.mydellmini.com/forum/dell-mini-9-os-x-discussion/13909-osx-10-6-wireless-wifi-issue.html):

"you can try deleting com.apple.airport.preferences.plist, NetworkInterfaces.plist, and preferences.plist form /Library/Preferences/SystemConfiguration and restart to get the airport interface working again"

Voila! Problem solved.

I had this nice long post about this problem, but hit the wrong key and accidentally opened up my bookmarks, and lost the entire post, so here's the short story:

If you're having problems (like I was) getting decent prints from Lightroom 2 to an Epson R1800, try this: download the European Epson driver. I saw that solution posted on the Adobe forums, and I couldn't believe it worked, but it did!

Previously, all my photos were coming out extremely dark, and after tons of ink, paper, time, and effort wasted trying to fix this, I was ready to list the printer on Craigslist to sell. Once I downloaded and installed the European driver, I seem to be back in business!

Our friend Andy Ihnatko was in town last week, and we met up at the Pancacke House in Boulder. Geeks as they are, Michelle and Andy started taking photos of each other, turned out to be a pretty cool picture:

This is a collection of small hacks and tips for the iPhone. Nothing fancy, but helps me keep track of these things, and maybe someone will find them useful too.

So, for the second or third time, I read on Slashdot about people complaining about the "serious security" problems with MacOSX. I finally couldn't stop myself from posting to one of these discussions, not because I'm a Macintosh fan, but because I find it prepostoreous to even call this a bug.

As far as I'm concerned, Apple has implemented their solutions as per specifications. They probably could have made better documentation, GUI/tools and training around the well known security issues around DHCP in general, and the LDAP option in particular. And arguably, using DHCP with the LDAP option like they did might have been a poor design decision, but it was no less secure than their previous systems afaik (e.g. Netinfo).

I first posted this response to the latest /. article:

I still don't understand why this security "hole" got so much attention... Are people struggling
to find problems with MacOSX? First of all, attacks like this is nothing new, just remember the
old YP/NIS problems with broadcasting for the server, to mention just one example.

Secondly, when we wrote the DHCP LDAP option specs way back when, we explicitly
documented this problem in the security section:

    5. Security considerations

    Security considerations discussed in [3], particularly with respect to the
    provision of authentication information, are directly applicable here.
    Additionally, it should be noted that providing LDAP server information by
    a broadcast protocol such as DHCP may allow unauthorized clients to learn
    the location of and authentication information for LDAP servers and hence
    pose as valid clients. This presents a security problem when sensitive
    information, such as user passwords, is published via LDAP servers.

    The DHCP protocol provides no mechanisms for the client to verify the
    validity and correctness of the received information. The security
    considerations in [1] discuss several weaknesses, particularly the problem
    with unauthorized DHCP servers.

This was written in 1997, note the last paragraph above. These issues have been discusses
and documented in several RFCs, many years ago...

Someone posted a question asking if this was a MacOSX specific problem, to which I responded:

Well, DHCP is inherently insecure, so this is definitely not a MacOSX specific "bug" (but I
personally don't consider it a bug). This is all well documented in the DHCP RFCs and docs,
e.g. from RFC 2131:

    7. Security Considerations

          DHCP is built directly on UDP and IP which are as yet inherently
          insecure. Furthermore, DHCP is generally intended to make
          maintenance of remote and/or diskless hosts easier. While perhaps
          not impossible, configuring such hosts with passwords or keys may be
          difficult and inconvenient. Therefore, DHCP in its current form is
          quite insecure.

          Unauthorized DHCP servers may be easily set up. Such servers can
          then send false and potentially disruptive information to clients
          such as incorrect or duplicate IP addresses, incorrect routing
          information (including spoof routers, etc.), incorrect domain
          nameserver addresses (such as spoof nameservers), and so on.
          Clearly, once this seed information is in place, an attacker can
          further compromise affected systems.

          Malicious DHCP clients could masquerade as legitimate clients and
          retrieve information intended for those legitimate clients. Where
          dynamic allocation of resources is used, a malicious client could
          claim all resources for itself, thereby denying resources to
          legitimate clients.

I think what makes MacOSX "unique" is that they use services traditionally not provided by DHCP (in this case, LDAP server information). Just like with NIS/YP, we have a tradeoff between ease of deployment (automatic service discovery) vs strong security. I know for a fact that way back, many YP/NIS deployments got hacked (in open networks, most commonly Universities) by simply pretending to be an NIS server. NIS+ addressed this problem (and others), and made it close to impossible to deploy and maintain. :-)

I don't know what Apple will do to "secure" this, the natural solution seems to be to have the DHCP client limit which servers it will talk to (establish a trust relation). It could be done with something as simple as a DHCP server host list, or more likely using Kerberos tickets to verify the authenticity of the DHCP response (I'm no Kerberos expert, so don't quote me on that one). More than likely, it'll make deployment a bit harder that what it is now.

Nothing new about this at all....