I just ran HP Fortify security scanner against our code, and it appears to be crawling into the LLBLGen Runtime libraries code. It is finding one typical issue it is reporting frequently for the LLBLGen Runtime library: "Null Dereference"

I'm running LLBLGen 4.2: SD.LLBLGen.Pro.ORMSupportClasses.dll 4.2.16.0209 2/24/26 10:56am

Below are some sample occurrences. I'd be happy to send all of them...

Thoughts?

Unable to locate source code of: C Myprojects/VS.NET Projects/LLBLGen Pro v4.2/Frameworks/LLBLGen Pro/RuntimeLibraries/ORMSupportClasses/SelfServicingSpecific/DaoBase.cs

Abstract:

The method PerformFetchEntityAction() in DaoBase.cs can dereference a null pointer on line 287, thereby raising a NullException.

Explanation:

Null pointer errors are usually the result of one or more programmer assumptions being violated.

In this case the variable can be null when it is dereferenced at line 287, thereby raising a NullException.

Most null pointer issues result in general software reliability problems, but if an attacker can intentionally trigger a null pointer dereference, the attacker may be able to use the resulting exception to bypass security logic or to cause the application to reveal debugging information that will be valuable in planning subsequent attacks.

Abstract:

The method PerformPolymorphicEntityFetch() in DaoBase.cs can dereference a null pointer on line 1224, thereby raising a NullException.

Explanation:

Null pointer errors are usually the result of one or more programmer assumptions being violated.

In this case the variable can be null when it is dereferenced at line 1224, thereby raising a NullException.

Most null pointer issues result in general software reliability problems, but if an attacker can intentionally trigger a null pointer dereference, the attacker may be able to use the resulting exception to bypass security logic or to cause the application to reveal debugging information that will be valuable in planning subsequent attacks.

Abstract:

The method CreateQueryForUpdateEntitiesDirectly() in DataAccessAdapterCore.cs can dereference a null pointer on line 5431, thereby raising a NullException.

Explanation:

Null pointer errors are usually the result of one or more programmer assumptions being violated.

In this case the variable can be null when it is dereferenced at line 5431, thereby raising a NullException.

Most null pointer issues result in general software reliability problems, but if an attacker can intentionally trigger a null pointer dereference, the attacker may be able to use the resulting exception to bypass security logic or to cause the application to reveal debugging information that will be valuable in planning subsequent attacks.

Are these reported as errors or just warnings? With some googling I can see some have reported false positives when it comes to Null Dereference.

Hi Walaa,

Fortify doesn't appear to classify issues as "warnings" -vs- "errors". Fortify has different "Filter Sets" a user can choose, that that "Filter Set" decides how to classify the issue. Under the "filter set" we are using, they are classified as "High Priority" issues.

In looking at where I got some of the "Null Dereference" issues in my code, it did seem to be accurate that there was a possible code path to using a null object before it was assigned/allocated. Whether it's actually a "high" security issue is a matter of opinion. For my code cases...yes, there was a path, but I don't think there was ever a realistic possibility of going down that path. Maybe there are other cases where Fortify has true false positives (where there is no even theoretical case)?

Null valued object references in .NET aren't the same as a null pointer in C, this software seems to think it is. That some references might lead to a NRE according to some static analysis software is OK, they're either deliberate (fail fast: so the using developer made a mistake and the code fails immediately) or won't happen in practice. We lean towards fail fast if the developer did something wrong, as there's often little we can do otherwise.

A null reference can't be dereferenced in .NET, you can only use an object reference which is null and you'll get a nullreferenceexception (NRE). A bit too much fearmongering from this tool, IMHO.

The line is here btw: http://referencesource42.llblgen.com/#SD.LLBLGen.Pro.ORMSupportClasses/SelfServicingSpecific/DaoBase.cs,287 but it's a '{'. If they think 'rootEntityCollection' can be null in theory, they're right, but only if someone deliberately made a mistake and cleared the factory. Even if that happens, all that's going to happen at runtime is an NRE is issued, and the dev knows something was wrong immediately.

We analyze our code with Resharper analysis btw (which I think does the same thing as this tool does) and fix any issues which require addressing, e.g. a potential null reference which shouldn't happen. Others, like potential NREs in e.g. xml deserialization are left in deliberately to make the code crash when things are wrong so the developer knows immediately something's off, as there's little sense in recovering at that point.

You can safely ignore this false positive from fortify scan.