Hi,

Few days back done some security audit.In audit report found one thing i.e,[FAIL] nullpointer -- Tests for the null pointer dereference vulnerability.

how to find where i'm getting this problem?how to solve it.

Please suggest me.

thanks,
Raghu.

What did you run to get that report? That makes little or no sense to me, and here's why.

It appears to be a program problem versus a security issue. A NULL pointer, is referencing address 0x00000000.

In operating systems that is an invalid address because it's typically the start vector for the CPU.

If code branches or jumps to that location, that typically ends up resetting your processor. That would be "session catastrophic" (my invented term) because it restarts your computer. I don't feel that it is damaging with the exception that any open programs and their associated data are lost. The equivalent is if you force a reboot at an inopportune time; or if you lose power on a system that doesn't have a battery. Bummer, but not the end of the world.

If a program attempts to access a NULL address location; for instance it has a pointer to some data and that pointer happens to be corrupted to be NULL, then what happens is a software exception, which means the program attempted to access an illegal memory location. Similar to when you have a program that crashes where it goes from working, to suddenly either just gone, or popping up a fault screen and giving you the option to go to a debugger. This is almost always a software bug in that particular program. Again, not IMHO a security breach of any type. In fact, I'm wondering if the software which ran to perform this audit was the program which had an address exception fault and that's the report you're seeing.

The other variation is my less than gratuitous opinion that some "security audit", pardon my phrase "crapware" gives the operator these elusively, onerous sounding terms, thus raising your concern antenna. I also do wonder if it is Malware of some type. Any chance this all happened as part of a pop up from a browser?

would be nice to ask them to explain the source (origin) of that message. Without additional info it has no any real meaning. (What was checked at all, how, ....)
Something was wrong somewhere....

A google search of the key phrase gets a lot of hits, most of which give unsupported claims about the issue with no real information. That seems to be a technique for selling security services (exaggerated and confusing claims about vulnerabilities without info to back it up).

I found one page with a decent explanation of an issue with that same description. That is not necessarily the only issue with that description, just the only one I could find explained:

http://www.kb.cert.org/vuls/id/650142

That example (and most of the other unexplained ones) are potential "denial of service" vulnerabilities, meaning someone outside can cause a program running on your system to crash. It does not mean they can steal your data or take over control of your system, just make something on your system crash.

It is very clear that this vulnerability provides a way for a malicious web site to cause your browser to crash. But I consider that too trivial to worry about. When a malicious web site causes your browser to crash you just restart your browser and avoid that site.

A more serious "denial of service" would be if a malicious browser could cause your web site to crash. I don't see anything in any of the descriptions I found with google that would make me believe this vulnerability acts in that direction. But I don't see enough detail to rule that out.

So far as getting rid of it, you need to update the package in which the problem was found to one new enough that the problem is fixed. It is not something you can fix yourself other than by getting the newer version after the package maintainer has fixed it.

Edit: I found a slight less explained but more serious issue with the same phrase in its description:

http://xforce.iss.net/xforce/xfdb/91985

That sounds like it would let a hostile local user crash the whole system. I don't know if you have users who have been given the right to compile and run their own programs, who also might be malicious. I am more used to an environment where outside users cannot compile or run their own programs and inside users are not malicious.

There does seem to be a patch available if that one is the issue you are worried about.

If you want to read from a null pointer, more power to you. It's a useless thing to do, and you will read garbage, but you won't hurt anything. Other than possibly making your program go brain-dead and crash, depending on how well, or how poorly, you wrote the program.

Now, if you try to WRITE to the null pointer, that would be writing to someplace you shouldn't be. I think most, if not all, OS'es these days will prevent this operation. That wasn't the case back "in the old days". I have imcompetantly written to many nulls pointers in my decades long career, with disasterous results sometimes (crash the system). But the box would reboot back just fine, and other than the disturbance of having crashed the thing, no harm done (although the potential for harm - maybe a corrupted filesystem from the crash - obviously exists).

I guess I did have ONE instance of badness from reading the null pointer. I remember a C program, running as root on a System V box, that I diagnosed eventually as reading from the null pointer. Problem was, that program was running as root, and passed the results of the null pointer read to "kill". It was supposed to be pointing to a process id. Well, I guess it was, randomly, but apparently that "process id" happened to be "1" or something else equally as bad. The box came down rather fast and unexpectedly!