5 ms·

The story has been updated with the following: "Apple issued a new, stronger (SHA-2) Mac App Store certificate in September, before the older (SHA-1) one expir

by dak1 11y ago

The story has been updated with the following: "Apple issued a new, stronger (SHA-2) Mac App Store certificate in September, before the older (SHA-1) one expired, as planned. The new Mac App Store certificate was using the current, strong SHA-2 algorithm. However, some apps were running receipt validation code using very old versions of OpenSSL that don’t support SHA-2. OpenSSL started supporting SHA-2 in 2005, which is why Apple didn’t foresee this issue."

lambada 11y ago
This needs to be upvoted, and the title changed. Turns out it was due to developers using incredibly old security code. Rather than an expired certificate.
- whatever_dude 11y ago
  Yup, this changes my own point of view from "Gee Apple what a blunder" to "Some developers can be really dumb".
  - mikeash 11y ago
    Apple built a lame DRM system, tossed out some half-baked sample code, and then told third parties "OK, you guys go implement this yourselves" without even so much as providing a library to help with the hard parts. Then they made a pretty substantial change without even checking to see if all of these one-off third-party implementations could deal with it.
    - lambada 11y ago
      Given that OpenSSL has supported SHA-2 since 2005, and the Mac App Store was announced in 2010, then released in 2011, I'm really not sure you can blame Apple for thinking it'd be reasonable to expect App Developers to not be using 5 year old versions of dependencies.
      - mikeash 11y ago
        Why not? When you're running a service like this, thinking instead of checking is not a wise move. How much time would it have taken to whip up a script that just tests all of the apps in the store? Even if it's a week of an engineer's time, that seems worthwhile. Testing whether the apps in the store actually run when presented with a valid receipt should already be automated anyway. I'm looking through Apple's guidance here: https://developer.apple.com/library/mac/releasenotes/General/ValidateAppStoreReceipt/Chapters/ValidateLocally.html https://developer.apple.com/library/mac/releasenotes/General... The only thing they say about which version of OpenSSL to use is that you need to bring your own and not rely on the one that ships with the OS, because Apple is still shipping a version of OpenSSL from 2005. They do not say anything about which version of OpenSSL you need to use or what capabilities it needs to have. I bet a lot of people were using Apple's OpenSSL for this originally, and when it was deprecated the path of least resistance would have been to bundle the same version Apple ships.
        reaperhulk 11y ago
        To be clear Apple's OpenSSL (currently 0.9.8zg) supports SHA2 despite its deprecated status. You can't link against it in El Capitan any more since they stopped shipping the development headers, but getting an OpenSSL that doesn't support SHA2 is actually somewhat challenging (You'd either need an OpenSSL compiled with OPENSSL_NO_SHA or OPENSSL_NO_SHA256 or one that predates 0.9.7h). None of that excuses Apple not checking this of course. Security.framework can do all this validation -- did they not historically provide code samples on how to do this without linking an external library?
        mikeash 11y ago
        Sorry, I didn't mean to imply that their ancient OpenSSL doesn't do SHA-2, although I had no idea either way. They just say you can't use it because it's deprecated, and therefore off limits to App Store apps. Historically, I believe the code samples were more or like the ones in the link I posted. I don't believe they ever posted anything that showed how to use Security.framework for the heavy lifting. I think they wanted to get everybody to bring their own code to make it so you couldn't pirate every app with a patch to one shared library.
  - hockeybias 11y ago
    Apple? blunder? Perish the thought and worship on!
  - blinkingled 11y ago
    You'd be right if the developers were distributing their apps on their own - once Apple has put up a service in the form of the App Store and are taking a 30% cut out of every sale, it's their responsibility to keep it running. If that means detecting that many apps use incompatible OpenSSL and communicating with the developers to address that issue before rolling out SHA-2 cert, so be it - all competent services companies do things like these all the time. It's not as if there wasn't a way for Apple to detect this (if there wasn't then again it's their own fault) and it wasn't as if they couldn't have renewed with another SHA-1 cert for a few months until they figured out how to roll out SHA-2 one without causing a lot of people a lot of trouble.
    - tinalumfoil 11y ago
      > It's not as if there wasn't a way for Apple to detect this Assuming developers were statically linking the old OpenSSH versions, how would Apple detect this? Are developers forced to reveal source code before submitting to Apple? Does OSX executables have some format to specify what libraries it's using? I don't develop for OSX so I'm genuinely curious.
      - JoachimSchipper 11y ago
        Apple is able to scan iOS code for e.g. use of nonpublic API's; certainly they can grep a binary for a recognizable chunk of OpenSSL code, too. (Neither the iOS scans nor the OpenSSL scan will catch everything, of course.)
        joosters 11y ago
        A recognizable chunk of OpenSSL code? It could be any statically linked and custom-compiled version, that's millions of possible versions, once you take into account compile options, optimisation levels and linking techniques. Good luck grepping for it! Even if the version number is in there somewhere, there's probably all kinds of false positives that you would hit. Plus, it could be due to other SSL libraries, not just OpenSSL. In short, there's no realistic way to do what you are asking.
- deleted 11y ago
  [deleted]
dlitz 11y ago
I wish we could find a way to fix this "old SSL library/configuration" category of bugs across the board. Neither OS distributors, nor app makers, nor sysadmins seem to be uniformly good at (or interested in) staying on top of this, and it means users get unreliable security.

by dak1 11y ago

lambada 11y ago

This needs to be upvoted, and the title changed. Turns out it was due to developers using incredibly old security code. Rather than an expired certificate.

whatever_dude 11y ago
Yup, this changes my own point of view from "Gee Apple what a blunder" to "Some developers can be really dumb".
- mikeash 11y ago
  Apple built a lame DRM system, tossed out some half-baked sample code, and then told third parties "OK, you guys go implement this yourselves" without even so much as providing a library to help with the hard parts. Then they made a pretty substantial change without even checking to see if all of these one-off third-party implementations could deal with it.
  - lambada 11y ago
    Given that OpenSSL has supported SHA-2 since 2005, and the Mac App Store was announced in 2010, then released in 2011, I'm really not sure you can blame Apple for thinking it'd be reasonable to expect App Developers to not be using 5 year old versions of dependencies.
    - mikeash 11y ago
      Why not? When you're running a service like this, thinking instead of checking is not a wise move. How much time would it have taken to whip up a script that just tests all of the apps in the store? Even if it's a week of an engineer's time, that seems worthwhile. Testing whether the apps in the store actually run when presented with a valid receipt should already be automated anyway. I'm looking through Apple's guidance here: https://developer.apple.com/library/mac/releasenotes/General/ValidateAppStoreReceipt/Chapters/ValidateLocally.html https://developer.apple.com/library/mac/releasenotes/General... The only thing they say about which version of OpenSSL to use is that you need to bring your own and not rely on the one that ships with the OS, because Apple is still shipping a version of OpenSSL from 2005. They do not say anything about which version of OpenSSL you need to use or what capabilities it needs to have. I bet a lot of people were using Apple's OpenSSL for this originally, and when it was deprecated the path of least resistance would have been to bundle the same version Apple ships.
      - reaperhulk 11y ago
        To be clear Apple's OpenSSL (currently 0.9.8zg) supports SHA2 despite its deprecated status. You can't link against it in El Capitan any more since they stopped shipping the development headers, but getting an OpenSSL that doesn't support SHA2 is actually somewhat challenging (You'd either need an OpenSSL compiled with OPENSSL_NO_SHA or OPENSSL_NO_SHA256 or one that predates 0.9.7h). None of that excuses Apple not checking this of course. Security.framework can do all this validation -- did they not historically provide code samples on how to do this without linking an external library?
        mikeash 11y ago
        Sorry, I didn't mean to imply that their ancient OpenSSL doesn't do SHA-2, although I had no idea either way. They just say you can't use it because it's deprecated, and therefore off limits to App Store apps. Historically, I believe the code samples were more or like the ones in the link I posted. I don't believe they ever posted anything that showed how to use Security.framework for the heavy lifting. I think they wanted to get everybody to bring their own code to make it so you couldn't pirate every app with a patch to one shared library.
- hockeybias 11y ago
  Apple? blunder? Perish the thought and worship on!
- blinkingled 11y ago
  You'd be right if the developers were distributing their apps on their own - once Apple has put up a service in the form of the App Store and are taking a 30% cut out of every sale, it's their responsibility to keep it running. If that means detecting that many apps use incompatible OpenSSL and communicating with the developers to address that issue before rolling out SHA-2 cert, so be it - all competent services companies do things like these all the time. It's not as if there wasn't a way for Apple to detect this (if there wasn't then again it's their own fault) and it wasn't as if they couldn't have renewed with another SHA-1 cert for a few months until they figured out how to roll out SHA-2 one without causing a lot of people a lot of trouble.
  - tinalumfoil 11y ago
    > It's not as if there wasn't a way for Apple to detect this Assuming developers were statically linking the old OpenSSH versions, how would Apple detect this? Are developers forced to reveal source code before submitting to Apple? Does OSX executables have some format to specify what libraries it's using? I don't develop for OSX so I'm genuinely curious.
    - JoachimSchipper 11y ago
      Apple is able to scan iOS code for e.g. use of nonpublic API's; certainly they can grep a binary for a recognizable chunk of OpenSSL code, too. (Neither the iOS scans nor the OpenSSL scan will catch everything, of course.)
      - joosters 11y ago
        A recognizable chunk of OpenSSL code? It could be any statically linked and custom-compiled version, that's millions of possible versions, once you take into account compile options, optimisation levels and linking techniques. Good luck grepping for it! Even if the version number is in there somewhere, there's probably all kinds of false positives that you would hit. Plus, it could be due to other SSL libraries, not just OpenSSL. In short, there's no realistic way to do what you are asking.
deleted 11y ago
[deleted]

dlitz 11y ago

I wish we could find a way to fix this "old SSL library/configuration" category of bugs across the board. Neither OS distributors, nor app makers, nor sysadmins seem to be uniformly good at (or interested in) staying on top of this, and it means users get unreliable security.