|Summary:||CVE-2014-3586 JBoss AS CLI: Insecure default permissions on history file|
|Product:||[Other] Security Response||Reporter:||Arun Babu Neelicattu <aneelica>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||unspecified||CC:||bdawidow, cdewolf, chazlett, dandread, darran.lofthouse, dereed, grocha, jason.greene, jawilson, jpallich, jrusnack, jshepherd, kejohnso, lgao, mweiler, myarboro, pgier, ppalaga, pslavice, rsvoboda, security-response-team, slaskawi, spinder, theute, tkirby, ttarrant, twalsh, vtunka|
|Fixed In Version:||Doc Type:||Bug Fix|
It was found that the Command Line Interface, as provided by Red Hat Enterprise Application Platform, created a history file named .jboss-cli-history in the user's home directory with insecure default file permissions. This could allow a malicious local user to gain information otherwise not accessible to them.
|Last Closed:||2019-06-08 02:34:11 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1126727, 1126728, 1126689, 1126693, 1126726, 1126729, 1126730, 1126732|
|Bug Blocks:||1196291, 1212496|
Description Arun Babu Neelicattu 2014-08-05 05:35:56 UTC
It was identified that the Command Line Interface, as provided by Red Hat Enterprise Application Platform and WildFly (previously JBoss Application Server), created a history file named .jboss-cli-history in the user's home directory with insecure default file permissions. This could allow a malicious local user to gain information otherwise not accessible.
Comment 4 Darran Lofthouse 2014-08-05 10:55:31 UTC
Within the server this class contains the approach previously used to set permissions on a folder: - https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/src/main/java/org/jboss/as/remoting/RealmSecurityProviderService.java A script based solution may be possible but we do need to keep in mind users can update the configuration to alter the location of the history so a script would only be based on the default location. Also to add to this upstream I have the following task to re-visit file system permissions using the APIs available to us in Java 7: - https://issues.jboss.org/browse/WFLY-431 I don't think now is the time but maybe for EAP 6 we can explore a 'if using Java 7 use new API, otherwise use Java6 approach'.
Comment 5 Arun Babu Neelicattu 2014-08-06 08:01:13 UTC
A solution that handles the default case (via script), tries to fix permissions (if using Java 7) and warns if configuration is modified and permissions are unable to be set (if using Java 6 or earlier) would be, in my opinion, considered a sufficient fix taking into account supported deployments.
Comment 8 Arun Babu Neelicattu 2014-09-23 12:49:28 UTC
Upstream Issue: https://issues.jboss.org/browse/WFCORE-120
Comment 18 Kurt Seifried 2015-02-26 19:44:21 UTC
I would like to propose unembargoing this issue public as it is low severity.
Comment 20 Chess Hazlett 2015-03-19 19:26:45 UTC
Comment 26 errata-xmlrpc 2015-04-16 15:39:13 UTC
This issue has been addressed in the following products: JBoss Enterprise Application Platform 6.4.0 Via RHSA-2015:0849 https://rhn.redhat.com/errata/RHSA-2015-0849.html
Comment 27 errata-xmlrpc 2015-04-16 16:25:11 UTC
This issue has been addressed in the following products: JBEAP 6.4.z for RHEL 6 Via RHSA-2015:0847 https://rhn.redhat.com/errata/RHSA-2015-0847.html
Comment 28 errata-xmlrpc 2015-04-16 16:31:11 UTC
This issue has been addressed in the following products: JBEAP 6.4.z for RHEL 5 Via RHSA-2015:0846 https://rhn.redhat.com/errata/RHSA-2015-0846.html
Comment 29 errata-xmlrpc 2015-04-16 16:33:16 UTC
This issue has been addressed in the following products: JBEAP 6.4.z for RHEL 7 Via RHSA-2015:0848 https://rhn.redhat.com/errata/RHSA-2015-0848.html
Comment 30 errata-xmlrpc 2015-05-14 15:22:11 UTC
This issue has been addressed in the following products: JBoss Portal 6.2.0 Via RHSA-2015:1009 https://rhn.redhat.com/errata/RHSA-2015-1009.html
Comment 31 Jason Shepherd 2015-11-04 22:30:43 UTC
This issue as been addressed in JON 3.3.4 via a rebase of EAP 6.4.3