Snort Exploit ( general expolit question)

[S3cur|ty4ng31]

I read some posts about some bugs with snort so I basically did some more investigation and I realized that I can crash snort with a number of hand crafted packets.

Now the bottom line was that it is basically seg-faulting because of a null pointer exception. So from what I know that means there is no way to exploit in a way to run arbitrary commands and the only thing you could do is dos the program.

Or is there a way to exploit a null pointer? I googled around and I read some stuff about lynxOS being vulnerable to null pointer exceptions. Im not really sure how that would work, I mean you cant influnece the run time stack right?. Is it completely impossible or are there ways to execute commands this way?

[Tiger Shark]

I think you'll find those vulns were patched in about 1.8(something). We are now at 2.2 so I don't think they are relevant any more. Correct me if I am wrong though.....

[S3cur|ty4ng31]

No the code I wrote will actually crash 2.13 and 2.20.
Its been brought to the snort team attention though so it should be fixed by 2.3 but I dont se the fix in cvs yet.

But like I said its a null pointer exception. So I dont think it can be exploited except for dos'ing snort.
Im just more curiious if someone could make a remote expolit or anything else from a null pointer exception.

[thehorse13]

Like anything else, it depends. More details are needed on exactly what you found and where/when this happens. I would say that DoSing an IDS is pretty significant. You might want to release your findings to BugTraq if they do not respond in a timely manner.

Also, don't be surprised about the speed at which the snort folks respond to bugs. We found a way to beat out pattern matching in snort yet to date, it hasn't been addressed. At least not that I'm aware of.

[SirDice]

That null-pointer exception is probably the result of something else gone amiss. Something like a memory request not succeeding i.e. will return a null-pointer. It's hard to say..

Compile snort with debug options and break into a debugger when it segfaults. Do some stack backtracing, look at the source, set some break points etc..

In other words you need to find out what exactly is happening to snort if it encounters your "hostile" packets. Then you can look at ways to exploit it, if that's possible.

[phishphreek]

Originally posted here by thehorse13
Like anything else, it depends. More details are needed on exactly what you found and where/when this happens. I would say that DoSing an IDS is pretty significant. You might want to release your findings to BugTraq if they do not respond in a timely manner.

Hell yeah, it is significant. If it can be DoS'd then there is really no reason to have it there. It just becomes a waste of resources. Not to mention figuring out a way top bypass it all together.

Also, don't be surprised about the speed at which the snort folks respond to bugs. We found a way to beat out pattern matching in snort yet to date, it hasn't been addressed. At least not that I'm aware of.

I beleive that you mentioned this some six + months ago? That is a LONG time. And people complain about m$ taking a long time to release fixes for serious problems. They are probably taking their sweet old time because the info on it wasn't released. What would that do to Snort's image. Good thing that info is in trustworthy hands...

[S3cur|ty4ng31]

Its not that serious because it only effects snort when the verbose flag is set. So most people using it as an IDS would just daemonize it and not also use the -v flag. In IDS it actually does detect a malformedpacket. When the -v flag is on it tries to display information about the packet that doesnt exist. I know exactly where in the code it does this and I have made POC code that can segfault it on a number of different packets. So its really not that serious but out of my own curiosity I wanted to see if it was possible to exploit this(since it would still be cool to get a root shell if some was running ./snort -v).

From my knowledge there is no way yo exploit it. Theres basically a buffer that is null and it is displayed to output. But i talked to someone else and he said an OS like Link OS (not sure about spelling) and a few others would be vulnerable. So I would assume this means that have a different style of run time stack or that variables get certain address's or ...... well really thats why I asked because while I dont think its possible and other peo[le are telling me it is and I was just curious how and why.