Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Where to report bugs #22

Closed
bshastry opened this issue Apr 20, 2017 · 8 comments
Closed

Where to report bugs #22

bshastry opened this issue Apr 20, 2017 · 8 comments

Comments

@bshastry
Copy link

Hi,

I have been testing snort3 and have managed to find program crashes in read pcap mode. Where do I report them?

Thanks!
Bhargava

@bshastry
Copy link
Author

Oops, didn't read carefully enough. They need to be sent to bugs@snort.org

Sorry!

@snortadmin
Copy link
Collaborator

Feel free to report on Snort++ issues here. We check both. We will follow up on this one at bugs@. Thanks.

@bshastry
Copy link
Author

Mailed a report to bugs@snort.org. Waiting on your acknowledgement :-)

@bshastry
Copy link
Author

Heho, re-opening since I didn't get a response from bugs@snort.org

@bshastry bshastry reopened this Apr 28, 2017
@snortadmin
Copy link
Collaborator

Oops, my email only went to back to bugs@. I asked this:

"That's an eth:icmp6 packet, which should be illegal, so our fix would be to fail to decode and drop when inline. Did you craft or capture your pcap?"

We have a fix that will be out later today or early next week on github.

@bshastry
Copy link
Author

bshastry commented May 2, 2017

No worries. Shall I initiate a CVE for this or do you have a security process that already takes this into account?

The reason I ask is that FOSS projects differ in how they handle security bugs. I would like to know what snort's view is.

@snortadmin
Copy link
Collaborator

Actually that packet is eth:llc:snap:invalid but due to the Snort++ implementation and a bug in the llc codec (which includes the snap header) it looks to Snort++ like icmp6 and hence the crash.

We have a process. Someone will be contacting you. Thanks.

@snortadmin
Copy link
Collaborator

This issue was fixed. The packet manager now does validation of the ether type and will raise 116:473, (decode) ether type out of range as appropriate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants