On Mon, Dec 24, 2012 at 5:49 AM, Dan Kaminsky <[email protected]> wrote: > Remarkably tricky to do well, though. Do it like Apple: perform your updates over HTTP. Make it a feature so an organization trying to manage an non-organizational MacBook can provide DNS and the Update Service. And don't sign the catalogs (TAR balls fetched before the signed update). No problems ;)
What I can't understand: when it was applied against in-App purchases (StoreKit), Apple cried foul. http://z6mag.com/technology/apple/free-apps-for-ipad-iphone-security-flaw-in-ios-goes-unfixed-by-apple-1612248.html It would be funny if it wasn't true: "Apple has now added a 'unique identifier' field to receipts, and given developers tools so they could verify digital receipts on their own server. However, this only works if the developer runs the receipt through their server first. Apps that connect directly to the Apple App Store server are still vulnerable to the hack." Instead of taking advantage of the pre-exisiting relationship between the StoreKit API and Apple Servers by pinning the certificate (similar to SSH's StrictHostKeyCheck), Apple pushed it on developers. Amazing. Jeff > On Sun, Dec 23, 2012 at 4:19 PM, Jeffrey Walton <[email protected]> wrote: >> >> Came across this recently: "Autoupdaters are the best security tool >> since Diffie-Hellman" >> (http://www.slideshare.net/jserv/brief-tour-about-android-security). I >> could not agree more, and I will be lifting that quote. _______________________________________________ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list.
