exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

OsiriX Private Key Disclosure

OsiriX Private Key Disclosure
Posted Nov 6, 2013
Authored by Dirk-Willem van Gulik

OsiriX suffers from a private key disclosure vulnerability. All versions up to and including 5.7.1/2.7-MD are affected. The fix was introduced in version 5.8 and 2.8-MD.

tags | advisory, info disclosure
advisories | CVE-2013-4425
SHA-256 | a1aaad73f338f3e2622bef5fd13f44a5546ecc0c57fad091ab344b8aef7bfd21

OsiriX Private Key Disclosure

Change Mirror Download
Hash: SHA1

Private key disclosure, Osirix (lite, 64bit and FDA cleader version)

CVE-2013-4425 (version 1.09)
CVSS Score: 8.4


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


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.


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.


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


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

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

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

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:

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}


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

Dirk-Willem van Gulik (dirkx (at) webweaving (dot) org) as part of the
Artemis/EU project HighProfile (http://www.highprofile-project.eu/).

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.


Login or Register to add favorites

File Archive:

June 2023

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jun 1st
    18 Files
  • 2
    Jun 2nd
    13 Files
  • 3
    Jun 3rd
    0 Files
  • 4
    Jun 4th
    0 Files
  • 5
    Jun 5th
    32 Files
  • 6
    Jun 6th
    39 Files
  • 7
    Jun 7th
    22 Files
  • 8
    Jun 8th
    17 Files
  • 9
    Jun 9th
    0 Files
  • 10
    Jun 10th
    0 Files
  • 11
    Jun 11th
    0 Files
  • 12
    Jun 12th
    0 Files
  • 13
    Jun 13th
    0 Files
  • 14
    Jun 14th
    0 Files
  • 15
    Jun 15th
    0 Files
  • 16
    Jun 16th
    0 Files
  • 17
    Jun 17th
    0 Files
  • 18
    Jun 18th
    0 Files
  • 19
    Jun 19th
    0 Files
  • 20
    Jun 20th
    0 Files
  • 21
    Jun 21st
    0 Files
  • 22
    Jun 22nd
    0 Files
  • 23
    Jun 23rd
    0 Files
  • 24
    Jun 24th
    0 Files
  • 25
    Jun 25th
    0 Files
  • 26
    Jun 26th
    0 Files
  • 27
    Jun 27th
    0 Files
  • 28
    Jun 28th
    0 Files
  • 29
    Jun 29th
    0 Files
  • 30
    Jun 30th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Security Services
Hosting By