full-disclosure - [FD] Open-Xchange Security Advisory 2019-10-09

Open Source and information security mailing list archives

Message-ID: <1314469603.199.1570620177744@appsuite-dev-guard.open-xchange.com>
Date: Wed, 9 Oct 2019 13:22:57 +0200 (CEST)
From: Martin Heiland via Fulldisclosure <fulldisclosure@...lists.org>
To: "fulldisclosure@...lists.org" <fulldisclosure@...lists.org>
Subject: [FD] Open-Xchange Security Advisory 2019-10-09

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear subscribers,

we're sharing our latest advisory with you and like to thank everyone who contributed in finding and solving those vulnerabilities. Feel free to join our bug bounty programs (appsuite, dovecot, powerdns) at HackerOne.

Yours sincerely,
Martin Heiland, Open-Xchange GmbH

Product: OX App Suite
Vendor: OX Software GmbH

Internal reference: 66094 (Bug ID)
Vulnerability type: Server-Side Request Forgery (CWE-918)
Vulnerable version: 7.10.1 and 7.10.2
Vulnerable component: backend
Report confidence: Confirmed
Solution status: Fixed by Vendor
Fixed version: 7.10.0-rev33, 7.10.1-rev17, 7.10.2-rev9
Vendor notification: 2019-07-08
Solution date: 2019-08-09
Public disclosure: 2019-10-09
Researcher Credits: mantis
CVE reference: CVE-2019-14225
CVSS: 6.4 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:L)

Vulnerability Details:
The subscription mechanism for external iCal event sources follows HTTP redirection codes.

Risk:
Requests can be redirected to internal network targets if the attacker controls and injects redirect codes from the supposed iCal event source. Checking the content of the returned errors and their timing allows to gather information about internal network topology and services. This can be used as a reconnaissance pattern for further attacks.

Steps to reproduce:
1. Create a webservice that redirects HTTP requests to internal hosts
2. Configure that webservice as target of "external calendar" sources
3. Check response patterns when altering the redirection target

Solution:
We disabled HTTP redirection at the responsible HTTP client component.

---

Internal reference: 66081 (Bug ID)
Vulnerability type: Cross-site scripting (CWE-80)
Vulnerable version: 7.10.1 and 7.10.2
Vulnerable component: frontend
Report confidence: Confirmed
Solution status: Fixed by Vendor
Fixed version: 7.10.0-rev30, 7.10.1-rev16, 7.10.2-rev7
Vendor notification: 2019-07-08
Solution date: 2019-08-09
Public disclosure: 2019-10-09
Researcher Credits: Manas Gupta
CVE reference: CVE-2019-14227
CVSS: 5.4 (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N)

Vulnerability Details:
Calendar print view (for week, months) executes script code that is part of an appointments title.

Risk:
Malicious script code can be executed within a users context. This can lead to session hijacking or triggering unwanted actions via the web interface (sending mail, deleting data etc.). For this to work an attacker needs to inject a malicious appointment to the victims calendar first, for example through a seemingly legitimate calendar invite or by being part of the same context.

Steps to reproduce:
1. Create a appointment with script code fragments as title
2. Open "View" -> "Print" at a calendar view and cancel the native print dialog

Proof of concept:
<iframe/onMouseOver="document.location.href='https://example.com/ox.png'">

Solution:
We fixed the template engines escaping routines.

---

Internal reference: 66025 (Bug ID)
Vulnerability type: Cross-site scripting (CWE-80)
Vulnerable version: 7.10.1 and 7.10.2
Vulnerable component: frontend
Report confidence: Confirmed
Solution status: Fixed by Vendor
Fixed version: 7.10.1-rev16, 7.10.2-rev7
Vendor notification: 2019-07-04
Solution date: 2019-07-30
Public disclosure: 2019-10-09
Researcher Credits: Michael Medvedev
CVE reference: CVE-2019-14227
CVSS: 5.4 (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N)

Vulnerability Details:
Appointment dialogs contain a folder selector which is not properly escaping folder names.

Risk:
Malicious script code can be executed within a users context. This can lead to session hijacking or triggering unwanted actions via the web interface (sending mail, deleting data etc.). For this to work an attacker needs to modify a calendar folder within the same context or trick the user to do so.

Steps to reproduce:
1. Change a calendar folder to contain script code (or change the users name accordingly)
2. Edit or create a new appointment

Proof of concept:
ayb"><img src=x onerror=alert(document.domain)>

Solution:
We now escape folder names at this part of the dialog.

---

Internal reference: 65805 (Bug ID)
Vulnerability type: Information Exposure (CWE-200)
Vulnerable version: 7.10.2 and earlier
Vulnerable component: backend
Report confidence: Confirmed
Solution status: Fixed by Vendor
Fixed version: 7.8.4-rev60, 7.10.0-rev33, 7.10.1-rev17, 7.10.2-rev9
Vendor notification: 2019-06-24
Solution date: 2019-08-09
Public disclosure: 2019-10-09
Researcher Credits: hd7exploit
CVE reference: CVE-2019-14226
CVSS: 3.1 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N)

Vulnerability Details:
Information about external sharing URLs is provided to users that have non-administrative permissions to a folder.

Risk:
Other users could discover sharing links and use that to keep access to a folders content even though permissions has been revoked for them at a later point in time.

Steps to reproduce:
1. As User A, create a sharing link for a folder (e.g. Calendar) and invite internal User B with "Viewer" permissions
2. As User B, check the responses of "folder?action=get" for shared folders

Proof of concept:
The response contains a "share_url" parameter

Solution:
We removed the paramter from API responses for users that don't have access to modify it (administrative permissions).

---

Internal reference: 65799 (Bug ID)
Vulnerability type: Improper Access Control (CWE-284)
Vulnerable version: 7.10.2 and earlier
Vulnerable component: backend
Report confidence: Confirmed
Solution status: Fixed by Vendor
Fixed version: 7.8.4-rev60, 7.10.0-rev33, 7.10.1-rev17, 7.10.2-rev9
Vendor notification: 2019-06-24
Solution date: 2019-08-09
Public disclosure: 2019-10-09
Researcher Credits: hd7exploit
CVE reference: CVE-2019-14226
CVSS: 3.1 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N)

Vulnerability Details:
The attachment API allows to add attachments to tasks which are marked as "private" by their owner, in case the other user has permission to the task folder.

Risk:
Other users could unexpectedly add (malicious) content to tasks. Creators of those "private" tasks would not expect other users to be able to do so as those users are unable to access the task.

Steps to reproduce:
1. As User A, create "private" task and share the containing folder to User B
2. As User B, iterate through task IDs and try to attach files

Proof of concept:
The "attachment?action=attach" call allows to add attachments for tasks that are marked as "private" and not available to the user.

Solution:
We improved permission handling for the attachment API when dealing with "private" tasks.

---

Internal reference: 65722 (Bug ID)
Vulnerability type: Improper Access Control (CWE-284)
Vulnerable version: 7.10.1 and 7.10.2
Vulnerable component: backend
Report confidence: Confirmed
Solution status: Fixed by Vendor
Fixed version: 7.10.0-rev33, 7.10.1-rev17, 7.10.2-rev9
Vendor notification: 2019-06-18
Solution date: 2019-08-09
Public disclosure: 2019-10-09
Researcher Credits: hd7exploit
CVE reference: CVE-2019-14226
CVSS: 2.2 (CVSS:3.0/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N)

Vulnerability Details:
The API allows to change the visibility of appointments within shared folders, even though the user interface does not provide that option.

Risk:
Other users than the creator might change appointment visibility, which is unexpected. This is more of a cosmetical issue as it requires elevated permissions.

Steps to reproduce:
1. As User A, create an appointment and share the containing folder to User B with "author" permissions
2. As User B, modify the appointments visibility through API calls

Proof of concept:
Call "chronos?action=update" for an appointment created by User A and set the "class" parameter to "PRIVATE".

Solution:
We did adjust API handling to avoid other users than the creator of an appointment to modify its visibility.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives