Private key disclosure, Osirix (lite, 64bit and FDA cleader version) CVE-2013-4425 (version 1.09) CVSS Score: 8.4 Background: =========== OsiriX is an image processing software dedicated to DICOM images (files with a ".dcm" / ".DCM" extension) produced by imaging equipment (MRI, CT, PET, PET-CT, SPECT-CT, Ultrasounds) commonly used in medical settings. Certain versions are FDA or otherwise approved for clinical/medical use. The product is normally configured to connect to a Picture Archiving and Communication System (PACS) over the network; using protocols such as DICOM and the HTTP(s) based WADO. These connections are commonly secured with Transport Layer Security (TLS). OsiriX requires a public private key pair in order to do so (X509 certificate and corresponding private key). Required Environment: ===================== This advisory only applies to OsiriX installations which use TLS for securing their network connection in conjuction with a strong digital identity (e.g. a medical-care account, pass, medical-id). Vulnerability: ============== During startup of the DICOM listener the private key is extracted (from the generally well protected/encrypted keychain, chip-card or similarly), copied and then written to a file on the file system. Then it is perfunctory encrypted with a password that is hardcoded to 'SuperSecretPassword'. The resulting file (and the entire (directory) path) have read permissions which are totally open (user, group and other). This means that other users, daemons or subsystems on the same workstation as OsiriX, systems that have mounted/visibility of the path; or systems that are able to put a symbolic link in the path, can obtain the private key. Details: ======== The private and public key are extracted and written out as a temporary PKCS#12 file (through NSData writeToFile:). This file is then passed to the (hardcoded) path /usr/bin/openssl; where openssl its subcommand 'pkcs12' is used to split the file into a PEM encoded public and private key (fopen(2) with permissive O_NOFOLLOW, O_SYMLINK). The latter is perfunctory encrypted with 'SuperSecretPassword'. This password is visible in the binary and passed as a command line parameter (i.e. visible to 'ps(1)') during execution. The PKCS#12 is then removed. The various write operations honour things such as tilde expansion and (symbolic) links; thus allowing a fair degree of control for the attacker to re-position the file on a visible location (shared volume, a local webserver, a java(script)/browser visible location, an internet cache). Especially as the path itself is also writable for user, group and other. Impact: ======= Full disclosure of the users private key. And hence full negation of any and all privacy and authentication security measures of the TLS channel. The attacker can impersonate the user and/or decrypt (past) communications. As it is common in medical settions to use a single (personal) x509 certificate for enterprise/hospital wide authentication and privacy protection; the attacker will also gain access to all other systems thus protected. Work around or mitigation for existing installations: ===================================================== None (other than disabling the use of TLS/security). Solution: ========= Mitigate by Upgrading to version 5.8.2 or 2.5-MD. As per version 5.8/2.5-MD, vendor no longer uses the hardcoded 'SuperSecretPassword', but instead generates dynamic token which is held in in-process memory; and otherwise not saved directly. Therefore upgrading to U2.5-MD mitigates this issues. This is documented in the vendors release notes as: [MD-670] - CVE-2013-4425 : Private key disclosure, Osirix Note that this mitigation does not address subsequent security issues such as the VM paging these out, inter process memory visibility and so on). Furthermore, during execution of the /usr/bin/openssl command; the password is part of the command line and hence visible to tools such as 'ps(1)' to all users on the system. This fix has not yet been propagated to the unsupported open-source version; and no timeline for this is available at the time of this release. Versions affected: ================== All versions up to and including 5.7.1/2.7-MD The fix was introduced in version 5.8 and 2.8-MD. Vendor contact: Pixmeo SARL 266 Rue de Bernex CH-1233 Bernex Switzerland Caveats and Vendor certifications affected: =========================================== OsiriX MD is cleared as a 510k class II medical device, according to US Food And Drug Regulation CFR21 part 820 (http://www.accessdata.fda.gov/cdrh_docs/pdf10/K101342.pdf). OsiriX MD complies with European Directive 93/42/EEC concerning medical devices. Under this directive, it is regarded as a class IIa (CE-0029, Apra Gaz, Bruxelles, Belgium) product. Both these certifications set out requirements for (good) manufacturing practices. Therefore this mitigation may not fully resolve the issues when judged against normal industry best practices and/or regulatory requirements for private key handling in certain countries. This because the applied mitigation does still require the extraction of a private key to process memory; as opposed to making use of the normal OSX cryptographic primitives within a hardware/soft-token security sandbox. And it does expose the password of the keyfile as a command line argument (which is hard coded to the OS its own OpenSSL binary; which is well protected), albeit very very shortly. Timeline and disclosure: ======================== 2013-10-15 Issue confirmed, CVE issued, issue reported to vendor. 2013-10-16 Vendor response; will push out a fix as part of a planned release by/around mid December 2013. 2013-11-02 Vendor released 5.8, 2.8-MD 2013-11-06 First disclosure, version 1.09 Bibliographic References and classification: =========================================== @techreport{CVE-2013-4425, Number = {CVE-2013-4425}, Title = {Private key disclosure, Osirix (lite, 64bit and FDA cleader version)}, Author = {Dirk-Willem van Gulik}, Institution = {WebWeaving.org}, Month = {11}, Year = {2013}, Type = {Vulnerability Report, Responsible Full Disclosure}, Address = {Janvossensteeg 37, 2312WC, Leiden, Netherlands} } CVSSv2: AV:L/AC:L/Au:N/C:C/I:N/A:P/E:H/RL:U/RC:C/CDP:H/TD:H CVSS Base Score 7.2 Impact Subscore 10.0 Exploitability Subscore 3.9 CVSS Temporal Score 6.8 CVSS Environmental Score 8.4 Modified Impact Subscore 10.0 Overall CVSS Score 8.4 Credits: ======== Dirk-Willem van Gulik (dirkx (at) webweaving (dot) org) as part of the Artemis/EU project HighProfile (http://www.highprofile-project.eu/).