Open-Xchange AppSuite versions 7.10.1 and below suffer from information exposure and improper access control vulnerabilities.
49339a0d35cc917c045e135d1d0cc7bfProduct: OX App Suite
Vendor: OX Software GmbH
Internal reference: 61771 (Bug ID)
Vulnerability type: Information Exposure (CWE-200)
Vulnerable version: 7.10.1 and earlier
Vulnerable component: backend
Report confidence: Confirmed
Solution status: Fixed by Vendor
Fixed Version: 7.6.3-rev44, 7.8.3-rev53, 7.8.4-rev51, 7.10.0-rev25, 7.10.1-rev7
Vendor notification: 2018-11-23
Solution date: 2019-02-13
Public disclosure: 2019-04-01
CVE reference: CVE-2019-7159
CVSS: 4.1 (CVSS:3.0/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N)
Vulnerability Details:
The "oxsysreport" tool failed to sanitized custom configuration parameters that could contain credentials like API keys.
Risk:
Unintended configuration information has been collected and potentially sent to OX for further analysis. This transmission would happen through secure channels and to authorized personell. We have no indication that data was used illegitimately.
Steps to reproduce:
1. Have configuration properties that don't match the expected format (e.g. commented out, custom key format)
2. Run oxsysreport and check what parameters have been sanitized
Solution:
We made sure to remove all incorrectly collected information and removed backups thereof. To solve the root cause, the oxsysreport tool has been updated to deal with other patterns of properties.
---
Internal reference: 61315 (Bug ID)
Vulnerability type: Improper Access Control (CWE-284)
Vulnerable version: 7.10.1 and earlier
Vulnerable component: backend
Report confidence: Confirmed
Solution status: Fixed by Vendor
Fixed Version: 7.8.3-rev53, 7.8.4-rev51, 7.10.0-rev25, 7.10.1-rev7
Vendor notification: 2018-11-06
Solution date: 2019-02-13
Public disclosure: 2019-04-01
CVE reference: CVE-2019-7158
CVSS: 4.2 (CVSS:3.0/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N)
Vulnerability Details:
In case users did chose not to "stay signed in" or the operator disabled that functionality, cookies are maintained for a "session" lifetime to make sure they expire after the browser session has ended. Using "reload" on the existing browser session led to the impression that the session is already terminated as the login screen would be shown afterwards. However, those cookies are maintained by the browser for the remainder of the session until termination of the browser tab or window.
Risk:
Users could get the incorrect impression that their session has been terminated after reloading the browser window. In fact, the credentials for authentication (cookies) were maintained and other users with physical access to the browser could re-use them to execute API calls and access other users data.
Steps to reproduce:
1. Login with "Stay signed in" disabled
2. Reload the browser
3. Check which cookies are maintained while the "login" page is displayed
Solution:
We now drop the session associated with existent secret cookie on server-side in case a new login is performed and thus a new secret cookie is about to be written.