Subscribe to
Posts
Comments
NSLog(); Header Image

Security @ Apple . Com

John Gruber, in Security Cannot be Spun, poignantly takes Apple to task for trying to milk PR from recent security updates. The help:runscript vulnerability is the leadoff batter, and Gruber points out that Apple didn't seem to act on the issue until it was made public - having failed to do so when the vulnerability was reported on February 23. Gruber admits that Apple simply may have taken this long to fix the issue, but criticizes Apple for their handling of the situation:

Ostensibly, Lixlpixel did the right thing, or at least did what Apple would prefer people do when serious vulnerabilities are identified. Ideally, notifying Apple privately would engender the same response as publicizing the vulnerability in the press.

A quick look at the reporter's site provides this gem:

i told Apple on 23rd of February about this and never got any reply.

The thing is this: how did he report it to Apple? Did he send an email to feedback@apple.com or fill out the form. Did he call and leave some sort of voicemail with Apple PR?

I wouldn't expect any of those methods of notification to receive a response. Apple gets thousands of general emails per day and I could easily see how one might be lost in the shuffle.

I think we can come to three conclusions here.

One: Benefit of Doubt
It's easy for me to give the benefit of doubt to Apple regarding the date on which it became aware of the vulnerability. Lixlpixel does not tell us how he contacted or informed Apple of the problem on February 23: who's to say Lixlpixel even contacted Apple at all? I'm giving Apple the benfit of doubt here: they weren't actually aware of it until it became general news.

Two: Apple's PR Handling
The above in no way dismisses Apple's poor PR handling of the issue. John talks about this in far more depth than I am here, so I encourage you to follow that link for more. I agree wholeheartedly with most of what John says and disagree only on the suspicions regarding the February 23 notification.

Three: /security/
The confusion over how Lixlpixel notified Apple exposes an incredible flaw in Apple's handling of potential security threats. If Apple were serious about Security, apple.com/macosx/security/ would not be 404. The only words containing "secur" on apple.com/macosx would not relate to FileVault. Does security@apple.com go anywhere or does it bounce? Perhaps it goes to campus security? Why is it that the only RSS feed Apple offers with "security" in the title is for software downloads (Networking & Security Downloads)?

In other words, the lack of a clear means of notifying Apple about security issues is yet another way in which Apple has failed to properly and fully address security concerns in Mac OS X. I'm sitting here with various protocols disabled simply because I'd rather not be one of the first few people tricked into letting an exploit run rampant on a system in which a vulnerability still exists (with AFP, FTP, etc.).

Apple isn't taking security seriously. It needs to. It could communicate better (and not with PR fluff and lies) and it could let its users know where they stand.

P.S. I received an auto-response from security@apple.com. Here it is:

From: aplsecurity@apple.com
Subject: Auto-Response To Your Email

[NOTE -- THIS IS AN AUTOMATED RESPONSE]

This e-mail is confirmation that your request for assistance has been received by the Apple Corporate Security Department.

We appreciate your contacting us and consider your communications with us to be very important. Please know that your message will be reviewed promptly.

If your message pertains to the security aspect of a software product shipped by Apple, please re-send your message to product-security@apple.com.

Thank you,

Apple Corporate Security

9 Responses to "Security @ Apple . Com"

  1. I agree that it would be a good idea to have a simple to remember address like "security" but for now, the best place to post these things is Apple's Bug Reporter.

  2. Search on apple.com for "security" and you get as the first hit.

    http://www.apple.com/support/security/

  3. http://www.apple.com/security/ redirects to http://www.apple.com/macosx/features/security/ which is basically what you were looking for. That page has a link to "Apple Security" which redirects to "Apple Product Security" at http://www.info.apple.com/usen/security/index.html where you find contact info, PGP keys and the address for the security-announce list, etc.

    And Lixlpixel reported the concern from Bug Reporter as he's stated previously so someone sat on it for two months like any other bug. 🙂

  4. Having been through the process of notifying Apple about a security issue in OS X, my conclusions are: that they take issues seriously but remain relatively quiet about them until a proper fix is in place. I think the issues around the URI handlers have been over hyped; in particular John Gruber's latest outburst is unbalanced; I do not agree with his (or your) perception of Apple's take on product security. The coverage in the media may have 'forced' Apple to release a sub-standard fix?

    As has already been pointed out above: a little bit of effort on the part of the user yields http://www.info.apple.com/usen/security/index.html. Plus subscribing to the 'Security-Announce' (see URL) list will keep one up-to-date on the fixes as and when they become available. I believe that the pre-fix hype just made the problem worse in this case.

  5. Benjamin, I disagree that I'm overhyping it.

    There are still serious flaws in the Mac OS X that could be exploited rather easily. We're still unaware that Apple even recognizes these holes, let alone what plans they may have to fix them.

    I never suggested that the media coverage "forced" Apple to release a sub-standard fix, nor did John Gruber. The fix is a nice stopgap, but does not solve the larger issue of auto-URI registration (without warning) and possible execution of nonstandard URI schemes.

    Basic security should require almost no "effort" on the part of a user. I am aware of Apple's security pages, but still the point remains that the effort I did put in was rewarded with 404s. We're in the dark as far as OS security goes. But hey, if you don't believe me, I know of a pretty cool shareware game you should check out…

  6. So because you guessed at URL and didn't hit on something it is Apple's fault. Are they supposed to think of all of the variants or URLs that folks may come up with (in which languages)?

    Get real... use Apple's website search which is available on every page ("security", "security incident", etc.). May be Apple should make it a little more top level but for folks that report security issues they can find how to do it easily and/or report it to the various third-party security monitoring groups which will report it to Apple.

    Also note the large list of security fixes, some of which are actually remotely exploitable without user action (unlike the URI issue) that Apple has fixed. They didn't get hyped and yet Apple fixed them. Apple fully understands, tracks, and fixes security issues as they learn of them and release/testing allows. Just look at the history and here.

  7. Yes, Apple should think of the obvious URL variants. Apple hasn't fixed the URI issue: nor have they confirmed whether they still believe it to be a problem in need of a solution.

    Yes, an app can go around willy nilly deleting things when you launch it. You bet. However, applications need to launch and access files, and throwing up a dialog box to confirm an application's actions (including CLI apps) is silly. Apps need to launch.

    The difference with URI schemes is that very, very few applications need to register their own URI schemes. Something can be done here, and Apple's yet to tell anyone whether they're aware of the problem, working on a fix, or don't consider it to be a problem at all.

    "Mum's the word" is not a security policy. It's a cop-out. Spinning security fixes with mistruths and PR after the fact is merely a bad aftertaste.

  8. The difference with URI schemes is that very, very few applications need to register their own URI schemes.

    I can't say I agree at all.

    Very few applications need to register a URI hander, that's right. Yet, I would also say very few programs need to register a cron job, or a Startup Item, or a Dock icon, or a Login Item (just as bad!) or any number of other things on a computer that can range from annoying to critical. Registering a URI handler is significantly lower on my list than giving me a dialog when adding something to /Library/Startup\ Items or to my Login Items list.

    Something can be done here, and Apple's yet to tell anyone whether they're aware of the problem, working on a fix, or don't consider it to be a problem at all.

    My money's on "doesn't consider it a problem." I'm in for $20. Anyone want in?

  9. Apple, Mac OS X and security

    There is quite a debate raging right now over Apple's handling of the latest security flaw in Mac OS X. John Gruber writes a rather scathing piece entitled "Security Cannot


Comments RSS

Leave a Reply


Warning: Undefined variable $user_ID in /var/www/vhosts/nslog.com/httpsdocs/wp-content/themes/nslog/comments.php on line 96

Please abide by the comment policy. Valid HTML includes: <blockquote><p>, <em>, <strong>, <ul>, <ol>, and <a href>. Please use the "Quote Me" functionality to quote comments.