Glassfish cross-side scripting in instanceName

Basic information

Project name: Glassfish

What are the affected versions?

7.0.15

Details of the issue

Summary: In Eclipse GlassFish version 7.0.15 is possible to perform Reflected Cross-site scripting attacks. Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request that, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.

• Prerequisites: The victim must be authenticated within the Administration Console.

Step-by-step instructions and PoC

An unauthenticated remote attacker can create a malicious link that, if it is delivered to the victim (e.g., phishing), can cause JavaScript code execution in the victim's browser and supply some information to the attacker or run arbitrary HTTP Request in the context of victim's session.

Affected Endpoints • URL: https://[IP]:[PORT]/shared/instanceStatus.jsf • HTTP GET Parameter: instanceName

Below there is the evidence with the vulnerability details and the payloads used. Payload used to exploit the vulnerability: https://[IP]:[PORT]/shared/instanceStatus.jsf?instanceName=%22%20id=%22x%22%2 0tabindex=%221%22%20onfocus=%22alert(1)%22%20autofocus=%22

Security Impact

An attacker can exploit this vulnerability to extract some information or run arbitrary HTTP Request in the context of victim's session.

Remediation Steps

In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defences:

• Input should be validated as strictly as possible on arrival, given the kind of content that it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
• User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).

In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task. (How one can reproduce the issue - this is very important)

assigned to @hsawamura, @smillidge, @mbarbero, and @mrybczyn

made the issue visible to everyone

assigned to @redteamtim

made the issue confidential

@hsawamura @smillidge please have a look at this one. @redteamtim is the reporter and they can provide more information if needed

Reported: July 15, 2024

made the issue visible to everyone

assigned to @dmisingname3q2

made the issue confidential

Thank you for reporting.

This issue doesn't appear to be as dangerous as XSS, and would likely be considered a CSRF vulnerability (GET request only). IMO, it should be addressed in the future, but it's not considered a high priority.

Hi team, this is a typical reflected XSS scenario where clicking on a link results in executing malicious JavaScript in the victim's browser. In any case, could you tell us the estimated patch date? As Eclipse Foundation CNA, can you proceed with the reservation of the CVE-ID? Thank you for collaboration and Best Regards.

Hi @hsawamura, @smillidge, we would like to know whether you have any update about our reservation CVE Id request asked before. Is it possible to proceed? Thank you for cooperation and Best Regards.

Hi team and @mrybczyn, considering the mix-up created through the issue #232 (closed) about the CVE and since you are a CNA, therefore you are responsible for reservation request of CVE IDs and their management, may you keep us up to date regarding this issue please? May you reserve the CVE ID for it and trasmit it to us, please? Thank you and kind regards

Eclipse GlassFish typically requests CVE assignment upon the release of a version containing the fix. As an open-source project with publicly available source code, anyone can contribute fixes and improvements. We welcome your contributions for a swift resolution.

Hi team and @mrybczyn, According to your handbook about the CVEs management (https://www.eclipse.org/projects/handbook/#vulnerability-cve) the procedure is different: The first point of paragraph "General Case" (https://www.eclipse.org/projects/handbook/#general-case), that is called "Request the number", and we quote it "When you know that there is a security issue (the fix is not yet needed at this point), go to the CVE Request form and fill it. Make sure to keep the issue confidential for now. If you want to make the issue visible to multiple project members, add them as assignees when creating the ticket (it will be hard later on)." So you may proceed to require the CVE before you fix the flaws. Then, when the patch is ready, you can publish the CVE, as reported in your handbook in the point "Ask for publication of the issue".

So at this point may you reserve the CVE, please?

Hi team and @mrybczyn, is it possible to reserve the CVE-ID for this issue, please?

@redteamtim, thank you for your patience. We will get back to you early next week.

added vulnerabilityconfirmed label

@hsawamura @smillidge @dmisingname3q2 we will need a little bit of information from you. Please look at the similar issues and tell us if they all come from the same code or not. If it is the same code, we assign a single CVE ID for all situation caused by the same code. If you an fix each of those entries separately, we allocate separate CVEs.

@mrybczyn at first look they are subtly different. Some require access to the file system on the machine by the attacker. Another requires an authenticated admin user to store some malicious data for another admin user to execute later and a third requires an admin user to click on a malicious link. @hsawamura @dmisingname3q2 what is your analysis?

I agree. This would require either pre-populating malicious parameters using OS or GlassFish administrator privileges before displaying the screen to the admin user, or tricking the admin user into clicking a URL containing a malicious query parameter.

I believe the most practical countermeasure against a compromise of administrative privileges on the application server is to strongly recommend the following policies to users:

• Do not run GlassFish with root privileges.
• Change the admin port from its default.
• Do not expose the admin port to the internet.
• Do not touch other interfaces while logged into GlassFish.
• Always log out from GlassFish after completing operations.

Some of the above are already documented in the GlassFish security guide. https://glassfish.org/docs/latest/security-guide.html#securing-the-glassfish-server-host

@hsawamura could you please add the needed additions to your plan?

Hi @mrybczyn since the technical team's answer, could you tell us whether you will published the CVEs and may you tell us the relative IDs, please? thank you

@redteamtim as they look as separate vulnerabilities, we'll go for separate assignments. We'll create appropriate issues

An assignment has been created for this one see https://gitlab.eclipse.org/security/cve-assignement/-/issues/40

added cvereserved label

added statusawaiting_release label

Hi team, we would like to know if you have a release date for this vulnerability. Thank you and regards

Gentle ping @hsawamura @smillidge @dmisingname3q2. The researcher would like to have an update on their report. It has been already almost 4 months since they reported it. Thanks!

assigned to @atijmse7y

assigned to @omihalyi

assigned to @avpinchuk

assigned to @pygieo

assigned to @kaido207

@atijmse7y @omihalyi @avpinchuk @pygieo @kaido207, please have a look if you can assist in resolving this issue. Please note that this is a GitLab confidential issue and you need to be logged in to see it. Otherwise you will get a 404.

Hi team, we would like to know if you have any news for this vulnerability. Thank you and regards

Hi team, we would like to know if you have any news for this vulnerability. Thank you and regards

Hi @mrybczyn @mbarbero, could you help us to known if you have a release date for this vulnerability? Thank you and regards

@redteamtim we're working on it

Hi team, we would like to know if you have a release date for this vulnerability. Thank you and regards

Hi , we would like to know if you have any news about the release date for the fix. Thank you and best regards.

Greetings @redteamtim , many thanks for reporting!
We're making this issue public since it has passed number of days expected for responsible vulnerability disclosure.
The mitigation on this issue is expected to happen in the future.
Currently the Glassfish committers have a considerable workload on their hands and since this vulnerability requires access to the Administration Console, it has been considered there are greater risks coming from a malicious actor with that type of access.

made the issue visible to everyone

Hi @tiagolucas, thanks for your feedback. We would like to know when you will publish the CVE on MITRE about this issue, since you have published it here. Thank you and regards