Bug 971637 (CVE-2013-3734) - CVE-2013-3734 Embedded Jopr: Datasource password visible to administrator
Summary: CVE-2013-3734 Embedded Jopr: Datasource password visible to administrator
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2013-3734
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-07 01:58 UTC by Arun Babu Neelicattu
Modified: 2019-09-29 13:05 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-22 09:36:47 UTC


Attachments (Terms of Use)

Description Arun Babu Neelicattu 2013-06-07 01:58:56 UTC
The datasource password is contained in the response received by an authenticated administraive user. If SSL is not configured/used, this password may be exposed on the wire.

Comment 1 Arun Babu Neelicattu 2013-06-07 02:39:52 UTC
Statement:

This issue is not a security flaw as, on its own, it does not cross a trust boundary in the system.  In order to access the datasource password, you must be logged in to jopr as an administrative user, that has permission to (among other things) execute code, deploy applications and reset the password in question.  The administrative user has the privileges to reset the password, hence, this does not expose any information that is not otherwise visible.

As administrative interfaces often display or allow the transmission of sensitive information, it is recommended best-practice that SSL is configured for the administrative console, regardless of this issue.

Comment 2 amroot 2013-06-10 14:13:40 UTC
I generally do not debate security for many reasons but there seems to be a misunderstanding here.

SSL is not the real problem. That is a side issue. Of course, if a company is not using SSL then it can be captured. Yes, encourage the use of SSL as a compensating control for that. Very good. However, as a vendor, all efforts should be made to ensure that the application and its data is secure, even in lieu of user configurations.

The bigger problem is that this allows an attacker to pivot and gain access to other systems NOT controlled or managed by JBoss. 
If console credentials are obtained through brute forcing or other means, the EXTERNAL database (SQL and alike) credentials are returned on the page. 

The database passwords are masked so it seems secure but if the attacker views the page source then the credentials can be obtained anyway. Why mask the password at all if it’s not sensitive? 

Imagine this (which really happened): 
1. An attacker gains access to the JBoss admin console. The ability to upload applications is disabled so not that big of a deal. 
2. The attacker views the data sources and the password is masked so again no big deal.
3. The attacker views the page source and finds the database password even though it’s hidden in number 2. 
4. The attacker then uses these credentials to dump the entire external database containing very sensitive client data.

In the above real life scenario if that password was not returned the attack would have stopped there and no real data would have been compromised. Masking the password is pointless if it is still returned in plaintext. Just don't return it at all.

Furthermore, best practices dictates that under no circumstances should password data be returned to the end-user, especially a plaintext password. A security in-depth approach would also consider other factors, such as a potential XSS vector which could allow a user to exploit an XSS flaw and retrieve the value from the DOM and alike. 

Reference: CVE-2013-3734: Password Returned in Later Response


Note You need to log in before you can comment on or make changes to this bug.