July 23, 2014

Plethora of security updates in iOS 6

(LiveHacking.Com) - Yesterday Apple launched the latest version of its mobile operating system for the iPhone, iPad and iPod Touch. iOS 6 brings new features like Facebook integration and is the default OS for the new iPhone 5 which starts shipping on Friday. The new OS also includes lots of important security fixes.

Included in the fixes is an update to WebKit, the open source HTML rendering engine which Apple created and is also used in Google Chrome. Apple updated iTunes recently with a very similar set of WebKit fixes as those found in iOS 6. Apple describes the WebKit vulnerabilities by saying that “Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution.” Which it explains is due to “multiple memory corruption issues existed in WebKit. These issues are addressed through improved memory handling.”

Other WebKit fixes also include several cross-site scripting fixes and better URL handling. According to Apple the Unicode fonts embedded in Safari could can been used to create a URL which contains look-alike characters. These look-alike characters can be used by a malicious website to direct the user to a spoofed site that visually appears to be a legitimate domain.

Apple also spent some time fixing issues with passcode which can be set from within iOS to stop unwanted access to the device. This included a design flaw in the support for viewing photos that were taken while the screen was locked. Previously to determine which photos should be displayed the passcode lock checked the time at which the device was locked and compared it to the time that a photo was taken. However, by spoofing the current time an attacker could gain access to photos that were taken before the device was locked. To fix this, iOS now explicitly keeps track of the photos that were taken while the device was locked.

Other fixes are:

  • CFNetwork – An issue existed in CFNetwork’s handling of malformed URLs. CFNetwork may send requests to an incorrect hostname, resulting in the disclosure of sensitive information. This issue was addressed through improvements to URL handling.
  • CoreGraphics – Multiple vulnerabilities existed in FreeType, the most serious of which may lead to arbitrary code execution when processing a maliciously crafted font. These issues were addressed by updating FreeType to version 2.4.9. Further information is available via the FreeType site at http://www.freetype.org/
  • CoreMedia – An uninitialized memory access existed in the handling of Sorenson encoded movie files. This issue was addressed through improved memory initialization.
  • DHCP – Upon connecting to a Wi-Fi network, iOS may broadcast MAC addresses of previously accessed networks per the DNAv4 protocol. This issue was addressed by disabling DNAv4 on unencrypted Wi-Fi networks.
  • ImageIO – A buffer overflow existed in libtiff’s handling of ThunderScan encoded TIFF images. This issue was addressed by updating libtiff to version 3.9.5.
  • ImageIO – Multiple memory corruption issues existed in libpng’s handling of PNG images. These issues were addressed through improved validation of PNG images.
  • ImageIO – A double free issue existed in ImageIO’s handling of JPEG images. This issue was addressed through improved memory management.
  • ImageIO – An integer overflow issue existed in libTIFF’s handling of TIFF images. This issue was addressed through improved validation of TIFF images.
  • International Components for Unicode – A stack buffer overflow existed in the handling of ICU locale IDs. This issue was addressed through improved bounds checking.
  • IPSec – A buffer overflow existed in the handling of racoon configuration files. This issue was addressed through improved bounds checking.
  • Kernel – An invalid pointer dereference issue existed in the kernel’s handling of packet filter ioctls. This may allow an attacker to alter kernel memory. This issue was addressed through improved error handling.
  • Kernel – An uninitialized memory access issue existed in the Berkeley Packet Filter interpreter, which led to the disclosure of memory content. This issue was addressed through improved memory initialization.
  • libxml – Multiple vulnerabilities existed in libxml, the most serious of which may lead to an unexpected application termination or arbitrary code execution. These issues were addressed by applying the relevant upstream patches.
  • Mail – A logic issue existed in Mail’s handling of attachments. If a subsequent mail attachment used the same Content-ID as a previous one, the previous attachment would be displayed, even in the case where the 2 mails originated from different senders. This could facilitate some spoofing or phishing attacks. This issue was addressed through improved handling of attachments.
  • Mail – A logic issue existed in Mail’s use of Data Protection on email attachments. This issue was addressed by properly setting the Data Protection class for email attachments.
  • Mail – S/MIME signed messages displayed the untrusted ‘From’ address, instead of the name associated with the message signer’s identity. This issue was addressed by displaying the address associated with the message signer’s identity when it is available.
  • Messages – When a user had multiple email addresses associated with iMessage, replying to a message may have resulted in the reply being sent from a different email address. This may disclose another email address associated to the user’s account. This issue was addressed by always replying from the email address the original message was sent to.
  • Office – Viewer An information disclosure issue existed in the support for viewing Microsoft Office files. When viewing a document, the Office Viewer would write a temporary file containing data from the viewed document to the temporary directory of the invoking process. For an application that uses data protection or other encryption to protect the user’s files, this could lead to information disclosure. This issue was addressed by avoiding creation of temporary files when viewing Office documents.
  • OpenGL – Multiple memory corruption issues existed in the handling of GLSL compilation. These issues were addressed through improved validation of GLSL shaders.
  • Passcode Lock – A logic issue existed with the display of the “Slide to Power Off” slider on the lock screen. This issue was addressed through improved lock state management.
  • Passcode Lock – A logic issue existed in the termination of FaceTime calls from the lock screen. This issue was addressed through improved lock state management.
  • Passcode Lock – A design issue existed in the support for viewing photos that were taken at the lock screen. In order to determine which photos to permit access to, the passcode lock consulted the time at which the device was locked and compared it to the time that a photo was taken. By spoofing the current time, an attacker could gain access to photos that were taken before the device was locked. This issues was addressed by explicitly keeping track of the photos that were taken while the device was locked.
  • Passcode Lock – A logic issue existed in the Emergency Dialer screen, which permitted FaceTime calls via Voice Dialing on the locked device. This could also disclose the user’s contacts via contact suggestions. This issue was addressed by disabling Voice Dialing on the Emergency Dialer screen.
  • Passcode Lock Using the camera from the screen lock could in some cases interfere with automatic lock functionality, allowing a person with physical access to the device to bypass the Passcode Lock screen. This issue was addressed through improved lock state management.
  • Passcode Lock – A state management issue existed in the handling of the screen lock. This issue was addressed through improved lock state management.
  • Restrictions – After disabling Restrictions, iOS may not ask for the user’s password during a transaction. This issue was addressed by additional enforcement of purchase authorization.
  • Safari – Websites could use a Unicode character to create a lock icon in the page title. This icon was similar in appearance to the icon used to indicate a secure connection, and could have lead the user to believe a secure connection had been established. This issue was addressed by removing these characters from page titles.
  • Safari – Password input elements with the autocomplete attribute set to “off” were being autocompleted. This issue was addressed through improved handling of the autocomplete attribute.
  • System Logs – Sandboxed apps had read access to /var/log directory, which may allow them to obtain sensitive information contained in system logs. This issue was addressed by denying sandboxed apps access to the /var/log directory.
  • Telephony – Messages displayed the return address of an SMS message as the sender. Return addresses may be spoofed. This issue was addressed by always displaying the originating address instead of the return address.
  • Telephony – An off-by-one buffer overflow existed in the handling of SMS user data headers. This issue was addressed through improved bounds checking.
  • UIKit – Applications that use UIWebView may leave unencrypted files on the file system even when a passcode is enabled. This issue was addressed through improved use of data protection.
  • WebKit – A cross-origin issue existed in the handling of CSS property values. This issue was addressed through improved origin tracking.
  • WebKit – A cross-origin issue existed in the handling of iframes in popup windows. This issue was addressed through improved origin tracking.
  • WebKit – A cross-origin issue existed in the handling of iframes and fragment identifiers. This issue was addressed through improved origin tracking.
  • WebKit – The International Domain Name (IDN) support and Unicode fonts embedded in Safari could have been used to create a URL which contains look-alike characters. These could have been used in a malicious website to direct the user to a spoofed site that visually appears to be a legitimate domain. This issue was addressed by supplementing WebKit’s list of known look-alike characters. Look- alike characters are rendered in Punycode in the address bar.
  • WebKit – A canonicalization issue existed in the handling of URLs. This may have led to cross-site scripting on sites which use the location.href property. This issue was addressed through improved canonicalization of URLs.
  • WebKit – An HTTP header injection issue existed in the handling of WebSockets. This issue was addressed through improved WebSockets URI sanitization.
  • WebKit – A state management issue existed in the handling of session history. Navigations to a fragment on the current page may cause Safari to display incorrect information in the URL bar. This issue was addressed through improved session state tracking.
  • WebKit – An uninitialized memory access issue existed in the handling of SVG images. This issue was addressed through improved memory initialization.

Will Apple fix SMS spoofing flaw before iOS 6 is released?

(LiveHacking.Com) – As demonstrated many times, social engineering is a key method used by hackers to solicit personal information from victims and now, due to a new SMS spoofing flaw which has been discovered on the iPhone, users need to be extra careful about trusting text messages they receive on their phones.

Security researcher “pod2g” has found a serious flaw in the way iOS processes SMS messages that leaves iPhone users open to spoofing.

This means that an attacker can spoof messages from a victim’s bank asking them for some private information, or linking to phishing website and, because of the flaw, the message look genuine. Also false messages can be sent to a device and used as false evidence. In fact, pod2g writes that the spoofing can be use to do “anything you can imagine that could be utilized to manipulate people, letting them trust somebody or some organization [that] texted them.”

This flaw has existed since 2007, when the first iPhone was released, and still hasn’t been addressed with iOS 6  beta 4.

SMS messages are converted to complex PDU (Protocol Description Unit) packets  for delivery. As part of the payload, a section called UDH (User Data Header) allows the sender to add a reply-to number. If included, any replies written by the receiver will be sent to that number rather than the original number.

The problem with the iPhone SMS app is that the reply-to address is displayed rather than the genuine originator number. This means a message can be sent from one device and made to look like it came from another. What should happen is that if the reply-to and originator numbers are different both should be shown or a warning displayed.

Tools exist for smartphones and even online for sending raw PDU messages meaning that these fake messages are relatively easy to generate.

“Apple takes security very seriously,” representatives from the Cupertino, Calif.-based company told The Verge on Saturday. “When using iMessage instead of SMS, addresses are verified which protects against these kinds of spoofing attacks.”

“Now you are alerted. Never trust any SMS you received on your iPhone at first sight,” wrote pod2g.

The question now remains, will Apple fix this before iOS 6 is released?

iOS 6 apps need user permission to access personal data

(LiveHacking.Com) – The incredible growth of Internet enabled smartphones and tablets means that malware authors have targeted these devices in their attempts to make illegally gained income. One of the most valuable types of information on a smartphone is the personal information like contacts, calendars, reminders and photos. Android and iOS have both had their shares of privay scandals including the Carrier IQ snopping incident and Apple’s locationgate problems.

According to a MacRumors report, new clauses have been added to the ‘Data Privacy’ section in Apple’s iOS 6 Release Notes:

In addition to location data, the system now asks the user’s permission before allowing third-party apps to access certain user data, including:

- Contacts
- Calendars
- Reminders
- Photo Library

For contact, calendar, and reminder data, your app needs to be prepared to be denied access to these items and to adjust its behavior accordingly. If the user has not yet been prompted to allow access, the returned structure is valid but contains no records. If the user has denied access, the app receives a NULL value or no data. If the user grants permission to the app, the system subsequently notifies the app that it needs to reload or revert the data.

Previously, an app only needed to get permission when it wanted to access the GPS data but with iOS 6, explicit permission is now requested when the media gallery is accessed because of the location meta-data stored in the photos.

iOS 6 is currently a developer preview and is expected to be released  in the last quarter of this year.