Created attachment 1083 [details] the original report and the details of the reported vulnerability This is Noriko Totsuka from JPCERT/CC Vulnerability Coordination Group. We have received a vulnerability report on the product "IPFire" from a researcher/user here in Japan. We would like to coordinate with you to solve the reported vulnerability, and your cooperation would be greatly appreciated. The attached file is the original report and the details of the reported vulnerability. - JVN#15411362 IPFire contains a cross-site scripting vulnerability Please read through the report and return to us with the information such as; -validate the products, and whether the reported vulnerability is confirmed or not -solutions (e.g., patch or module update) -workarounds if any -estimated time for creation of fixes -preferable date for public release on your site *we will also publish an advisory for these issues on our vulnerability knowledge base, JVN, https://jvn.jp, https://jvn.jp/en/, synchronizing with your release schedule. About us: JPCERT/CC, non-profit organization, is working as a vulnerability information coordinator between the reporters and the product vendors relevant to the reports. Please check the following websites for more information. https://www.jpcert.or.jp/english/ https://www.jpcert.or.jp/english/vh/project.html https://jvn.jp/en/ ====================================================================== JPCERT Coordination Center (JPCERT/CC) EMAIL: vuls@jpcert.or.jp PGP key: 0xF652B38B: 9C3D 85CA 8E9E F820 9805 C9EF 4262 4548 F652 B38B https://www.jpcert.or.jp/english/
Thank you very much for your research and submitting this bug report. I will mark it as security sensitive which will hide the report for now until we have analysed the report and confirmed the vulnerability. We will then provide a fix and make the report publicly accessible again.
Created attachment 1084 [details] mail.cgi: Validate email recipient
Created attachment 1085 [details] proxy.cgi: Correctly validate domain lists These patches fix the reported vulnerabilities. Could you please review the patches and confirm? If so, I will make the report public again and submit the patches to our mailing list for further review.
Hello. Thank you very much for your response. We will pass your request to the original reporter. Once we hear back from him, we will let you know. Please wait a moment.
We have received the reply from the original reporter. ----------------------------------------------------------------- Reporter's reply (begins here) ----------------------------------------------------------------- I have confirmed that a new check has been added at the location I reported. I'm aware that it is necessary to confirm the actual behavior in the future, but I believe that the point I reported have been addressed. ----------------------------------------------------------------- Reporter's reply (ends here) ----------------------------------------------------------------- The original reporter requested us to publish the advisory for this issue on JVN <https://jvn.jp/en/, https://jvn.jp/> with CVE assigned to it. It is greatly appreciated if you could tell us the new version release schedule (date and time) when it is determined. We will publish JVN advisory synchronizing with your release. If you have not already obtained CVE on your end, we will assign CVE as a CNA (CVE Numbering Authority) for this vulnerability. Please let us know if it has been assigned or not. Right now, we are creating the advisory draft. Once it's written up, we will send it over to you for your review. Thank you for your cooperation. We await for your reply.
(In reply to Noriko Totsuka from comment #5) > We have received the reply from the original reporter. > ----------------------------------------------------------------- > Reporter's reply (begins here) > ----------------------------------------------------------------- > I have confirmed that a new check has been added at the location > I reported. I'm aware that it is necessary to confirm the actual > behavior in the future, but I believe that the point I reported > have been addressed. > ----------------------------------------------------------------- > Reporter's reply (ends here) > ----------------------------------------------------------------- Thank you for the feedback. And also thank you for dealing with this. > The original reporter requested us to publish the advisory for this > issue on JVN <https://jvn.jp/en/, https://jvn.jp/> with CVE assigned to it. Yes, this is okay for us. In the patches I used your name as the reporter, because I wasn't aware that you were reporting on behalf of someone else. Is there any way we can give credit or would the reporter prefer to stay absolutely anonymous? > It is greatly appreciated if you could tell us the new version > release schedule (date and time) when it is determined. > We will publish JVN advisory > synchronizing with your release. We do not have a fixed schedule for the next release, yet. I would expect it to be released within four weeks from now. We just have the previous release coming out of the stabilising phase and will then move on to the next one. I will check with the release manager whether these fixes can still be brought into the current one. > If you have not already obtained CVE on your end, we will > assign CVE as a CNA (CVE Numbering Authority) for this > vulnerability. Please let us know if it has been assigned or not. No, we did not obtain a CVE. If you can, please assign one (or two?) for this. > Right now, we are creating the advisory draft. > Once it's written up, we will send it over to you for your review. Thank you.
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=7cb63527d96c4610171feb580c9fcd27c3af26b6 https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=ba4f53c56573d51be5e804f70965e82e5b271fd5
Since the bug fix is now public, I will make this bug report public, too. The fixes are supposed to be released either during the next week or if we find any other issues the week after. We would aim for the next week.
https://blog.ipfire.org/post/ipfire-2-27-core-update-170-is-available-for-testing
> In the patches I used your name as the reporter, because I wasn't aware that > you were reporting on behalf of someone else. Is there any way we can give > credit or would the reporter prefer to stay absolutely anonymous? The original reporter's name is "Satoshi Horikoshi". Please use only his name as the reporter in the patches. > No, we did not obtain a CVE. If you can, please assign one (or two?) for this. There are 2 XSSs pointed out, but if they have the same cause, assign 1 CVE, otherwise 2. Please let us know if the cause is the same or different. Thank you for your cooperation. We await for your reply.
(In reply to Noriko Totsuka from comment #10) > > In the patches I used your name as the reporter, because I wasn't aware that > > you were reporting on behalf of someone else. Is there any way we can give > > credit or would the reporter prefer to stay absolutely anonymous? > > The original reporter's name is "Satoshi Horikoshi". > Please use only his name as the reporter in the patches. Okay. > > No, we did not obtain a CVE. If you can, please assign one (or two?) for this. > > There are 2 XSSs pointed out, but if they have the same cause, assign 1 CVE, > otherwise 2. > Please let us know if the cause is the same or different. I believe one CVE should be enough. It is a problem of the same nature on both files.
https://blog.ipfire.org/post/ipfire-2-27-core-update-170-released
> IPFire 2.27 - Core Update 170 released Thank you for providing the new release information. We are preparing a JVN advisory for this issue. Please note that we have some national holidays till September 23. Therefore, the next contact is planned sometime during the week of September 26. We apologize for any inconvenience you may have and appreciate your understanding. Thank you for your cooperation.
Sorry for coming back to this bug again. But the patch for proxy.cgi/general-functions.pl isn't sufficient. validwildcarddomainname() extracts the domain name as follows # Ignore any leading dots if ($domainname =~ m/^\*\.(.*)/) { $domainname = $1; } The match slurbs all characters after '*.'. Wildcards usually are of the form '*.ipfire.org*' ( see example in proxy page ). Therefore the match should be $domainname =~ m/^\*\.([^\*]*)/ see also https://community.ipfire.org/t/proxy-cgi-error-message-when-use-wildcard-in-wpad-excluded-url-s/8597
Created attachment 1091 [details] JVN advisory draft The original xss vulnerabilities have been fixed in Core Update 170. Therefore,we are planning to publish the advisory with "CVE-2022-36368" assigned by JPCERT/CC on JVN (https://jvn.jp/en/, https://jvn.jp/) on October 6 (Thu) 12:00 JST(UTC/GMT+9hours). Please review the draft attached to this comment and return to us with any feedback/comments you may have by September 30 (Fri) 0:00 UTC. Thank you for your cooperation.
(In reply to Noriko Totsuka from comment #15) > Created attachment 1091 [details] > JVN advisory draft > > The original xss vulnerabilities have been fixed in Core Update 170. > Therefore,we are planning to publish the advisory with "CVE-2022-36368" > assigned by JPCERT/CC on JVN (https://jvn.jp/en/, https://jvn.jp/) on > October 6 (Thu) 12:00 JST(UTC/GMT+9hours). > Please review the draft attached to this comment and return to us with any > feedback/comments you may have by September 30 (Fri) 0:00 UTC. > > Thank you for your cooperation. Thank you for the document. The affected product is up to "IPFire 2.27 - Core Update 169". Core Update 170 already carries the patch and is therefore no longer affected. Further down below, I am not sure whether the document says that the user needs to be authenticated. In order to send the request, the attacker needs to have admin credentials to store any malicious content which will then be executed in another admin's browser. So I would say for CVSSv2 for "Authentication" it should say at least "Single"?
Created attachment 1093 [details] Updated JVN advisory draft Thank you for your comment about the JVN Advisory draft. > The affected product is up to "IPFire 2.27 - Core Update 169". Core Update 170 > already carries the patch and is therefore no longer affected. "IPFire versions prior to 2.27 - Core Update 170" means the same as up to "IPFire 2.27 - Core Update 169". In other words, before 170 is affected and 170 is unaffected. > Further down below, I am not sure whether the document says that the user needs > to be authenticated. In order to send the request, the attacker needs to have > admin credentials to store any malicious content which will then be executed in > another admin's browser. > > So I would say for CVSSv2 for "Authentication" it should say at least "Single"? We have changed "CVSS v2 Authentication" from "None" to "Single" and "CVSS v3 Privileges Required" from "Low" to "High". In addition, a supplementary explanation has been added in the "Comment" column. Thank you for your cooperation.
We apologize for the last minute change, but this is to let you know that CVSS v2 score was changed. Before: AV:N/AC:H/Au:S/C:N/I:P/A:N base score 2.1 After: AV:N/AC:M/Au:S/C:N/I:P/A:N base score 3.5 Through our review, we realized that the attacker does not need to guide the victim to a trap site since the issues are Stored XSS vulnerabilities. For this reason, we revised CVSS to "AC:M" and "cross-site scripting vulnerabilities" of the Description section to "stored cross-site scripting vulnerabilities". Thank you for your cooperation.
Please be informed that we published the JVN advisory for this issue. JVN#15411362 IPFire WebUI vulnerable to cross-site scripting https://jvn.jp/en/jp/JVN15411362/ (English) https://jvn.jp/jp/JVN15411362/ (Japanese) Thank you very much for all your help and support.
Thank you very much for your contribution. If you were to find anything in the future, please don't hesitate to open a new report.