| WIKI | FAQ | Tech FAQ | |
 http://csua.com/feed/ | |
| ||||||
| 5/24 |
| 2011/11/9-30 [Computer/SW/Security, Computer/SW/OS/OsX] UID:54219 Activity:nil |
11/9 Unsigned code execution exploit in iOS 4.3 & 5:
http://preview.tinyurl.com/bslubtu [arstechnica]
\_ Fixed in iOS 5.0.1:
http://preview.tinyurl.com/7l4vq52 [macobserver] |
| 5/24 |
|
| preview.tinyurl.com/bslubtu -> arstechnica.com/apple/news/2011/11/safari-charlie-discovers-security-flaw-in-ios-gets-booted-from-dev-program.ars?utm_source=rss&utm_medium=rss&utm_campaign=rss MobileSafari, has discovered yet another serious security flaw in Apple's iOS mobile operating system. The bug could potentially let any app download and run unsigned code, though it appears that Apple has a fix in the works. In the meantime, however, Miller's proof-of-concept app--originally approved by Apple and available until late Monday--has earned the researcher a one year suspension from Apple's developer program. According to the report, Miller plans to reveal the issue in a presentation at the SysCan security conference in Taiwan next week. As part of his presentation, Miller created an app capable of exploiting the flaw, and uploaded it to the App Store. use of a special memory area, which allows his app to run unsigned code. Ars spoke to Miller to understand the bug and its implications. In particular, he noted that this should make iOS users wary of apps from unknown or untrusted developers. "Until the flaw is fixed, you can't really trust what's coming from the App Store," Miller told Ars. Crack in the sandbox foundation iOS is designed to only run code that is digitally signed by the developer. Developers are given special security certificates from Apple when they join the App Developer Program, and when developers have an app ready to submit to the App Store, they use these certificates to digitally "sign" the code, confirming it comes from a trusted source. Apple then puts apps through a vetting process, which attempts to confirm that apps don't use nonstandard APIs or attempt to use user data in an unscrupulous way. When you download an app from the App Store, then, you should be confident that the app is safe. But in iOS 43, Apple introduced a mechanism to allow exceptions to this hard and fast "signed code only" rule. Safari on Mac OS X, Nitro works by first analyzing JavaScript code for a webpage, and then compiling it "just in time" into optimized native code. "This code hasn't been signed, so there has to be a mechanism to relax those restrictions," Miller said. Normally, iOS's kernel won't let apps allocate memory that is writeable and executable. Either memory is allocated as writeable--able to store data--or it's executable--able to store signed instruction code. excellent explanation of sandboxing entitlements as they are used in Lion). "MobileSafari is allowed to have a single special region of memory to write JIT code to memory and allow it to execute," Miller explained. Miller said that even this entitlement is well-protected. If MobileSafari were hacked, it couldn't create an additional executable area of memory, and it couldn't affect other apps outside of its sandbox. The problem that Miller discovered is actually a flaw in the part of iOS that checks to make sure that only MobileSafari has the special ability to create an area of memory that is both writeable and executable. "That allowed my app to create its own special area of memory to download and run unsigned code." But by September, he had fully exploited the flaw and was able to get a proof-of-concept app, which took advantage of it, into the App Store. According to Miller, that app was downloaded by quite a few people before Apple pulled the app on Monday, though he said only his copy is configured to download code from his server. Part of the reason he waited to publicize the issue is that he wanted to see if Apple had fixed it in iOS 5 According to Miller, it did not. Patch in the works Miller alerted Apple about the weakness three weeks ago. The company acknowledged it and asked how Miller should be credited in a security bulletin that accompanies most iOS release notes. "I'm sure it is something they will fix quickly," Miller noted, suggesting the fix would likely appear before his presentation in Taiwan. I'm sure they are also working on code fixes for the battery draining issue and stuff that they are going to release patch for." One thing Miller did not tell Apple, however, is that he had an app in the App Store that took advantage of the flaw. A few hours after the news broke, Miller received an e-mail from Apple noting that his developer program access had been revoked for a period of one year for violating its terms of service. He called the move "heavy handed," noting that Apple gave security researchers free access to the dev program for the purposes of discovering flaws. "For the record, without a real app in the App Store, people would say that Apple wouldn't approve an app that took advantage of this flaw," he wrote on Twitter. While publicizing the flaw means that other hackers might be able to exploit the same bug, Miller told Ars that it's "pretty easy to check for my little trick," so it's likely that the App Store review team will be looking for strange memory allocations. And, Miller said, "at least now people will know to be more careful until Apple is able to patch." |
| preview.tinyurl.com/7l4vq52 -> www.macobserver.com/tmo/article/ios_5.0.1_fixes_charlie_millers_code_signing_security_flaw/?utm_source=macobserver&utm_medium=rss&utm_campaign=rss_everything One of those fixes is for a flaw attributed to Charlie Miller, the security researcher Apple recently banned from the company's developer program. Mr Miller drew Apple's ire when he submitted an app to Apple's iOS App Store as part of his proof of concept testing for a security flaw he had discovered. That app was approved by Apple, but then Mr Miller was able to download unsigned code from his own server and then execute that code on his iPhone. He did all this without Apple's knowledge, and the company kicked him out of its developer program, despite the fact that the researcher is responsible for finding (and reporting to Apple) many security flaws in Apple's software over the years. In any event, that same flaw appears to be one of the ones fixed in this update. Apple's security patch notes include this entry: * Kernel Available for: iOS 30 through 50 for iPhone 3GS, iPhone 4 and iPhone 4S, iOS 31 through 50 for iPod touch (3rd generation) and later, iOS 32 through 50 for iPad, iOS 43 through 50 for iPad 2 Impact: An application may execute unsigned code Description: A logic error existed in the mmap system call's checking of valid flag combinations. This issue does not affect devices running iOS prior to version 43 CVE-ID CVE-2011-3442 : Charlie Miller of Accuvant Labs Other security fixes in this update include: * CFNetwork Available for: iOS 30 through 50 for iPhone 3GS, iPhone 4 and iPhone 4S, iOS 31 through 50 for iPod touch (3rd generation) and later, iOS 32 through 50 for iPad, iOS 43 through 50 for iPad 2 Impact: Visiting a maliciously crafted website may lead to the disclosure of sensitive information Description: An issue existed in CFNetwork's handling of maliciously crafted URLs. When accessing a maliciously crafted HTTP or HTTPS URL, CFNetwork could navigate to an incorrect server. CVE-ID CVE-2011-3246 : Erling Ellingsen of Facebook * CoreGraphics Available for: iOS 30 through 50 for iPhone 3GS, iPhone 4 and iPhone 4S, iOS 31 through 50 for iPod touch (3rd generation) and later, iOS 32 through 50 for iPad, iOS 43 through 50 for iPad 2 Impact: Viewing a document containing a maliciously crafted font may lead to arbitrary code execution Description: Multiple memory corruption issues existed in FreeType, the most serious of which may lead to arbitrary code execution when processing a maliciously crafted font. CVE-ID CVE-2011-3439 : Apple * Data Security Available for: iOS 30 through 50 for iPhone 3GS, iPhone 4 and iPhone 4S, iOS 31 through 50 for iPod touch (3rd generation) and later, iOS 32 through 50 for iPad, iOS 43 through 50 for iPad 2 Impact: An attacker with a privileged network position may intercept user credentials or other sensitive information Description: Two certificate authorities in the list of trusted root certificates have independently issued intermediate certificates to DigiCert Malaysia. DigiCert Malaysia has issued certificates with weak keys that it is unable to revoke. An attacker with a privileged network position could intercept user credentials or other sensitive information intended for a site with a certificate issued by DigiCert Malaysia. This issue is addressed by configuring default system trust settings so that DigiCert Malaysia's certificates are not trusted. We would like to acknowledge Bruce Morton of Entrust, Inc. When resolving a maliciously crafted hostname, libinfo could return an incorrect result. CVE-ID CVE-2011-3441 : Erling Ellingsen of Facebook, Per Johansson of Blocket AB * Passcode Lock Available for: iOS 43 through 50 for iPad 2 Impact: A person with physical access to a locked iPad 2 may be able to access some of the user's data Description: When a Smart Cover is opened while iPad 2 is confirming power off in the locked state, the iPad does not request a passcode. This allows some access to the iPad, but data protected by Data Protection is inaccessible and apps cannot be launched. November 10th, 2011 at 3:20 PM: The over-the-air update worked really well. If you want to poke your iOS device to get the update, go to Settings->General->Software Update. I don't know how the timing works out, but if Apple had this fix in the pipeline before Charlie Miller's stunt, that would indicate his "demonstration" had no effect on the priorities; Understanding The Debate Over Apple's Mac App Store Sandbox - 8 Comments TMO Express Join the TMO Express Daily Newsletter to get the latest Mac headlines in your e-mail every weekday. All information presented on this site is copyrighted by The Mac Observer, Inc. No portion of this site may be copied without express written consent. Other sites are invited to link to any aspect of this site provided that all content is presented in its original form and is not placed within another frame. The Mac Observer is an independent publication and has not been authorized, sponsored, or otherwise approved by Apple, Inc. Support The Mac Observer We noticed you may be running AdBlock on your computer. It takes real money to run this site and to deliver the news, tips, and opinions you love to read. If you wish to block the ads that pay for the creation of our content, we ask that you instead support TMO Directly, either with a $5 monthly recurring contribution, or a one-time donation of any amount of your choice. |