2013-04-03
Abstract
‘It concerns me that my daughter’s favourite game requires access to Wi‑Fi, contacts, the operating system, etc.’ Aleksander Czarnowski, AVET.
Copyright © 2013 Virus Bulletin
Recent in-the-wild exploitation of the CVE-2013-0422 and CVE-2012-3174 Java vulnerabilities (which together I will refer to as the MBeanInstantiator.findClass vulnerability) has led me to some interesting thoughts about security, especially in the era of BYOD.
Even though the use of Java inside web browsers is dying out (at least it should be), the number of potential targets is still large enough for malware writers to search for vulnerabilities and put them into commercial malware packages. With the ever increasing number of devices that can run a web browser (and run Java), it is likely that if even less than 1% of them are vulnerable, it is worth the bad guys investing in vulnerability research.
When introducing important changes or new features to software, it is important always to remember to double‑check your code. The root of the MBeanInstantiator.findClass vulnerability is a change in reflection API as a result of the introduction of new functionality. The ability of the exploit to bypass policies and security checks enforced by Java SecurityManager comes from the fact that not all security-related code has been upgraded to the new API correctly – in a world where the complexity of software is increasing constantly, and new releases have to be pushed out ever more quickly, security often falls by the wayside.
How many host-based IDS systems trace and can block the Java call ‘System.setSecurityManager(null)’ – which removes all Java security from the process? How many of those can stop the latest exploit without a signature update?
Whether you love or hate Java, the fact is that the number of programs that run in some kind of virtual machine on our devices is rising. As computing power and memory resources increase, this trend will become ever more prevalent. Most of these technologies (including .NET, for example) provide some form of reflection-like API and allow access to complex internal runtime structures that reach a lot further than just a bytecode representation. Things like security managers and reflection APIs are hard to get right from a security perspective. When designing such a solution you have to take into account many different situations, a lot of which are hard to imagine without proper education and relevant experience.
What does BYOD have to do with any of this? We are now in the habit of converting all our programs to mobile applications, which in many cases means converting to HTML5 and running a tablet web browser disguised as a dedicated application. HTML5 might be immune to some of the problems that plagued previous web technologies, but users tend to change their behaviour over the years, and we should take the time to learn from the past.
It concerns me greatly that my young daughter’s favourite tablet game requires access to Wi‑Fi, contacts, the operating system, etc. I wonder how many hours the game’s developer dedicated to pen testing this game. Probably none. These apps are not written in assembly language but in high‑level frameworks which have complex APIs like Java reflection. If I were a bad guy, I would target a high‑profile game that runs with extremely high privileges (check out your app store, most of them do). Now imagine that all the employees at your workplace bring in the devices their children have been playing on – complete with malware kits already installed.
This is just the tip of the iceberg. Users are always keen to install the latest apps on their devices, so the constant patch/update cycle is alive and kicking. However, the problem comes when the time frame for fixing a high‑profile vulnerability is big enough for the bad guys to make a buck on it: in some cases even a couple of hours can be long enough. Now I’m off to delete pictures from my wife’s phone since they are taking up too much space for the latest 1.6GB system update.
