Bugzilla – Bug 667077
VUL-0: Moonlight Multiple Vulnerabilities
Last modified: 2011-04-28 11:51:57 UTC
Three issues in the Mono runtime has been reported by Jeroen Frijters. The issues wont cause harm (with Mono itself) unless executing untrusted code (which only Moonlight does). The fact that these issues could be exploited in Moonlight is *not* public. IIRC our next Moonlight release (beta) is planned for February 11th. We could release an update to (stable) Moonlight 2.3 at the same time. Note: Moonlight 1.x does not execute managed code (i.e. does not include Mono) so it is not affected by this vulnerability.
The three issues are: 1) Calling RuntimeHelpers.InitializeArray on non-primitive types Status: fixed in GIT https://github.com/mono/mono/commit/035c8587c0d8d307e45f1b7171a0d337bb451f1e 2) Race in Array.Copy "FastCopy" Status: fixed in GIT https://github.com/mono/mono/commit/2f00e4bbb2137130845afb1b2a1e678552fc8e5c 3) DynamicMethod resurrection Status: unfixed (c.c. rkumpera@novell.com) https://bugzilla.novell.com/show_bug.cgi?id=660422 Credits: Jeroen Frijters, http://www.ikvm.net/
p5->p3 mass change
Pardon my ignorance, I have a hard time understanding the issues. In order to determine how many CVE numbers we need, we need to know whether we can group the bugs. So I'd like to understand what's going on here. (In reply to comment #1) > 1) Calling RuntimeHelpers.InitializeArray on non-primitive types This seems to memcpy one array to another. How could that be exploited? > 2) Race in Array.Copy "FastCopy" Is the race here that malicious code could shrink the target array while it's beeing copied? > 3) DynamicMethod resurrection That's all greek to me. It's possible to call a method after the garbage collector has freed the memory? ie use-after-free?
Ok, here's how *I* see them. Pretty sure someone with more (or a black'er) imagination would have even more fun with them ;-) >> 1) Calling RuntimeHelpers.InitializeArray on non-primitive types > > This seems to memcpy one array to another. Yes. The API [1] copy from the (potentially user provided) assembly metadata (i.e. the runtime field handle) into an application/user array. > How could that be exploited? Before the fix the API [2] allowed to copy into (and array of) non reference value-types (e.g. structs in C#). The value-type members can be private (not user modifiable under CoreCLR, Moonlight's sandbox) and the content can be used, later, in security-critical operations. Moonlight's policy code and it's safe critical API (limiting/blocking access to critical/native API) depends on various value-types - and the fact that they are not user-modifiable. [1] http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.runtimehelpers.initializearray%28v=VS.95%29.aspx [2] This method is marked [SecuritySafeCritical] which means it's executable from user/application code. >> 2) Race in Array.Copy "FastCopy" > > Is the race here that malicious code could shrink the target array > while it's beeing copied? The element type check and copy actions were done in separate loops when copying objects into a value-type array. Another thread could change an item, after the type check, and the FastCopy would copy the data into the output array. That case would lead situations similar to #1. >> 3) DynamicMethod resurrection > > That's all greek to me. It's possible to call a method after the > garbage collector has freed the memory? ie use-after-free? That's my understanding, i.e. DynamicMethod -> Finalize -> Free -> Resurrect -> Use (after free) Rodrigo please correct me if I'm wrong. 4) Improper thread finalization We'll also add a fix for bug #678515. It's comment #5 describe the issue (minor IMO).
CVE-2011-0989: modification of read-only values via RuntimeHelpers.InitializeArray CVE-2011-0990: buffer overflow due to race condition in in Array.FastCopy CVE-2011-0991: use-after-free due to DynamicMethod resurrection CVE-2011-0992: information leak due to improper thread finalization
our 2.4.1 update is out and 3.99.3 will be soon... CVE-2011-0989: modification of read-only values via RuntimeHelpers.InitializeArray https://github.com/mono/mono/commit/035c8587c0d8d307e45f1b7171a0d337bb451f1e CVE-2011-0990: buffer overflow due to race condition in in Array.FastCopy https://github.com/mono/mono/commit/2f00e4bbb2137130845afb1b2a1e678552fc8e5c CVE-2011-0991: use-after-free due to DynamicMethod resurrection https://github.com/mono/mono/commit/8eb1189099e02372fd45ca1c67230eccf1edddc0 https://github.com/mono/mono/commit/89d1455a80ef13cddee5d79ec00c06055da3085c CVE-2011-0992: information leak due to improper thread finalization https://github.com/mono/mono/commit/722f9890f09aadfc37ae479e7d946d5fc5ef7b91 p.s. mono's wiki has been updated too
Update released for: libmoon-devel, libmoon0, moonlight, moonlight-debuginfo, moonlight-debugsource, moonlight-desktop, moonlight-desktop-devel, moonlight-plugin, moonlight-tools, moonlight-web-devel Products: SLE-DEBUGINFO 11-SP1 (i386, x86_64) SLE-DESKTOP 11-SP1 (i386, x86_64)
11.3: sr#66385 11.4: sr#66386
Update released for: libmoon-devel, libmoon0, libmoon0-debuginfo, moonlight, moonlight-debugsource, moonlight-desktop, moonlight-desktop-devel, moonlight-plugin, moonlight-plugin-debuginfo, moonlight-tools, moonlight-web-devel Products: openSUSE 11.3 (debug, i586, x86_64) openSUSE 11.4 (debug, i586, x86_64)
released
Could these fixes also be submitted to openSUSE:Factory and Mono:Factory, please? Even if Factory is the development version that doesn't means we actively keep it unsafe! And Packman links from Mono:Factory to create multimedia enabled builds (since it's the first time ever I have seen an update not being submitted to the devel project). Also, probably the moonlight version in the Mono project (not in Mono:Factory) should be updated (currently 2.3) or deleted?
This is an autogenerated message for OBS integration: This bug (667077) was mentioned in https://build.opensuse.org/request/show/66385 https://build.opensuse.org/request/show/66386 https://build.opensuse.org/request/show/66873