Forwarded from mail: This email is a confidential pre-notification for multiple security alerts for Subversion clients and servers: * CVE-2015-5259 Heap overflow and out-of-bounds read in svn:// protocol parser * CVE-2015-5343 Heap overflow and out-of-bounds read in mod_dav_svn Please *do not forward* any part of this mail to anyone. The public announcement is not until 15 December 2015, and we'd like to keep the information embargoed until the announcement. You are receiving this mail because (we think) you distribute software that uses the Subversion libraries or that you host a Subversion installation used by a large number of users. We believe that you might want to have your software patched by the time this security hole is made public on 15 December. If you no longer maintain Subversion-related packages or hosting, please reply to this mail indicating who the appropriate contact would be for your organization. Below are the advisories, followed by patches to fix the problems. The patches apply to Subversion 1.8.14 and 1.9.2. Subversion 1.8.15 and 1.9.3 will be published on 15 December, including the attached patches, as well as other stability and bug fixes. The full advisories and patches are attached. CVE-2015-5259-advisory.txt: Remotely triggerable heap overflow and out-of-bounds read caused by integer overflow in the svn:// protocol parser. Summary: ======== Subversion servers and clients are vulnerable to a remotely triggerable heap-based buffer overflow and out-of-bounds read caused by an integer overflow in the svn:// protocol parser. This allows remote attackers to cause a denial of service or possibly execute arbitrary code under the context of the targeted process. Known vulnerable: ================= Subversion 1.9.0 through 1.9.2 (inclusive) Only servers and clients using svn:// protocol are vulnerable Subversion httpd servers and clients (any version) are not vulnerable Known fixed: ============ Subversion 1.9.3 Details: ======== The svnserve svn:// protocol strings are sent as a length followed by the string data. The protocol parsing logic contains a flaw that allows an attacker to write memory past the end of a heap buffer with a specially crafted request that causes an arithmetic overflow. Since the flaw is in the parsing of the protocol, exploiting this vulnerability against an svnserve server does not require authentication from the remote attacker. The parsing code with the flaw is shared by both the svnserve server and clients using the svn://, svn+ssh:// and other tunneled svn+*:// methods. Severity: ========= CVSSv2 Base Score: 9 CVSSv2 Base Vector: AV:N/AC:L/Au:N/C:P/I:P/A:C We consider this to be a high risk vulnerability. An exploit exists and has been tested to work against this vulnerability. The denial of service attack is reasonably easy to carry out, while exploiting the heap overflow is more difficult, depending upon how skilled the attacker is and upon the specifics of the platform. We do not believe the exploit is being actively used in the wild at this time. Recommendations: ================ We recommend all users of Subversion 1.9.x to upgrade to Subversion 1.9.3. Users of Subversion 1.9.x who are unable to upgrade may apply the included patch. New Subversion packages can be found at: http://subversion.apache.org/packages.html No workaround is available. References: =========== CVE-2015-5259 (Subversion) Reported by: ============ Ivan Zhakov, VisualSVN CVE-2015-5343-advisory.txt: Remotely triggerable heap overflow and out-of-bounds read in mod_dav_svn caused by integer overflow when parsing skel-encoded request bodies. Summary: ======== Subversion's httpd servers are vulnerable to a remotely triggerable heap-based buffer overflow and out-of-bounds read caused by an integer overflow when parsing skel-encoded request bodies. This allows remote attackers with write access to a repository to cause a denial of service or possibly execute arbitrary code under the context of the httpd process. 32-bit server versions are vulnerable to both the denial-of-service attack and possible arbitrary code execution. 64-bit server versions are only vulnerable to the denial-of-service attack. Known vulnerable: ================= Subversion httpd servers 1.7.0 to 1.8.14 (inclusive) Subversion httpd servers 1.9.0 through 1.9.2 (inclusive) Subversion svnserve servers (any version) are not vulnerable Known fixed: ============ Subversion 1.8.15 Subversion 1.9.3 Details: ======== The Subversion http://-based protocol used for communicating with a Subversion mod_dav_svn server has two versions, v1 and v2. The v2 protocol was added in Subversion 1.7.0. As a part of the commit happening over v2 protocol, the client sends a POST request with the request body containing data encoded in a special `skeleton' (or `skel') format. The parser of skel-encoded request bodies in mod_dav_svn contains a flaw that allows the attacker to write memory past the end of a heap buffer with a specially crafted request that causes an arithmetic overflow in 32-bit server versions. 64-bit server versions are not vulnerable to the heap-based buffer overflow, but can be forced into allocating huge amounts of memory, thus, the successful attack on them would cause denial-of-service conditions. Exploiting this vulnerability requires the attacker to be authenticated and to have write access to a repository on the targeted server. Severity: ========= CVSSv2 Base Score: 4.6 CVSSv2 Base Vector: AV:N/AC:H/Au:S/C:P/I:P/A:P We consider this to be a medium risk vulnerability. In order to take advantage of this attack the attacker would require write access to the repository. Most configurations require authentication to commit changes and so anonymous users would not be able to use this attack in these cases. With the write access, the denial of service attack is reasonably easy to carry out, while exploiting the heap overflow is more difficult, depending upon how skilled the attacker is and upon the specifics of the platform. In case of the denial of service attack, a remote attacker may be able to crash a Subversion server. Many Apache servers will respawn the listener processes, but a determined attacker will be able to crash these processes as they appear, denying service to legitimate users. Servers using threaded MPMs will close the connection on other clients being served by the same process that services the request from the attacker. In either case there is an increased processing impact of restarting a process and the cost of per process caches being lost. Recommendations: ================ We recommend all users to upgrade to Subversion 1.9.3. Users of Subversion 1.8.x and 1.9.x who are unable to upgrade may apply the included patch. New Subversion packages can be found at: http://subversion.apache.org/packages.html No workaround is available. References: =========== CVE-2015-5343 (Subversion) Reported by: ============ Ivan Zhakov, VisualSVN
Side note: branch 1.7 mentioned as vulnerable, but no release for it scheduled. @maintainers: Perhaps we should drop or mask 1.7 branch?
This issue is public now @maintainers: ping about 1.7 branch - should we mask it?
(In reply to Sergey Popov from comment #2) > This issue is public now > > @maintainers: ping about 1.7 branch - should we mask it? I suggest adding a mask for =1.7* and keeping it for a longer time, so people still using it also will get the message. For the version remaining in tree, the best is probably to remove it after fixed version became stable. Does security want to do the mask or should i do that?
(In reply to Thomas Sachau from comment #3) > (In reply to Sergey Popov from comment #2) > > This issue is public now > > > > @maintainers: ping about 1.7 branch - should we mask it? > > I suggest adding a mask for =1.7* and keeping it for a longer time, so > people still using it also will get the message. > For the version remaining in tree, the best is probably to remove it after > fixed version became stable. Does security want to do the mask or should i > do that? If you could mask it that would be great. Do you intend to call for stabilization of 1.8.15 and 1.9.3?
Added to existing GLSA.
I have removed the 1.7 series from the tree. I leave the removal of the mask to the reporter.
Mask for 1.7 branch was removed, waiting for cleanup old versions
Cleanup was done
This issue was resolved and addressed in GLSA 201610-05 at https://security.gentoo.org/glsa/201610-05 by GLSA coordinator Aaron Bauman (b-man).
