Highlighted
Regular Contributor.. kboulebiar Regular Contributor..
Regular Contributor..
1925 views

Unsafe JNI in Java : getClass How to fix it

Hi all,

 

We recently updated fortify and now it appears thousands of issues related to "Unsafe JNI".

It appears every time we are using getClass ( and others clone() , ...)

The problem is that we often see getClass when we override equals methods:

@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;

Do you think we should write a rule that validates all getClass call from Object? Or any idea how to handle this ?  The problem is that we cannot deliver our software if it exists a High issue.

 

Thanks in advance 

Greetings,

Kamel

 

 

 

 

6 Replies
Raphael Hagi Super Contributor.
Super Contributor.

Re: Unsafe JNI in Java : getClass How to fix it

I'm not a Java Guy, but CWE shows some potential fixes. Check it out:

https://cwe.mitre.org/data/definitions/111.html

Hope this helps.


Data, or do not.
0 Likes
Regular Contributor.. kboulebiar Regular Contributor..
Regular Contributor..

Re: Unsafe JNI in Java : getClass How to fix it

Thanks Rapahel , 

Actually i would like to write a rule with "Custom rule editor" saying that "getClass" and "clone" method are safe JNI call. We trust the  Oracle JDK.

 

I tried to write a DataflowCleanseRule but it is not working.

Do you have any clue how to do that?

 

The rule I tried to write looks like this:

  <DataflowCleanseRule formatVersion="19.10" language="java">
                <RuleID>4937C32F-57F1-45B1-B183-6BC29A7019A0</RuleID>
                <TaintFlags>-UNSAFE_JNI,+VALIDATED_UNSAFE_JNI</TaintFlags>
                <FunctionIdentifier>
                    <NamespaceName>
                        <Pattern>java.lang</Pattern>
                    </NamespaceName>
                    <ClassName>
                        <Pattern>Object</Pattern>
                    </ClassName>
                    <FunctionName>
                        <Pattern>getClass|clone</Pattern>
                    </FunctionName>
                    <ApplyTo implements="true" overrides="true" extends="true"/>
                </FunctionIdentifier>
                <OutArguments>return</OutArguments>
            </DataflowCleanseRule>

Taint flags : -UNSAFE_JNI,+VALIDATED_UNSAFE_JNI may not exists ....

And I don't even know if I can write that kind of rule for an issue of type "Structural"

0 Likes
Raphael Hagi Super Contributor.
Super Contributor.

Re: Unsafe JNI in Java : getClass How to fix it

It´s such a common to have new getClass() around your code in every version?

Maybe it's better to mark this as false positive, and let Fortify still looking for this kind of issue, sometimes can a developer use this to get a class outside a JDK.


Data, or do not.
0 Likes
Regular Contributor.. kboulebiar Regular Contributor..
Regular Contributor..

Re: Unsafe JNI in Java : getClass How to fix it

Hi Raphael,

How do you set an issue to "False-Positive" , you simply hide the issue? But when you have hundreds scanned projects and versions , I will lost too much time hidding those issues.

Furthermore, in one big project I have hundreds issues of that kind "unsafe JNI".

 

My ONLY need is to write a custom rule that remove issues of kind "Unsafe JNI" when it is a call to methods "getClass" and "clone".

0 Likes
Raphael Hagi Super Contributor.
Super Contributor.

Re: Unsafe JNI in Java : getClass How to fix it

Hello,

So, if you really considering custom rules, is it possible. The documentation to help you with custom rules development are shipped with your Fortify zip file. Look to "SCA and  Apps" directory, inside of it, you will find the "SCA_Cust_Rules_Guide_<version>.zip" file in subfolder called "Docs". I think it have the assistance that you need.


Data, or do not.
adefender
New Member.

Re: Unsafe JNI in Java : getClass How to fix it

I am also getting this new issue after updating to Java 11 and using SCA 19.1.0, but I am seeing it on calls to other built-in JRE functions: Object.hashcode() and Thread.currentThread(). This implies that JNI functions built into the JRE cannot be trusted.

Is there a valid solution for this issue besides excluding the rule? Is my configuration somehow incorrect that it is identifying built-in JRE functions as not safe to be trusted?

 

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.