search

cushon / issues-import

0 stars 0 forks source link

== true test #132

Open cushon opened 10 years ago

cushon commented 10 years ago

Original issue created by grosse@google.com on 2013-05-15 at 04:26 PM

Tests of the form (expr == true) are a potential security issue when interacting with untrusted bytecode, as the bytecode may return a boolean that is not equal to true or false. Booleans are compiled to 32bit ints, while the constants true and false are compiled to 1 and 0. Without an explicit equality test, all nonzero values are treated as true, so booleans will behave as Java programmers expect.

It might make sense to warn about both (== true) and (== false) even though the later doesn't present the same risk. People rarely write code like this, so it may indicate a programmer mistake.

Code containing these tests can be easily fixed. (var == true) is replaced with (var) while (var == false) is replaced with (!var).

cushon commented 10 years ago

Original comment posted by eaftan@google.com on 2013-05-15 at 05:12 PM

This is fascinating, I hadn't heard of this. Do you have a reference on this? Is this still a problem on modern VMs?

For context, Java VM Spec 2.3.4 says: "Although the Java Virtual Machine defines a boolean type, it only provides very limited support for it. There are no Java Virtual Machine instructions solely dedicated to operations on boolean values. Instead, expressions in the Java programming language that operate on boolean values are compiled to use values of the Java Virtual Machine int data type."

cushon commented 10 years ago

Original comment posted by grosse@google.com on 2013-05-15 at 08:11 PM

Yes it is a "problem" on modern VMs. I've confirmed it myself with handwritten bytecode.

The issue is that not all of the Java language level restrictions are enforced at the bytecode level. So Java code that interfaces with untrusted bytecode and is written assuming those restrictions hold may not behave correctly.

Other notable problems in the same vein include boolean/byte arrays, interface types, checked exceptions, method signatures, and pretty much anything relating to inner classes and generics.

Fortunately, I haven't yet found any real world code where this is a problem.