Anyone packaging OCaml 4.04.0 or OCaml 4.04.1 and installing setuid binaries
with it should be aware of this CVE, and upgrade their distribution packaging
accordingly. Please get in touch with me if you are having any issues with
upgrading to the latest OCaml 4.04.2.
> Begin forwarded message:
> From: Damien Doligez <Damien.Doligez@...ia.fr>
> Subject: [Caml-list] OCaml release 4.04.2
> Date: 23 June 2017 at 16:18:44 BST
> To: caml announce <caml-announce@...ia.fr>, caml users <caml-list@...ia.fr>
> Reply-To: Damien Doligez <Damien.Doligez@...ia.fr>
> Dear OCaml users,
> We have the pleasure of celebrating the birthday of Alan Turing by
> announcing the release of OCaml version 4.04.2.
> This minor release fixes the security issue described in
> CVE-2017-9772 (included below).
> All users should eventually upgrade to 4.04.2 from 4.04.0 and 4.04.1.
> Any user who produces setuid programs with OCaml should read the CVE
> and upgrade immediately.
> It is available as an OPAM switch, or as a source download here:
> Happy hacking,
> -- Damien Doligez for the OCaml team.
> OCaml 4.04.2 (23 Jun 2017):
> ### Security fix:
> - PR#7557: Local privilege escalation issue with ocaml binaries.
> (Damien Doligez, report by Eric Milliken, review by Xavier Leroy)
> CVE-2017-9772: Privilege escalation in OCaml runtime for SUID executables
> The environment variables CAML_CPLUGINS, CAML_NATIVE_CPLUGINS, and
> CAML_BYTE_CPLUGINS can be used to auto-load code into any ocamlopt-compiled
> executable or any ocamlc-compiled executable in ‘custom runtime mode’.
> This can lead to privilege escalation if the executable is marked setuid.
> Vulnerable versions: OCaml 4.04.0 and 4.04.1
> - Upgrade to OCaml 4.04.2 or higher.
> or - Compile the OCaml distribution with the "-no-cplugins" configure option.
> or - OPAM users can "opam update && opam switch recompile 4.04.1", as
> the repository has had backported patches applied.
> Impact: This only affects binaries that have been installed on Unix-like
> operating systems (including Linux and macOS) with the setuid bit set.
> However, in that situation, any user who execute the program gains all
> the privileges of the owner of the executable (meaning that root-owned
> setuid executables provide root access).
> Fix: OCaml 4.04.2 mitigates this by modifying Sys.getenv and Unix.getenv
> to raise an exception if the process has ever had elevated privileges.
> The OCaml runtime has also been modified to use this function for
> retrieving all of the runtime environment variables which could potentially
> cause files to be accessed or modified. The older behaviour is available
> in Sys.unsafe_getenv for applications that require strict compatibility.
> Credits: This was originally reported by Eric Milliken on the OCaml Mantis
> bug tracker. https://caml.inria.fr/mantis/view.php?id=7557
> References: see CVE-2017-9779 for a lesser vulnerability in older versions.
> CVSS v2 Vector:
> CWE ID: 114
> Caml-list mailing list. Subscription management and archives:
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
4.04.2 is in tree and should be ready for being stabilized
I've checked my system for setuid binaries and found nothing built by ocaml but I might have missed some.
(In reply to Alexis Ballier from comment #1)
> I've checked my system for setuid binaries and found nothing built by ocaml
> but I might have missed some.
For the GLSA we would need at least a way to identify binaries built by ocaml...
please test and mark stable: =dev-lang/ocaml-4.04.2
(In reply to Thomas Deutschmann from comment #2)
> (In reply to Alexis Ballier from comment #1)
> > I've checked my system for setuid binaries and found nothing built by ocaml
> > but I might have missed some.
> For the GLSA we would need at least a way to identify binaries built by
Note: Everything built with ocaml must have := dep on it so will be rebuilt with latest version automatically.
Stable on alpha.
Arches, please finish stabilizing hppa
Gentoo Security Padawan
GLSA request opened.
This issue was resolved and addressed in
GLSA 201710-07 at https://security.gentoo.org/glsa/201710-07
by GLSA coordinator Aaron Bauman (b-man).