Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Adrien Nader <adrien@notk.org>
To: caml-list@inria.fr
Subject: [Caml-list] [cve-assign@mitre.org] [oss-security] Re: buffer overflow and information leak in OCaml < 4.03.0
Date: Fri, 29 Apr 2016 18:46:13 +0200	[thread overview]
Message-ID: <20160429164613.GB24608@notk.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 126 bytes --]

This is probably of interest to the list.

PS: no credit goes to me, I'm merely subscribed to oss-security@

-- 
Adrien Nader

[-- Attachment #2: Type: message/rfc822, Size: 4024 bytes --]

From: cve-assign@mitre.org
To: cuoq@trust-in-soft.com
Cc: cve-assign@mitre.org, oss-security@lists.openwall.com
Subject: [oss-security] Re: buffer overflow and information leak in OCaml < 4.03.0
Date: Fri, 29 Apr 2016 10:49:11 -0400 (EDT)
Message-ID: <20160429144911.5DD178BC4E6@smtpvmsrv1.mitre.org>

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

> OCaml versions 4.02.3 and earlier have a runtime bug that, on 64-bit
> platforms, causes sizes arguments to an internal memmove call to be
> sign-extended from 32 to 64-bits before being passed to the memmove
> function.
> 
> This leads arguments between 2GiB and 4GiB to be interpreted as larger
> than they are (specifically, a bit below 2^64), causing a buffer
> overflow.
> 
> Arguments between 4GiB and 6GiB are interpreted as 4GiB smaller than
> they should be, causing a possible information leak.
> 
> This commit fixes the bug:
> https://github.com/ocaml/ocaml/commit/659615c7b100a89eafe6253e7a5b9d84d0e8df74#diff-a97df53e3ebc59bb457191b496c90762
> The function caml_bit_string is called indirectly from such functions
> as String.copy. String.copy for instance is supposed to be a "safe"
> function for which OCaml's memory safety guarantees apply.

Use CVE-2015-8869.

(We consider this a single "to be sign-extended from 32 to 64" issue
even though there are two different types of impacts. Also, the
structure of the code change ("Int_val" replaced by "Long_val") is the
same everywhere. We did not consider it worthwhile to sort through the
possible "independently encountered" aspects as mentioned, for
example, in the
https://github.com/ocaml/ocaml/commit/659615c7b100a89eafe6253e7a5b9d84d0e8df74#commitcomment-14040616
comment.)

- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at
  http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJXI3NXAAoJEHb/MwWLVhi2RdEQAI71I2vgUNPxtIPV5muuzuT/
BGlgZLTiWI6HgmFvV7mRtNonvKockAP150f7cArfGgsG13DVViE45IYCk4WHacnW
aTfRtbPYBZ+eawApm1tWmSxXi4Idt2sSBPXxnA46vwKUZo3oDG8p0oxEanZ1O1Y6
v+zAL4vVNq+IdSnpPzwM368C/gc1KDBM0uLu7qVoV6E2qHriWXpWpEZ7MGqab5Dv
2/8ZhpdAnZDVzMSzGbKY+h1k1JjwWnIx3WmWzU65JKF3ccDtLyWy+LaRT5D63d/K
f5orQDKfJyxc9UQIa+TH4waYQZ64f1xb5haTZaQv8tJVxlwVKD0vVk/eVrlN/r1e
XXbtknwlMcWLf30hKqzOcDwAfWf2rPtUk5h6PotFVR42esLTTDg7BlIjYFilBXw0
AlVyDrZ4cBlnd3ZeeyJW2moEoErRlnYFrqdijjIBmHPokoPVAOUcfcU2saBfkFqP
suYLBcMHrpvitrr4V5yu5T2ZYZI9DtEse+z3Oe+wupCemyfoXXcGvX7Kwz0j4oIk
bFDuuKtNpo4do+2JkCwbczGwIGAyW20rBbyJqkMMGI1c3VlY/rzn8hES3ltKjVND
1WShu2c9wwyIhhYUKuacdx8RvuZinNBAlmkWdpNUI33XsVXmdRiEhjB+RGyvqv/X
a2JgvU+8pOLRMJsRX7CA
=BBAV
-----END PGP SIGNATURE-----

                 reply	other threads:[~2016-04-29 16:46 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160429164613.GB24608@notk.org \
    --to=adrien@notk.org \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox