ITsecurity
twitter facebook rss

Android exfiltration, OpenSSL, and iOS app memory handling

Posted by on March 18, 2015.

[Update: details of the OpenSSL advisory released after this blog here. Note that the FREAK-related CVE-2015-0204 flagged by Intego here is reclassified as ‘severe’ and upgrades are advised:

This was classified low because it was originally thought that server RSA
export ciphersuite support was rare: a client was only vulnerable to a MITM
attack against a server which supports an RSA export ciphersuite. Recent
studies have shown that RSA export ciphersuites support is far more common.

This issue affects OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.1 users should upgrade to 1.0.1k.
OpenSSL 1.0.0 users should upgrade to 1.0.0p.
OpenSSL 0.9.8 users should upgrade to 0.9.8zd.

This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan
Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen
Henson of the OpenSSL core team. It was previously announced in the OpenSSL
security advisory on 8th January 2015.]

I’ll try not to rant on yet again Google’s squirming on security issues – especially in the context of malware – but it’s not been an altogether happy few weeks in Android security. According to Fox a 9-year-old boy was able to demonstrate how to steal contacts, call logs and messages within just 15 minutes at the Security B-sides conference. I wasn’t there and certainly can’t say how convincing the demonstration was, but it clearly attracted attention.

Meanwhile, FireEye claimed that

1228 (11.2%) [Android apps] are vulnerable to a FREAK attack because they use a vulnerable OpenSSL library to connect to vulnerable HTTPS servers.

Not that Apple fared much better on this occasion – according to FireEye:

On the iOS side, 771 out of 14,079 (5.5%) popular iOS apps connect to vulnerable HTTPS servers.

I don’t know if this has any bearing on the forthcoming OpenSSL updates, for which the ‘highest severity defect fixed by these releases is classified as “high” severity.’  Or indeed on Google’s announcement that it will augment its automatic checking of apps submitted to Google Play with a manual review process, but that’s welcome news anyway, in the opinion of many.

Commentary by Graham Cluley on the FireEye article here, and on Google Play’s announcement here.

More on the iOS front: Prateek Gianchandani offers analysis of memory handling in appsiOS Application Security Part 39 – Sensitive information in memory

He states that:

iOS applications may store sensitive information like passwords, session IDs etc in the memory of the application without releasing them. In some cases, releasing these variables may not be an option.

I’ve had material published by Infosec Institute in the past and been unhappy with both the publishing process and some of the correspondence that followed publication, but there is some interesting analysis and speculation here. A pity it wasn’t better proofed and edited. He does refer to the first article in an interesting series by Mark Beard: iOS Tutorial – Dumping the Application Heap from Memory and iOS Tutorial – Dumping the Application Memory Part 2.

David Harley
Small Blue-Green World


Share This:
Facebooktwittergoogle_plusredditpinterestlinkedinmail

Leave a Reply

Your email address will not be published. Required fields are marked *

Submitted in: David Harley | Tags: , , ,