Community
Participate
Working Groups
From the security inbox: -- To me it looks like as if the ioFog agent fails to properly validate server side TLS certificates: See: https://github.com/eclipse-iofog/Agent/blob/23b787fc165f4d4f0a5c1d7b8d58d705e73ebc3e/iofog-agent-daemon/src/main/java/org/eclipse/iofog/utils/trustmanager/X509TrustManagerImpl.java#L33-L45 This is present in ioFog 2.0, but the same code is also part of the most recent development branch. To my understanding of the code, the validator only checks if the server presents at least one certificate which is signed by the trust anchor. However, this can basically be any certificate. Additionally, timestamps and hostnames not checked. If this is the case, then I think a CVE ID should be assigned. --
There's help for handling vulnerability reports in the handbook: https://www.eclipse.org/projects/handbook/#vulnerability And, specifically, for assembling information for a CVE: https://www.eclipse.org/projects/handbook/#vulnerability-cve Let me know if you have any questions or require any assistance.
Project team: we require your engagement on this issue.
Thanks Wayne we will look into it. Are you able to help with the following issue? We need to fix up our repo branches but don't have permissions: https://bugs.eclipse.org/bugs/show_bug.cgi?id=572384
(In reply to Serge Radinovich from comment #3) > Are you able to help with the following issue? Not directly, no. You'll need to work with Webmaster. I have no special powers that help here.
(In reply to Wayne Beaton from comment #1) > There's help for handling vulnerability reports in the handbook: > > https://www.eclipse.org/projects/handbook/#vulnerability > > And, specifically, for assembling information for a CVE: > > https://www.eclipse.org/projects/handbook/#vulnerability-cve > > Let me know if you have any questions or require any assistance. (In reply to Wayne Beaton from comment #0) > From the security inbox: > > -- > To me it looks like as if the ioFog agent fails to properly validate server > side TLS certificates: > > See: > https://github.com/eclipse-iofog/Agent/blob/ > 23b787fc165f4d4f0a5c1d7b8d58d705e73ebc3e/iofog-agent-daemon/src/main/java/ > org/eclipse/iofog/utils/trustmanager/X509TrustManagerImpl.java#L33-L45 > > This is present in ioFog 2.0, but the same code is also part of the most > recent development branch. > > To my understanding of the code, the validator only checks if the server > presents at least one certificate which is signed by the trust anchor. > However, this can basically be any certificate. > > Additionally, timestamps and hostnames not checked. > > If this is the case, then I think a CVE ID should be assigned. > -- AFAIK that code is intended to accept any certificate signed by the configured trust anchor. Why is this(In reply to Wayne Beaton from comment #0) > From the security inbox: > > -- > To me it looks like as if the ioFog agent fails to properly validate server > side TLS certificates: > > See: > https://github.com/eclipse-iofog/Agent/blob/ > 23b787fc165f4d4f0a5c1d7b8d58d705e73ebc3e/iofog-agent-daemon/src/main/java/ > org/eclipse/iofog/utils/trustmanager/X509TrustManagerImpl.java#L33-L45 > > This is present in ioFog 2.0, but the same code is also part of the most > recent development branch. > > To my understanding of the code, the validator only checks if the server > presents at least one certificate which is signed by the trust anchor. > However, this can basically be any certificate. > > Additionally, timestamps and hostnames not checked. > > If this is the case, then I think a CVE ID should be assigned. > -- What changes to the code are you suggesting apart from checking hostnames/timestamps?
My previous comment should only say: What changes to the code are you suggesting apart from checking hostnames/timestamps? Has Bugzilla been updated since the 1900s?
> What changes to the code are you suggesting apart from checking > hostnames/timestamps? Jens, can you answer this? > Has Bugzilla been updated since the 1900s? Stable software can be off-putting. Having said that, we are in the process of moving all of this stuff over to GitLab. We use Bugzilla primarily because it provides a means to restrict the visibility of vulnerability reports until we're ready to disclose. If Bugzilla hurts your eyes, then please add a SECURITY[.md] file to your repositories with specific instructions on how to report vulnerabilities for your project and we'll follow that. We have some ongoing work to sort out a template here [1] [1] https://gitlab.eclipse.org/eclipse/dash/org.eclipse.dash.handbook/-/issues/150
Please not that on some older systems like Debian 9 we get ``` Provision failed with error message: "Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty" ``` This is fixed by updating certs in `/etc/ssl/certs/`. I have only done this by manually copying over the cert files from a working system during debugging. Not sure what `ca-certificates` command etc could be the proper fix.
(In reply to Wayne Beaton from comment #7) > > What changes to the code are you suggesting apart from checking > > hostnames/timestamps? > > Jens, can you answer this? > I think I already addresses this in: https://github.com/eclipse-iofog/Agent/pull/378
The 30 month confidentiality period has passed, so I'm removing the committer-only flag. Is there a resolution to this issue available? (In reply to Wayne Beaton from comment #1) > And, specifically, for assembling information for a CVE: > > https://www.eclipse.org/projects/handbook/#vulnerability-cve Can you provide me with the information that I need to create a CVE?
(In reply to Wayne Beaton from comment #10) > The 30 month confidentiality period has passed, so I'm removing the > committer-only flag. Um... "3 month"
This issue has been migrated to https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/623.
