Is it easier to exploit open soucre?

As soon as the term "open source" has been coined discussion regarding security of such solutions versus ones with closed source code started. When finally it seemed that this discussion is over (could computing is now cool topic) "An Empirical Analysis of Exploitation Attempts based on Vulnerabilities in Open Source Software" report has been published as part of "Workshop on the economic of information security". Obviously information security is tightly connected with economy. Perfect example of this is cryptography when one often assumes security level based on time, computing power and energy consumption estimation. All and every single one of those attributes is closely connected with economy. So generally noneconomic attacks are not performed. This is why such report seemed very interesting for us.

As for the report, go on and read it and judge it yourself. On several mailing lists some very interesting topics has been brought regarding this work, so there is no point repeating the same content. On the other hand we have to answer similar questions more often than we would like so it seems that this is a very good opportunity to present not only few facts but also our thoughts and experiences (not necessary directly connected with above publication).

1. The development lifecycle of secure applications is not a trivial process and it needs proper alignment. The process is not influenced directly by the source code access policy.
2. Inexperienced and lacking proper education programmers will always produce bad and insecure code no matter is it open source or not project.
3. Dedicated internal solutions seem to be more insecure as it is easier to forget / ignore security concerns in such cases.
4. Auditing source code – especially for more complex issues like state problems – is a very time consuming and complex process. At the end of the day it might be not feasible from economic perspective in certain cases.
5. Finding vulnerabilities in binary executables is a solution when most of the process can be automated.
6. In case of exploit creation for classical boundary condition errors source code access might not mean any advantage as we operate on stack frame or heap structure. All those elements are hidden from source code perspective. Even in case of auditing assembly language source code for Win32/64 platforms, macros can successfully hide some important details.
7. The compilation process cannot be treated as a information protection safeguard. During code writing we advice to use same approach as with designing cryptography: it’s not the secretes of operation that makes solution secure – it’s the strength of used algorithms.

From the above characteristics it is becoming obvious that more vulnerable are those applications where security was not a concern. Source code access has nothing to do with it in this case. The economy of finding vulnerabilities and exploiting them – due to process automation – points at web applications and binary executables (regardless of source code access). The final note worth making is the fact that many popular technologies used today are bytecode based. Java. .NET or Python are in this category just to name a few. Bytecode decompilation is usually easy and automatic. Hex-Rays – the company that is responsible for IDA Pro – is also offering advance decompilation plugin producing C output. So at the end of the day the cost of security level and working exploit delivery is not always directly connected to source code access.