Community
Participate
Working Groups
Created attachment 288634 [details] Security advisory Hi, During the security assessment of one of our clients, we discovered security issues on BIRT Viewer. This issue could allow an authenticated attackers to execute commands on the underlying server. Indeed, the default configuration of BIRT Viewer allows specifying report paths that match the current domain. However, in certain configurations, it does not check properly the origin of a Report Design file. Find attached our advisory of the vulnerability. Regards,
By the way, clicking the provided link (at https://github.com/eclipse/birt/security/policy) does not mark the vulnerability as "commiters-only" and I cannot find the way to do it here.
@John, WDYT about this report?
Hello, Do you have any news regarding this report? Best regards,
Hello, Do you have any news regarding this report?
Hello, Just a gentle reminder about this report :)
(In reply to Louis Wolfers from comment #5) > Hello, > > Just a gentle reminder about this report :) @John, @Wim, please give a heads up to Louis. Thanks!
(In reply to Louis Wolfers from comment #5) > Hello, > > Just a gentle reminder about this report :) Hi Louis, Thanks for providing this report. When reading the report, do I understand correctly that this is the solution? The response to this request must be intercepted to either: • Obtain a viewingSessionId, required to make the request to the SOAP endpoint that will effectively execute the command. • Modify the HTML base tag (which is reflected from the edited Host header) so that the browser makes the subsequent requests to the correct server.
Hello Wim, No, that's a step the attacker needs to do in order to successfully exploit the vulnerability. The vulnerability relies on the fact that Birt uses the Host header to verify if the __report parameter is pointing to the current domain. However, an attacker can modify the Host header and the request would still be processed on poorly configured Apache servers (e.g. when no virtual hosts are defined). My recommendation would be to: - Set "none" as the default value for the URL_REPORT_PATH_POLICY parameter. - Create a new URL_REPORT_DOMAIN_POLICY parameter that contains the list of authorized domains from which reports can be retrieved if the URL_REPORT_PATH_POLICY's value is "domain". This is my opinion, but I would also remove the "all" value for the URL_REPORT_PATH_POLICY or at the very least indicate on the documentation that this parameter is really unsafe by default (I've seen this value being set without any firewalling). It should also be made very clear to the users that using remote paths for reports from untrusted sources is dangerous and can lead to remote code execution.
Hello and happy new year! Wim, could you get a better look at the advisory? Feel free to ask questions if you have any.
(In reply to Louis Wolfers from comment #8) > > My recommendation would be to: > - Set "none" as the default value for the URL_REPORT_PATH_POLICY parameter. > - Create a new URL_REPORT_DOMAIN_POLICY parameter that contains the list of > authorized domains from which reports can be retrieved if the > URL_REPORT_PATH_POLICY's value is "domain". Hi Louis, Thank you for your persistence. I agree with your analysis. So the problem is that getting the hostname from the request is a vulnerability because that can be spoofed in the request. Is this BIRT's job to handle? How can we possibly code against all vulnerabilities in the server we are running on? Or code against ill-configured web servers? Cheers, Wim
(In reply to Louis Wolfers from comment #9) > Hello and happy new year! > > Wim, could you get a better look at the advisory? Feel free to ask questions > if you have any. I have made a change here. Can you take a look at it? https://github.com/eclipse/birt/pull/1165
(In reply to Wim Jongman from comment #10) > Is this BIRT's job to handle? How can we possibly code against all > vulnerabilities in the server we are running on? Or code against > ill-configured web servers? I do not think it should be BIRT's job to handle, to a certain extent: this vulnerability appears using the default configuration of Apache Tomcat and the default configuration of BIRT. Another way of solving this issue is by only modifying the default configuration of BIRT (URL_REPORT_PATH_POLICY to none) and warning the user of potential security issues if their configuration allows arbitrary content on the Host header. (In reply to Wim Jongman from comment #11) > I have made a change here. Can you take a look at it? > > https://github.com/eclipse/birt/pull/1165 Sure, I will look at it
The patch looks good to me ! Could you assign a CVE for this vulnerability ?
(In reply to Louis Wolfers from comment #13) > The patch looks good to me ! > > Could you assign a CVE for this vulnerability ? I would like to have the fix verified first. Can you rerun your test with the version that contains the fix? Binaries can be downloaded here: https://github.com/eclipse/birt/actions/runs/3830002040
(In reply to Wim Jongman from comment #14) > Can you rerun your test with the version that contains the fix? Hello, This fixes the vulnerability correctly, and I cannot find a way of bypassing it. Do you know if you have any policies regarding vulnerability disclosures at Eclipse?
Ok, I also verified it. @Wayne / @Mikael can one of you assign a CVE? Louis, thanks for the discovery and for the proposed solution, which is described here: https://github.com/eclipse/birt/discussions/1169
(In reply to Wim Jongman from comment #16) > Ok, I also verified it. @Wayne / @Mikael can one of you assign a CVE? > > Louis, thanks for the discovery and for the proposed solution, which is > described here: > > https://github.com/eclipse/birt/discussions/1169 Please open a request at https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/new?issuable_template=cve. Thanks!
(In reply to Mikaël Barbero from comment #17) > Please open a request at > https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/ > new?issuable_template=cve. Thanks! Hello Mikaël, The request can be found at: https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/432 Thanks!
@Wim, Has this vul. been published in a release? Can the CVE be published? Thanks!
Wim, as you may not be able to see the ticket, the CVE number is CVE-2023-0100
(In reply to Mikaël Barbero from comment #19) > @Wim, > > Has this vul. been published in a release? Can the CVE be published? > > Thanks! Yes, it can be published.
If I'm not mistaken, 4.13 (the version containing the fix) has not been released yet. Correct? Are you sure you want to publish the CVE without having the release done first?
(In reply to Mikaël Barbero from comment #22) > If I'm not mistaken, 4.13 (the version containing the fix) has not been > released yet. Correct? Are you sure you want to publish the CVE without > having the release done first? Yes, you are right. Let me release it first.
Hello Wim, Just wondering, do you have an ETA for the 4.13 release?
(In reply to Louis Wolfers from comment #24) > Hello Wim, > > Just wondering, do you have an ETA for the 4.13 release? Yes, March 1, 2023 👍 https://projects.eclipse.org/projects/technology.birt
Hello, Do you wish to wait a little bit before releasing? Also, would you mind if I talk about this vulnerability at a small cyber-security conference (with a small public of around 40 people, mostly students)? Best regards
(In reply to Louis Wolfers from comment #26) > Hello, > > Do you wish to wait a little bit before releasing? > > Also, would you mind if I talk about this vulnerability at a small > cyber-security conference (with a small public of around 40 people, mostly > students)? > > Best regards Hi Louis, We have released 4.13. No problem with your talk. Thanks for helping us.
CVE has been published. Closing and removing the committer-only visibility.
Thank you Louis for your report and your patience with this one!
