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

Responsible disclosure policy #1960

Closed
JamieSlome opened this issue Jan 24, 2022 · 6 comments
Closed

Responsible disclosure policy #1960

JamieSlome opened this issue Jan 24, 2022 · 6 comments

Comments

@JamieSlome
Copy link

Hey there!

I belong to an open source security research community, and a member (@aug5t7) has found an issue, but doesn’t know the best way to disclose it.

If not a hassle, might you kindly add a SECURITY.md file with an email, or another contact method? GitHub recommends this best practice to ensure security issues are responsibly disclosed, and it would serve as a simple instruction for security researchers in the future.

Thank you for your consideration, and I look forward to hearing from you!

(cc @huntr-helper)

@zuckschwerdt
Copy link
Collaborator

Sorry, we don't want to imply that security is a primary concern. We can't offer the assurances or the handling.
This software is explicitly not to be run with privileges. Further it should not be exposed to the internet.
(and if you use the output to do things, know that it isn't a trusted source.)

@zuckschwerdt
Copy link
Collaborator

To any user of rtl_433 reading this, please note: We aim to make rtl_433 safe to use, but it should not be assumed secure.
There is no reason to e.g. run with sudo, we do read and write files without any checks.

The output is literally pulled from thin air, it's not to be trusted. If you feed downstream system with data make sure edge cases are checked and handled. Network inputs and outputs are for use in a trusted local network, will contain unfiltered data, and might overload the recipient (know that e.g. the MQTT output can be controlled by anyone with a radio sender).

@merbanan
Copy link
Owner

@JamieSlome just open an issue and we will attend to it accordingly.

But as @zuckschwerdt says this tool should mainly be used as a rf to network bridge. And the use of the data is mainly for visualization purposes. The parsing code handles >100 different protocols, it is very likely that someone can craft a specific radio transmission to that triggers unwanted behavior.

@JamieSlome
Copy link
Author

@merbanan @zuckschwerdt - thanks for the response, both!

It is unlikely that the reports are consequential given your initial comments here, but both can be read here:

https://huntr.dev/bounties/6c9cd35f-a206-4fdf-b6d1-fcd50926c2d9/
https://huntr.dev/bounties/78eee103-bd61-4b4f-b054-04ad996b39e7/

@merbanan
Copy link
Owner

The issues are valid and will be fixed.

@JamieSlome
Copy link
Author

@merbanan - thanks, appreciate your time and effort here!

If possible, could you approve and confirm fixes against both reports, so that the researcher gets rewarded for their efforts?

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

3 participants