CSC/ECE 517 Fall 2009/wiki1a 10 RS56

CSC/ECE 517 Object Oriented Languages

Proposition: Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.

Ruby and Java from a security perspective.

Forward: This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or supervisor attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

Ruby

From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by customers who will then attempt to get support for the modified product. There is a potential of converting the Ruby code into Java bytecode through XRuby or JRuby which could then be better protected. Also, please see the Java discussion below for details.

The data center manager’s view of Ruby is less clear. The interpreted Ruby source language is safely protected from dissemination by layers of servers and firewalls. The potential vulnerability which is increased by dynamic typing may be mitigated by utilization of the tainted and trusted object features. The concept is to not let external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. [1]

The programming manager or supervisor also has a mixed-bag here. Ruby, the programmer’s best friend is touted to provide programming efficiencies that may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. Extra time must be spent with peer and team reviews of potentially dangerous code that an unforeseen type may have on the system.

Java

From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through obfuscation. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program.

The data center manager view of Java is one of a tried and tested product. The Java source code is completely protected by complete separation from the application and database servers. Security alerts are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “untrusted” input feature, there is peace of mind that all input must conform to all downstream types expected and understood by the design architect.

While it may have taken the programming manager’s staff longer to create a product in a type safe environment, the peace of mind that every bug that could be found at compile time was indeed found is priceless. The bugs and security vulnerabilities lurking due to an unchecked type will keep one up at night.

Conclusion

Ruby gives the programmer more tools to leave latent vulnerabilities in production code. The programmer and those reviewing his work must have a heightened security awareness as not to unduly put their enterprise at risk.

Glossary

Obfuscation - The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer.

References

1. Dave Thomas, Chad Fowler and Andy Hunt. Programming Ruby 1.9, chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5