A security issue fixed in ocaml 4.03.0 was reported today (April 29): http://openwall.com/lists/oss-security/2016/04/29/1 The report says that fixing this requires recompiling all of the ocaml packages, so I don't know if it's reasonable to think that we could fix this in Mageia 5, but we certainly can address it in Cauldron.
For cauldron I would add the patch to our 4.02 as updating from 4.01 to 4.02 was painful and required some patching so 4.03 seems scary. https://github.com/ocaml/ocaml/commit/659615c7b100a89eafe6253e7a5b9d84d0e8df74#diff-a97df53e3ebc59bb457191b496c90762 Then we can rebuild everything easily. Rebuilding everything on Mageia 5 is not hard too but I don't expect QA to test everything... Maybe only the applications and not the libraries? That still include things like xen.
CVE assignment: http://openwall.com/lists/oss-security/2016/04/29/6
Summary: ocaml new security issue fixed in 4.03.0 => ocaml new security issue fixed in 4.03.0 (CVE-2015-8869)Whiteboard: (none) => MGA5TOO
Debian-LTS has issued an advisory for this on May 11: http://lwn.net/Alerts/687205/
URL: (none) => http://lwn.net/Vulnerabilities/687227/
I see the OpenSuSE update just used part of the upstream commit: https://build.opensuse.org/request/show/393716 Fedora has the whole commit, plus 19 other patches. Should we have any of those? http://pkgs.fedoraproject.org/cgit/rpms/ocaml.git/commit/?id=496d4e4eafb670e14a7f5605991b61ad0de894ea Pascal, could you add a fix for this in Cauldron and rebuild affected ocaml packages? I guess they wouldn't all be named ocaml-*, as the SuSE bug mentioned libguestfs.
Blocks: (none) => 19282
Fedora changes as just because of adding a patch changing xx/19 to xx/20 on all other patches I'll add the only needed one and rebuild them all
Status: NEW => ASSIGNED
Fixed in Cauldron by Pascal. Thanks! Probably all we can reasonably do in Mageia 5 is to add the patch to ocaml itself.
Whiteboard: MGA5TOO => (none)Version: Cauldron => 5
Not totally actually, as scilab didn't build due to some java problem :(
Would we be able to actually update ocaml to 4.03.0 like OpenBSD already did?
As nobody take care anymore of this package I think we can drop it and also scirenderer.
CC: (none) => geiger.david68210
Indeed, there are probably a bunch of packages we should drop due to maintainer abandonment.
SRPMS: ocaml-4.02.3-1.mga5
CC: (none) => mageiaAssignee: pterjan => qa-bugs
Advisory: ======================== Updated ocaml packages fix security vulnerability: OCaml before 4.03.0 does not properly handle sign extensions, which allows remote attackers to conduct buffer overflow attacks or obtain sensitive information as demonstrated by a long string to the String.copy function (CVE-2016-8869). Note that software affected by this needs to be rebuilt with the updated ocaml to fix this issue. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8869 http://lwn.net/Alerts/687205/ ======================== Updated packages in core/updates_testing: ======================== ocaml-4.02.3-1.mga5 ocaml-compiler-4.02.3-1.mga5 ocaml-doc-4.02.3-1.mga5 ocaml-x11-4.02.3-1.mga5 ocaml-sources-4.02.3-1.mga5 ocaml-compiler-libs-4.02.3-1.mga5 from ocaml-4.02.3-1.mga5.src.rpm
The Advisory above uploaded.
CC: (none) => lewyssmithWhiteboard: (none) => advisory
"OCaml is a general purpose programming language". Some background information; previous bugs are not helpful here. Project site: http://ocaml.org/ Tutorials: http://ocaml.org/learn/tutorials/ of which Basics: http://ocaml.org/learn/tutorials/basics.html looks promising for some primitive usage.
@lewis May I have a go at testing this? There is some kind of proof of concept for CVE-2015-8869 at http://www.openwall.com/lists/oss-security/2016/04/29/1 which looks worth following up. The basic tutorials you pointed out might be enough to demonstrate that ocaml works. Nobody wants to get involved in scilab!! And wikipedia does not mention ocaml in relation to scilab although urpmq --whatrequires lists it against ocaml.
CC: (none) => tarazed25
(In reply to Len Lawrence from comment #15) > May I have a go at testing this? Be my guest! > There is some kind of proof of concept for > CVE-2015-8869 at http://www.openwall.com/lists/oss-security/2016/04/29/1 > which looks worth following up. Well found! I had followed links, but there were a lot on the CVE site, and I tried a few in vain. Yours was the first... There are two PoC mini-scripts: buffer_ovflw.ml & infoleak.ml; + run commands to illustrate the faults. Well presented. > The basic tutorials you pointed out might be enough to demonstrate that > ocaml works. That was the idea - before you found the PoC. NOTE: the link given in Comment 15 says specifically "OCaml versions 4.02.3 and earlier have a runtime bug that, on 64-bit platforms..." so 32-bit testing might be redundant. Testing MGA5 x64 ---------------- BEFORE the update, I installed: ocaml-x11-4.01.0-11.mga5 ocaml-compiler-libs-4.01.0-11.mga5 ocaml-compiler-4.01.0-11.mga5 ocaml-4.01.0-11.mga5 $ ocamlopt buffer_ovflw.ml && ./a.out Segmentation fault [The given example cites "Segmentation fault: 11"] It took forever for the segmentation fault to happen, and the entire system was blocked during that. $ ocamlopt infoleak.ml && ./a.out aFatal error: exception Out_of_memory [The given example cites instead an output "a 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0"] Once again the ultimate failure took very long to appear, and the system was blocked during that. AFTER the update to: ocaml-compiler-libs-4.02.3-1.mga5 ocaml-compiler-4.02.3-1.mga5 ocaml-4.02.3-1.mga5 ocaml-x11-4.02.3-1.mga5 $ ocamlopt buffer_ovflw.ml && ./a.out File "buffer_ovflw.ml", line 4, characters 9-20: Warning 3: deprecated: String.copy Segmentation fault The time to the end failure was less; but the unchanged result demonstrates nothing. $ ocamlopt infoleak.ml && ./a.out File "infoleak.ml", line 3, characters 9-20: Warning 3: deprecated: String.copy aFatal error: exception Out_of_memory Here also the failure happened sooner - but with an unchanged result; which proves nothing. I do not know what to do about this. If Len could have a go (64-bit) to control my unhelpful findings, it is very quickly & easily done.
Re comment 16: @lewis; I was asking because it was not obvious that you were going to test this, or maybe youpburden - trying to avoid treading on toes. Yep, I'll do a control run. Disappointing that the result does not compare directly with the PoC post.
So far so good. I ran the compilation and testing separately. $ ocamlopt buffer_ovflw.ml $ ./a.out Segmentation fault $ ocamlopt infoleak.ml $ ./a.out a 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 The responses were immediate. Tried doing everything inline and saw the same results; i.e. $ ocamlopt buffer_ovflw.ml && ./a.out Hard to explain that unless there was some kind of transcription error. OK. On to the updates...
Updated the packages on x86_64. $ ocamlopt buffer_ovflw.ml && ./a.out File "buffer_ovflw.ml", line 4, characters 9-20: Warning 3: deprecated: String.copy Segmentation fault $ ocamlopt infoleak.ml && ./a.out File "infoleak.ml", line 3, characters 9-20: Warning 3: deprecated: String.copy a 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Like Lewis I don't know what to make of this other than the fact that ocaml is now aware there is something wrong with the test files. We can probably ignore the Warning messages. @lewis: Did you install ocaml-sources - not sure if they are necessary but maybe that has something to do with your results? I shall go back to the original link and also look to the tutorials for enlightenment.
Examining the scripts again this becomes more opaque. The warnings come as two lines which identify the use of a deprecated function so it is not obvious that any damage is being prevented. From the link in comment 15; OCaml applications, compiled with OCaml 4.02.3 or earlier on a 64-bit platform, that apply the defective copy functions to untrusted inputs are at risk. These applications should be recompiled with OCaml 4.03.0. And note comments 8 and 9 regarding version 4.03.0. It looks like a dead end. Feedback?
Or is 4.02.3-1 equivalent to 4.03.0?
[root@x3 ~]# rpm -qa|grep ocaml ocaml-compiler-4.01.0-11.mga5 [root@x3 ~]# urpmi ocaml-compiler Some requested packages cannot be installed: camlp5-6.11-5.mga5.x86_64 (due to unsatisfied ocaml(Stream)[== 932d0bd7bd881dd54cdaabdd1ca8062b]) ocaml-compiler-4.01.0-11.mga5.i586 (due to conflicts with ocaml-compiler-4.02.3-1.mga5.x86_64, due to conflicts with ocaml-compiler-4.02.3-1.mga5.x86_64, due to conflicts with ocaml-compiler-4.02.3-1.mga5.x86_64, due to conflicts with ocaml-compiler-4.02.3-1.mga5.x86_64, due to conflicts with ocaml-compiler-4.02.3-1.mga5.x86_64, trying to promote ocaml(Array), ocaml(Buffer), ocaml(Dynlink), ocaml(Unix), ocaml(Str)) ocaml-compiler-4.01.0-11.mga5.x86_64 (due to conflicts with ocaml-compiler-4.02.3-1.mga5.x86_64, due to conflicts with ocaml-compiler-4.02.3-1.mga5.x86_64, due to conflicts with ocaml-compiler-4.02.3-1.mga5.x86_64, due to conflicts with ocaml-compiler-4.02.3-1.mga5.x86_64, due to conflicts with ocaml-compiler-4.02.3-1.mga5.x86_64, trying to promote ocaml(Array), ocaml(Buffer), ocaml(Dynlink), ocaml(Unix), ocaml(Str)) ocaml-compiler-libs-4.01.0-11.mga5.x86_64 (due to unsatisfied ocaml-compiler[== 4.01.0]) ocaml-ftp-0.1.0-8.mga5.i586 (due to unsatisfied ocaml(Printexc)[== d81cbca604b811d25138fa79499fe071]) ocaml-obrowser-1.1.1-8.mga5.i586 (due to conflicts with ocaml-text-0.6-8.mga5.x86_64, due to conflicts with ocaml-text-0.6-8.mga5.x86_64, due to conflicts with ocaml-text-0.6-8.mga5.x86_64, trying to promote ocaml(Dynlink), ocaml(Unix), ocaml(Str)) ocaml-obrowser-1.1.1-8.mga5.x86_64 (due to conflicts with ocaml-compiler-libs-4.01.0-11.mga5.x86_64, due to conflicts with ocaml-compiler-libs-4.01.0-11.mga5.x86_64, due to conflicts with ocaml-compiler-libs-4.01.0-11.mga5.x86_64, trying to promote ocaml(Dynlink), ocaml(Unix), ocaml(Str)) ocaml-text-0.6-8.mga5.x86_64 (due to unsatisfied ocaml(Printf)[== d012329cc712e91d0f10a5eef2303d18]) Suggestions?
CC: (none) => davidwhodgins
With the updated version of ocaml in place: # rpm -qa | grep ocaml ocaml-compiler-libs-4.02.3-1.mga5 ocaml-x11-4.02.3-1.mga5 ocaml-4.02.3-1.mga5 ocaml-sources-4.02.3-1.mga5 ocaml-compiler-4.02.3-1.mga5 ocaml-doc-4.02.3-1.mga5 # urpmi ocaml-compiler A requested package cannot be installed: ocaml-compiler-4.01.0-11.mga5.x86_64 (in order to keep ocaml-compiler-4.02.3-1.mga5.x86_64) Continue installation anyway? (Y/n) n As expected. The original packages were installed individually without any problems but one of them was pulled in - cannot remember which. Maybe Lewis kept notes.
Adding feedback marker due to conflicts installing the updates.
Whiteboard: advisory => advisory feedback
And perhaps because the update does not cure the PoC.
It looks like we may need to recompile some ocaml packages to fix the dependency issues. As for it not curing the PoC, you need to recompile it with the updated ocaml.
CC: (none) => pterjanAssignee: qa-bugs => mageia
CC: (none) => qa-bugs
Keywords: (none) => advisory, feedbackWhiteboard: advisory feedback => (none)
I don't suppose anyone actually uses this, outside of scilab. We weren't able to fix it.
Resolution: (none) => OLDStatus: ASSIGNED => RESOLVED