-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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/).


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (Darwin)
Comment: This message is encrypted and/or signed with PGP (gnu-pg, gpg). Contact dirkx@webweaving.org if you cannot read it.

iQCVAwUBUnpH2TGmPZbsFAuBAQKpjQP/V+pNz+Voh4lBglSO0QxYyHJEHQaloMyS
nwY3+ASclKaztCjxC6RKgCSvdtFTqxABeRVs7edhmdbAIRDevXC+4mYwXb6cVWbX
jKZ6jBrXoa1rhjJjnBhw919J+PlYsyazgTyY/4yXPHKlOnBaVFt5L2LiQB/cS747
M6YlYpunJQI=
=7jdT
-----END PGP SIGNATURE-----