Bug 12925 - JVN#15411362 Inquiry on vulnerability found in IPFire
Summary: JVN#15411362 Inquiry on vulnerability found in IPFire
Status: CLOSED FIXED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: unspecified Unspecified
: - Unknown - Security
Assignee: Michael Tremer
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-09-06 05:56 UTC by Noriko Totsuka
Modified: 2022-10-06 09:07 UTC (History)
5 users (show)

See Also:


Attachments
the original report and the details of the reported vulnerability (2.22 KB, application/x-zip-compressed)
2022-09-06 05:56 UTC, Noriko Totsuka
Details
mail.cgi: Validate email recipient (2.08 KB, patch)
2022-09-06 12:18 UTC, Michael Tremer
Details
proxy.cgi: Correctly validate domain lists (3.30 KB, patch)
2022-09-06 12:19 UTC, Michael Tremer
Details
JVN advisory draft (47.98 KB, application/pdf)
2022-09-26 09:02 UTC, Noriko Totsuka
Details
Updated JVN advisory draft (43.46 KB, application/pdf)
2022-09-28 04:00 UTC, Noriko Totsuka
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Noriko Totsuka 2022-09-06 05:56:53 UTC
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/
Comment 1 Michael Tremer 2022-09-06 09:21:54 UTC
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.
Comment 2 Michael Tremer 2022-09-06 12:18:32 UTC
Created attachment 1084 [details]
mail.cgi: Validate email recipient
Comment 3 Michael Tremer 2022-09-06 12:19:28 UTC
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.
Comment 4 Noriko Totsuka 2022-09-07 01:58:49 UTC
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.
Comment 5 Noriko Totsuka 2022-09-08 09:02:31 UTC
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.
Comment 6 Michael Tremer 2022-09-08 10:16:20 UTC
(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.
Comment 8 Michael Tremer 2022-09-11 09:43:33 UTC
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.
Comment 10 Noriko Totsuka 2022-09-14 00:32:43 UTC
> 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.
Comment 11 Michael Tremer 2022-09-14 07:19:18 UTC
(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.
Comment 13 Noriko Totsuka 2022-09-16 09:30:02 UTC
>   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.
Comment 14 Bernhard Bitsch 2022-09-20 09:13:02 UTC
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
Comment 15 Noriko Totsuka 2022-09-26 09:02:14 UTC
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.
Comment 16 Michael Tremer 2022-09-26 09:53:17 UTC
(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"?
Comment 17 Noriko Totsuka 2022-09-28 04:00:07 UTC
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.
Comment 18 Noriko Totsuka 2022-10-03 02:12:08 UTC
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.
Comment 19 Noriko Totsuka 2022-10-06 03:05:29 UTC
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.
Comment 20 Michael Tremer 2022-10-06 09:07:27 UTC
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.