Potential security issue

[zidingz]

Hey there!

I belong to an open source security research community, and a member (@srikanthprathi) 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)

[NiKiZe]

I might be wrong here, but seems that you are posting almost the same thing in many repos?
You can find the repo owners email in the git commits - SECURITY.md sure has it's place, but it can also be a hindrance, and out of date if just created. I will be against it in this repo/project.

[JamieSlome]

Hello @NiKiZe - we request a SECURITY.md, so we can be sure that the person receiving the report has explicit write permissions to the repository.

We reach out via Github Issue in this way, as we want to follow a responsible disclosure process and ensure we send the security concerns to the right, and authorised individuals.

Let me know if you have any questions or further thoughts! 😊

[NiKiZe]

That documentation is only valid if keept up to date, which it might not be even if it is there.
Not sure what security has anything to do with write permission.

Now 3 accounts are involved. Seems weird-ish.

[crankyoldgit]

I belong to an open source security research community

What is the name of the community? Got a link to something?

Hello @NiKiZe - we request a SECURITY.md, so we can be sure that the person receiving the report has explicit write permissions to the repository.

@JamieSlome I definitely have explicit write permission (as the owner of the repo), @NiKiZe has write access too.

Let me know if you have any questions or further thoughts! 😊

This is a completely open project. Feel free to create a new issue (or reuse this one) for any security problems.
I've created a draft Security.md in PR #1617 Please have a read. It expresses my views I think.
Unless there is something implicitly confidential/sensitive in nature, I'm fine with it being public knowledge with in the repo and in the open so to speak.
e.g. If you're dealing with an undisclosed confidential vuln in some component we are using etc., or we are the root cause of some RCE in a major project (e.g. Tasmota), then sure then lets keep it under-wraps etc. If it's a vuln in one of our examples etc, then a normal bug is fine etc.

That said, sure, we'd love to know of & fix the vuln before it is widely publicised etc. e.g. Before you go making announcements etc.

FWIW, I've previously worked at a Nation-level CERT, and Multi-national IT/Internet company on their IT Security teams. Not bragging, just saying I'm fully aware of the things, topics, & issues involved and willing to assist etc.

GPG key is available if required, but nothing in this project/library really warrants that level of paranoia. (plus I'd have to dust off the passphrase ;-)

Oh, and thanks for following "Responsible Disclosure" guidelines. Appreciated. Also happy to give appropriate attribution too.

[JamieSlome]

@crankyoldgit:

What is the name of the community? Got a link to something?

https://huntr.dev

@JamieSlome I definitely have explicit write permission (as the owner of the repo), @NiKiZe has write access too.

https://huntr.dev/bounties/4da00a75-50dc-458b-acc6-cc216e1c854a/ is the actual report. We don't share even this when we create the issue, as it can be seen as breaking GitHub's Guidelines and Community rules (i.e. advertising).

I've created a draft Security.md in PR #1617 Please have a read. It expresses my views I think.

Dropped a review on it!

[crankyoldgit]

https://huntr.dev/bounties/4da00a75-50dc-458b-acc6-cc216e1c854a/ is the actual report. We don't share even this when we create the issue, as it can be seen as breaking GitHub's Guidelines and Community rules (i.e. advertising).

@JamieSlome I looking at the proffered link without logging in, it looks like (from the context surrounding the blurred text) it is a case of a poor quality regex (i.e. CWE-1333 etc). I don't think we have any regex in the core of the library, or even in the examples we offer to users.
There are however regex in some of our internal tools we use when doing releases.
i.e.

IRremoteESP8266/tools/scrape_supported_devices.py

Lines 13 to 21 in ca44fa3

	BRAND_MODEL = re.compile(r"Brand: *(?P<brand>.+), *Model: *(?P<model>.+)")
	ENUMS = re.compile(r"enum (\w+) {(.+?)};", re.DOTALL)
	ENUM_ENTRY = re.compile(r"^\s+(\w+)", re.MULTILINE)
	DECODED_PROTOCOLS = re.compile(r".*(?:results->decode_type *=.*?|"
	r"typeguess\s*=\s*decode_type_t::)(\w+);")
	AC_FN = re.compile(r"ir_(.+)\.h")
	AC_MODEL_ENUM_RE = re.compile(r"(.+)_ac_remote_model_t")
	IRSEND_FN_RE = re.compile(r"IRsend\.h")
	ALL_FN = re.compile(r"ir_(.+)\.(h|cpp)")

And that tool (scrape_supported_devices.py) isn't even exposed to untrusted data.

As the "tools" directory is pretty much the only one with regex in/used by the code, it's of very low priority/importance in the scheme of things. Thus, I'm more than happy for your team to drop the details in a new (public) Issue on this repo.

Per your FAQ:

I'm a maintainer, but don't want to sign up. What should I do?

If you have been notified of a vulnerability disclosure against your repository, we will send a magic link to the elected e-mail address in your SECURITY.md. This magic link will allow you to view the private advisory, and validate/invalidate if necessary.
If you do not have a SECURITY.md in your repository, we will ping you the advisory information once you have added this.

Feel free to send the magic link to myself & @NiKiZe.
Per our code review policy, the Security.md will only be merged once it's been through our process. Thanks for your additional review, but I'll wait for @NiKiZe as he seems to have some thing to say on the issue.

[crankyoldgit]

And that tool (scrape_supported_devices.py) isn't even exposed to untrusted data.

Oh, that's incorrect now that I think about it. Someone could submit a PR with something evil in it. The worst that will happen is they get an RCE in a GitHub Actions container. Thankfully they (GitHub Actions) have no additional privileges above any other GitHub user w.r.t. this repo. So we are still fairly safe.

[NiKiZe]

And that tool (scrape_supported_devices.py) isn't even exposed to untrusted data.

Oh, that's incorrect now that I think about it. Someone could submit a PR with something evil in it. The worst that will happen is they get an RCE in a GitHub Actions container. Thankfully they (GitHub Actions) have no additional privileges above any other GitHub user w.r.t. this repo. So we are still fairly safe.

I would be more worried about a code execution and running it on my local machine - but since we must review and approved any new contributors PRs this is probably low risk (even if we don't check for non visible chars)

[crankyoldgit]

@zidingz @JamieSlome @srikanthprathi In the interest of saving time, as it seems GitHub's "privacy" email system doesn't seem to work as advertised, please feel free to email me directly at david@xyzzy.com.au

[zidingz]

Thank you for your patience and understanding!

An email should be with you in an hour.

[crankyoldgit]

I'll keep any eye out for it.

[crankyoldgit]

@zidingz I haven't seen any email to the above address from you or your org yet.

[crankyoldgit]

FYI, the PR has been merged, the repo now as a Security.md that you can read/reference etc.

[crankyoldgit]

Confirming I got the email with the magic link.

[crankyoldgit]

FYI, the changes mentioned above have now been included in the new v2.8.0 release of the library.