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 the programmer protecting his 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 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 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 the site as a potential threat! 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, the programmer’s best friend, is touted to provide programming efficiencies. That fact may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. However, extra time must be spent with peer and team reviews. 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.

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’s view of Java is one of a tried and tested product. Sun Microsystems maintains an extensive array of polished Secure Coding Guidelines and other security related Web pages. 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.

Conclusion

---

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.

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

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

---

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