Hacking on Empty

It’s uncharacteristic of Apple to announce things so for in advance of their availability. Usually they wait till the hardware is going into production. I can think of only three times they have done this recently: the watch, the phone, and the x86 switchover.

I’m sure Apple would have preferred to release the watch fully formed and ready to go as a surprise in the spring of ’15. However, it would be impossible to make a product of the quality that Apple desires while keeping it a secret from most of the company. That’s why I believe the announcement was not directly for the public’s benefit. Instead, Apple announced the watch far in advance of availability mainly to inform their employees.

With the watch public knowledge, everyone at Apple can get excited about it and make all of Apple’s products work with the level of integration that their customers expect. It would be impossible to keep it a secret if everyone at the company was aware of it so Apple made a dramatic public announcement. That way they also get to control the message, kill competitors, and deny months worth of leaks to naughty reporters and rumor sites. Same deal with iPhone and x86. Achieving success as defined by Apple required a concerted effort by most of the company.

The downside: competitors get some extra time to try to copy it. That’s why Apple only does this for the really big changes.

Shellshock is going around but there is not so much commentary about why it isn’t so shocking to people who have been around a while. Here’s some sage advice from a couple of legends in the security field.  Simson Garfinkel and Gene Spafford wrote Practical UNIX and Internet Security 20 years ago. Even then, it was well known that shells and untrusted input were bad news.  From the second edition (1996.) Emphasis is mine.

18.2.3.2 Testing is not enough!

Many programming languages, including C, ksh, sh, csh, and Perl, provide the means to spawn subprocesses. You should try to avoid using these features when writing CGI scripts. If you must spawn a subprocess, avoid passing through any strings that are provided by the user. If you must pass strings from the user to the subprocess, be sure that it does not pass shell meta characters including the `$|;>*<&> characters.

23.2 Tips on Avoiding Security-related Bugs

Check anything supplied by the user for shell meta characters if the user-supplied input is passed on to another program, written into a file, or used as a filename. In general, checking for good characters is safer than checking for a set of “bad characters” and is not that restrictive in most situations.

Shellshock is just as much an error by the developers of calling programs as it is a bug in the shell. Sure, the shell shouldn’t execute random stuff placed after a function definition in an environment variable but you probably don’t want random people on the internet defining functions in the shell you’re using to execute stuff, either.