Posted by David Harley on March 18, 2015.
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.
More on the iOS front: Prateek Gianchandani offers analysis of memory handling in apps: iOS 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.
Small Blue-Green World