CSC/ECE 517 Fall 2009/wiki1a 10 RS56

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.

Perspective on Security

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 a software publisher 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 review team 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 perspective of the software publisher or programmer who publishes his own work, Ruby presents a challenging environment. Disseminating precious source language to customers means certain plagiarism. Modifications will be made by clients who will then attempt to get support for the modified product. Work is currently underway on having the ability of converting Ruby source code into Java bytecode through XRuby or JRuby, which could then be better protected. Please see the Java discussion below for details of this protection.

The data center manager’s view of Ruby is less clear. Ruby does have a robust Issue Tracking System which is comforting. However, much of the Ruby security information is disseminated in less than polished blogs. I would have published a link here except my anti-spyware flagged one of the blogs as a potential threat! In this not for publication perspective, the interpreted Ruby source language would also be safely protected from dissemination by layers of servers and firewalls. The potential vulnerability, which is increased by dynamic typing and extending classes, may be mitigated by utilization of the tainted and trusted object features. With the tainted feature, the concept is to not let uncontrolled 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. The variable $SAFE, determines how much protection Ruby will afford to the executing thread.[1]

#Example of Ruby Tainted Objects
puts "Programs start with $SAFE level = #{$SAFE}"
myTrustedObject = "Data to be protected"
myTrustedObject = "Data to be protected with valid update #1"
$SAFE = 2
myTrustedObject = "Data to be protected with valid update #2"
$SAFE = 3
myTaintedObject = "Tainted data can be destroyed"
puts "Thread at $SAFE level: #{$SAFE} produced myTaintedObject: #{myTaintedObject}"
myTaintedObject = "Tainted data destroyed"
puts "Thread at $SAFE level: #{$SAFE} destroyed myTaintedObject: #{myTaintedObject}"
$SAFE = 4
myTrustedObject = "Data destroyed"
puts myTrustedObject

Programs start with $SAFE level = 0
Thread at $SAFE level: 3 produced myTaintedObject: Tainted data can be destroyed
Thread at $SAFE level: 3 destroyed myTaintedObject: Tainted data destroyed
trust_test.rb:26:in `write': Insecure operation `write' at level 4 (SecurityError)
	from trust_test.rb:26:in `puts'
	from trust_test.rb:26

Ruby 1.9 also adds the concept of “Trust”. Here, code itself can be marked untrusted. All objects created by the code will be untrusted and all objects it can modify must also be untrusted. The effect is creating a wall between the untrusted objects and the trusted system.[1]

#It is anticipated that a Ruby Trusted Object example will be placed here; however,
#CSC/ECE 517 is currently using a level of Ruby that does not support this feature.

The programming manager and review teams also have a mixed-bag here. Ruby is touted to provide programming efficiencies and programming joy. These characteristics may be offset by the potential for otherwise easily detected compile-time bugs perpetuating into runtime due to the lack of static typing. Extra time must be spent with peer and team reviews to mitigate this possibility. All potentially dangerous code that could have a system impact must be manually analyzed to prevent the instantiation of an unforeseen type which could present a risk to the system. However, Ruby (like Perl, its predecessor), adds by its very scripting nature, extensive Regular Expression support. This additional support can be said to counteract a primary security vulnerability of overrunning buffers caused by malicious input.

Java

From the software publisher’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’s view of Java is one of a tried and tested product. Sun Microsystems maintains an extensive array of polished Secure Coding Guidelines. Here, Sun details a set of six multi-part guidelines for protecting against common threats. There are also other security related Web pages. Here Sun details the benefits of Java’s platform security including strong data typing, automatic memory management, bytecode verification and secure class loading. Cryptography, authentication and access control, secure communications and public key infrastructure are also touted.

The Java source code is 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 “trusted/untrusted” input feature, Java design conforms to the “sandbox” model. All remote code can be isolated and prevented from causing damage to local code and resources. Due to the static typing, there is a peace of mind that all input must conform to downstream types expected and understood by the design architect.

Copious amounts of demonstration Java code to implement security is provided on the Sun Microsystems Web site such as the following example to defend against partially initialized instances of non-final classes:

// non-final java.lang.ClassLoader
public class ClassLoader {

    // initialized flag
    private volatile boolean initialized = false;

    protected ClassLoader() {
        // permission needed to create ClassLoader
        securityManagerCheck();
        init();

        // last step
        initialized = true;
    }

    protected final Class defineClass(...) {
        if (!initialized) {
            throw new SecurityException("object not initialized");
        }

        // regular logic follows
    }
}

While it may have taken the programming manager’s staff longer to create a product in a type safe environment, all bugs that could be found at compile time, were indeed found. The bugs and security vulnerabilities lurking due to an unchecked type, will not keep anyone up at night. Java, on the other hand, does not have built in Regular Expression support. This forces the programmer to handle the most conspicuous form of attack with a set of add-on classes.

Conclusion

Successful and secure Web sites have been built and will continue to be constructed with both Ruby and Java. Java presents a more polished view of security on the Sun Microsystems Web site than does the Ruby organizations and their associated blogs. Ruby gives the programmer dangerous tools which may allow latent vulnerabilities to exist in production code. The programmer and those reviewing his work must have heightened security awareness as to not put their organization at risk. However, as we have discussed, Ruby provides security capability that is missing from Java.

Glossary

Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not directly by the underlying computer hardware

Interpreted Code – The technique of directly processing programming language source text and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code

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

Regular Expression – A means of identifying and matching text strings

Tainted Object – Any Ruby object derived from some external source is automatically marked as being tainted.

Trusted Object – A Ruby object, created by code running at $SAFE levels 0, 1 or 2, which cannot be modified by code running at $SAFE levels 3 or 4.

References

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
http://xruby.com
http://jruby.org
http://redmine.ruby-lang.org
http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html
http://www.sun.com/support
http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc1.html
http://java.sun.com/security/seccodeguide.html
http://java.sun.com/javase/technologies/security/index.jsp

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

Contents

Perspective on Security

Ruby

Java

Conclusion

Glossary

References

Navigation menu

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

Perspective on Security

Ruby

Java

Conclusion

Glossary

References

Navigation menu

Search