Wednesday, December 10, 2008

Java Inner Classes and SOLID

I was dealing with some legacy code at work and came across some Java inner classes. Looking at those inner classes I realised that they had a bad feel to them; they break some of the SOLID principles.

The main problem lies with non-static inner classes. In the case of a static inner class why not just move the code out into a separate file? Some people argue that inner classes help to keep related things close together but it seems to go against the spirit of the SOLID principles. And other things aside, they completely break encapsulation.

Single Responsibility Principle

The single responsibility principle is about keeping things simple and manageable. However, inner classes add a highly (sometimes very highly) coupled added responsibility to a class. By adding the inner class complexity increases and testing is harder. In the case of a static inner class the two classes may be testable independently. However non-static inner classes can't be tested as an individual unit.

Dependency Inversion Principle

Again non-static inner classes break this principle: they are tightly coupled and depend on each other's implementation. As I mentioned above this makes testing the two classes in isolation impossible.

Open/Close, Liskov Substitution and Interface Segregation Principles

These principles relate more to the implementation specifics of classes. While the relationship between an inner class an its enclosing class doesn't explicitly break the principles, it must make it harder to write an outer class that complies with the principles.

Anonymous Inner Classes

In most cases anonymous inner classes fall into a slightly different category. Especially in Swing, anonymous inner classes are an important feature required to create clean UI code. However they are very much the exception to the norm. These sorts of small event handling classes are really just a poor substitute for language level events and delegates (such as those in the .net framework).

Summary

The more I consider Java inner classes the more I am inclined to avoid them. Looking at them in terms of the SOLID principles helps to outline why they can seem to complicate a class and related class design.

Sunday, December 7, 2008

OSX and the Malware Economy

One thing that annoys me is when people make silly statements about IT security. After the recent activity on the Apple forums regarding Mac anti-virus software, I found some people referencing this old article claiming Mac users are safe from malware. The main part of the article that stands out to me is this quote:

As Windows users continue to run their adware, spyware, and virus removal programs, Macintosh enthusiasts have enjoyed - literally - zero viruses. Adware and spyware are nonexistant as Mac users surf the Web without issue. OS X's UNIX shell is a secure system that keeps your computer safe, and Apple has built in a firewall for added security.

The first statement is certainly accurate, while there is an enormous amount of malware around for Windows systems there is very little around for Macs (although not zero). The second and third sentences are the sort of broad statements that are risky to make.

If you follow Robert Hensing's blog like I do, you'll be aware that security in OS X is not as good as some Mac users make it out to be. The links below are obviously slightly biased since Robert works for Microsoft however I feel he gives a fairly balanced point of view. Here are some examples:

So if all that stuff is true why is there only a handful of malware out there for OS X?

Platforms, platforms, platforms

So you want to start an cybercrime shop creating and distributing malware, what things do you need to consider?

The first thing to sort out is probably an attack vector. Typically this is a vulnerability in some software; favourites include the browser, browser plugins, network services (such as SMB on Windows) or by just tricking the end user into installing your software.

If you are using a software vulnerability such as a buffer overflow you will need to write some "shellcode" to get things started. The point of the shellcode is to provide a means to get the payload down onto the target system. It typically does this by opening a network connection to download the extra data. The tricky thing about shellcode is that it depends on the architecture of the system and probably also the operating system (e.g. if you need to open a socket to a remote host to get the payload).

Once you've executed your shellcode and downloaded your payload the possibilities open up. From here you can either write your payload to disk so you can restart once the computer or browser starts up again. Alternatively you can just hang around for the current session. Again the payload depends on the system architecture and the operating system. What the malware can do all depends on what privileges it scored when the shellcode executed. This is why IE 8 and Chrome both run with very limited privileges under Windows Vista and why Vista uses low privileges and UAC by default.

What this means is to put down a successful piece of malware you depend on a number of things: vulnerable software (or user error), operating system and architecture. And even then you may only exploit a low privilege user or process. A quick look at metasploit reveals something unsurprising: these are all solved problems for OS X - if you want to exploit an unpatched Mac, you can.

Its a numbers game

There are a few things that motivate malware writers but increasingly the trend seems to be financial motivation. Naturally malware is going to focus on the platform with the largest market share but other factors come into play which alter the concentration of malware.

Firstly, you need a reason to put malware onto a device. It sounds silly but there is literally no point developing malware for a device that won't be used to store or enter valuable information such as personal details, banking details, account details. The best example of this is the mobile non-smartphone market: Nokia sold 200 million of its Nokia 1100 model phones but its WAP 1.1 browser is not exactly the thing that most people do their Internet banking with.

The size of the PC market (and by PC I mean all PCs not just WinTel PCs) is quite large, some estimates from last year put it at the 1.3 billion mark, with Windows taking about 90% of that. As I mentioned above, a large user base is important but the Windows platform offers more that than -  it offers a standard platform. For example, a piece of malware that targets Windows NT will be able to run on Windows NT4, Windows 2000, Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008. It also has a fairly standard set of applications to attack: Office, Flash, Acrobat Reader, etc. Furthermore it has loads and loads of badly written third-party crapplets that all add to attack surface. Finally, you have heaps of people running Vista without UAC and Windows XP as the administrator. Microsoft can do all the threat modelling in the world and write the tightest code out there but if some Joe User clicks install when they visit a malware site all is lost. It all adds up to a malware bonanza.

While the Mac market share is growing it is still quite small in comparison (estimates currently range from 3% to 16%). OS X on desktop has only been around since 2001 and in 2006 the system architecture changed from PPC to Intel. These changes along with a less stable (and possibly less crappy) API makes it less attractive for exploit, shellcode and malware writers.

It seems to me like you need a sort of critical mass before security researchers and malware writers will start to put serious effort towards looking into a piece of software or platform. I also think that better security practices in recent times, such as workstation firewalls and automatic updates (OS X come with both by default), combined with a smaller market share make Macs a less viable malware target.

There's more than one way to skin a cat

So you've started up your cybercrime shop and decided initially to target the WinTel platform but now you're hungry for some extra cash. It turns out that there is more than one way to make money in the cybercrime economy and malware is only one of the options. Criminals are increasing using scams, phishing and spam to target end users and often this can be done in a platform independent way - Mac users are no exception.

A Mac user can visit a malicious site and be unaffected but a Windows user may be infected with malware. However if enough of a target develops the malware may evolve to target things differently.

A mobile focus

Mobile sales are increasing and the sales of mobile "smartphones" is increasing too. To me, the key difference between a mobile phone and a smartphone is that you are more likely to store personal information in the smartphone and also more likely to use it for banking and other sensitive transactions. And this is a point that has not gone unnoticed; the DC 09 Black Hat conference will be focusing on embedded devices among others.

Summary

The moral of this story (and evident by this post) is that it is easy to throw stones. OS X has certainly had its share of security issues and Windows certainly has a strong malware industry. The point I would like to make is that perhaps Apple hasn't needed to step up their software process to the next level but things can change quickly. I also think Microsoft has stepped up to the plate after their previous security woes and also that people wine about UAC too much (if it pops up lots I think you're doing something wrong ... ). Finally, cybercrime is something that is starting to affect everyone.

Friday, November 14, 2008

IKVM Benchmarking

I'm interested in what options are available for migrating a high performance Java application over to the .net runtime. IKVM is one obvious pathway so I decided to run some quick benchmarks to gauge how well it performs.

Method

I ran the DaCapo benchmark suite (2006-10-MR2) on my dual core PC and also a 16 core server. I allowed the execution time of the tests to converge (-converge) to help rule out startup costs and just used the default workload size. Since IVKM will have no heap restrictions I made the Java heap as large as possible. This turned out to be 1499Mb under the 32bit JVM and I limited the 64bit JVM to 2500Mb since I didn't want it to start page faulting on my box. As it turned out this was heaps [sic] of memory.

I took the fastest run time from the tests considering it as the "least disturbed" run. The graphs below are normalized to a percentage of the fastest runtime for each test so a smaller value is better. Several tests failed to run under IKVM which was a bit unfortunate - chart, eclipse and jython.

Results

Firstly lusearch is missing from the following results. This is because I'm quite interested in this benchmark in particular and it performed so badly that it warrants further investigation...

Dual Core Machine

I really should have the exact details of my machine but I don't have them handy. It is basically a dual core AMD 64 with 4Gb of RAM.

As you can see the results are quite mixed. Pmd and Xalan perform quite poorly, however looking at the threading information and the memory stats nothing really jumps out. Xalan is one of the multithreaded tests however so is hsqldb in which IKVM fairs quite well.

dual-core results

16 Core Machine

Again I don't have the exact details of this box but it is a quad-quad-core with 32Gb of RAM. The extra cores seem to exaggerate the dual core results further. Interestingly, on hsqldb (one of the multithreaded tests) IKVM 32 bit outperforms the Java 64 bit VM and the 32 bit client. The other strange result is on pmd in which the 32 bit Java client is the fastest to execute - I suspect this is a copy paste issue :-(

16-core

Summary

Some very mixed results and some questionable test results :) I guess some more work is needed.