aports issueshttps://gitlab.alpinelinux.org/alpine/aports/-/issues2019-07-23T14:21:55Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2033libtirpc CVE-2013-19502019-07-23T14:21:55ZPeter Kotcauerlibtirpc CVE-2013-1950An invalid pointer free flaw was found in the way server side code
implementation for connectionless RPC requests of libtirpc, a library
implementing Transport-Independent RPC (TI-RPC), (previously)
performed
arguments retrieval (d...An invalid pointer free flaw was found in the way server side code
implementation for connectionless RPC requests of libtirpc, a library
implementing Transport-Independent RPC (TI-RPC), (previously)
performed
arguments retrieval (due to a regression in commit 82cc2e61
svc\_dg\_getargs()
routine callers would crash with invalid pointer free). A remote
attacker
could issue a specially-crafted Sun RPC request that, when processed,
would lead to rpcbind daemon crash.
A different vulnerability than CVE-2003-0028.
\[3\] https://bugzilla.redhat.com/show\_bug.cgi?id=948378\#c13
Particular upstream patch:
\[4\]
http://git.infradead.org/users/steved/libtirpc.git/commitdiff/a9f437119d79a438cb12e510f3cadd4060102c9f
Note: While the original CVE-2003-0028 issue has been reported to
possibly
allow / lead to arbitrary code execution under certain circumstances,
the current (CVE-2013-1950) is believed to be able to cause (remote)
rpcbind daemon crash “only”.
*(from redmine: issue id 2033, created on 2013-05-30, closed on 2013-06-03)*
* Relations:
* child #2034Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2034[v2.6] libtirpc: Invalid pointer free leads to rpcbind daemon crash CVE-2013-...2019-07-23T14:21:54ZPeter Kotcauer[v2.6] libtirpc: Invalid pointer free leads to rpcbind daemon crash CVE-2013-1950An invalid pointer free flaw was found in the way server side code
implementation for connectionless RPC requests of libtirpc, a library
implementing Transport-Independent RPC (TI-RPC), (previously)
performed
arguments retrieval (d...An invalid pointer free flaw was found in the way server side code
implementation for connectionless RPC requests of libtirpc, a library
implementing Transport-Independent RPC (TI-RPC), (previously)
performed
arguments retrieval (due to a regression in commit 82cc2e61
svc\_dg\_getargs()
routine callers would crash with invalid pointer free). A remote
attacker
could issue a specially-crafted Sun RPC request that, when processed,
would lead to rpcbind daemon crash.
A different vulnerability than CVE-2003-0028.
\[3\] https://bugzilla.redhat.com/show\_bug.cgi?id=948378\#c13
Particular upstream patch:
\[4\]
http://git.infradead.org/users/steved/libtirpc.git/commitdiff/a9f437119d79a438cb12e510f3cadd4060102c9f
Note: While the original CVE-2003-0028 issue has been reported to
possibly
allow / lead to arbitrary code execution under certain circumstances,
the current (CVE-2013-1950) is believed to be able to cause (remote)
rpcbind daemon crash “only”.
*(from redmine: issue id 2034, created on 2013-05-30, closed on 2013-06-03)*
* Relations:
* parent #2033
* Changesets:
* Revision 473d40bbb88f98d74f074adb5a1a05e5c168aac2 by Natanael Copa on 2013-06-03T15:41:48Z:
```
main/libtirpc: fix CVE-2013-1950
fixes #2034
```Alpine 2.6.1Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2036znc 1.0: null pointer dereference in webadmin CVE-2013-21302019-07-23T14:21:53ZPeter Kotcauerznc 1.0: null pointer dereference in webadmin CVE-2013-2130A null pointer dereference was found in ZNC 1.0 in the webadmin module
which can be triggered by non-admins and cause denial of service\[0\].
References:
\[0\]
https://github.com/znc/znc/commit/2bd410ee5570cea127233f1133ea22f25174eb...A null pointer dereference was found in ZNC 1.0 in the webadmin module
which can be triggered by non-admins and cause denial of service\[0\].
References:
\[0\]
https://github.com/znc/znc/commit/2bd410ee5570cea127233f1133ea22f25174eb28
\[1\] https://secunia.com/advisories/53450/
http://www.openwall.com/lists/oss-security/2013/05/30/3
*(from redmine: issue id 2036, created on 2013-05-30, closed on 2013-06-04)*
* Relations:
* child #2037Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2037[v2.6] znc 1.0: null pointer dereference in webadmin CVE-2013-21302019-07-23T14:21:53ZPeter Kotcauer[v2.6] znc 1.0: null pointer dereference in webadmin CVE-2013-2130A null pointer dereference was found in ZNC 1.0 in the webadmin module
which can be triggered by non-admins and cause denial of service\[0\].
References:
\[0\]
https://github.com/znc/znc/commit/2bd410ee5570cea127233f1133ea22f25174eb...A null pointer dereference was found in ZNC 1.0 in the webadmin module
which can be triggered by non-admins and cause denial of service\[0\].
References:
\[0\]
https://github.com/znc/znc/commit/2bd410ee5570cea127233f1133ea22f25174eb28
\[1\] https://secunia.com/advisories/53450/
http://www.openwall.com/lists/oss-security/2013/05/30/3
*(from redmine: issue id 2037, created on 2013-05-30, closed on 2013-06-04)*
* Relations:
* parent #2036
* Changesets:
* Revision 5461ef9adb8cfbbca3db9367b6922a3f37552bc5 by Natanael Copa on 2013-06-04T09:12:38Z:
```
main/znc: fix NULL pointer dereference in webadmin (CVE-2013-2130)
fixes #2037
```Alpine 2.6.1Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2038Package request: rsyslog-mongodb2019-07-23T14:21:52ZJan-Hendrik DörnerPackage request: rsyslog-mongodbIt would be great, to support MongoDB as a backend for logging.
This feature wish is blocked by feature request issue 1182.
*(from redmine: issue id 2038, created on 2013-06-01, closed on 2019-05-06)*
* Relations:
* blocks #1182It would be great, to support MongoDB as a backend for logging.
This feature wish is blocked by feature request issue 1182.
*(from redmine: issue id 2038, created on 2013-06-01, closed on 2019-05-06)*
* Relations:
* blocks #11823.10.0Simon Fsimon-alpine@fraho.euSimon Fsimon-alpine@fraho.euhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2039CVE-2013-2850: Linux kernel iSCSI target heap overflow2019-07-23T14:21:51ZPeter KotcauerCVE-2013-2850: Linux kernel iSCSI target heap overflowupstream fix:
http://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?id=cea4dcfdad926a27a18e188720efe0f2c9403456
http://www.openwall.com/lists/oss-security/2013/06/01/2
*(from redmine: issue id 2039, created on 201...upstream fix:
http://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?id=cea4dcfdad926a27a18e188720efe0f2c9403456
http://www.openwall.com/lists/oss-security/2013/06/01/2
*(from redmine: issue id 2039, created on 2013-06-02, closed on 2013-06-06)*
* Relations:
* child #2040
* child #2041
* child #2042
* Changesets:
* Revision 3310ac9accc6cebf3ad021b1f7129f77f1ddb8b9 by Natanael Copa on 2013-06-03T16:23:04Z:
```
main/linux-grsec: upgrade to grsecurity-2.9.1-3.9.4-201306011536
ref #2039
```
* Revision c643c4483a61f62669afc857fbc34c883138c45f by Natanael Copa on 2013-06-03T16:32:21Z:
```
main/linux-grsec: upgrade to grsecurity-2.9.1-3.9.4-201306011536
fixes #2039
(cherry picked from commit 3310ac9accc6cebf3ad021b1f7129f77f1ddb8b9)
```
* Revision 97a2dc5e64610f100ddcf87f5ed30b5c2aea766d by Natanael Copa on 2013-06-05T13:49:11Z:
```
main/linux-grsec: security fix CVE-2013-2850
ref #2039
fixes #2041
```
* Revision 56028d0155b80c508b86c5b1215f0e444ab33c58 by Natanael Copa on 2013-06-05T14:02:08Z:
```
main/linux-grsec: upgrade to 3.4.47 and fix CVE-2013-2850
ref #2039
fixes #2042
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/2040[v2.6] CVE-2013-2850: Linux kernel iSCSI target heap overflow2019-07-23T14:21:49ZPeter Kotcauer[v2.6] CVE-2013-2850: Linux kernel iSCSI target heap overflowupstream fix:
http://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?id=cea4dcfdad926a27a18e188720efe0f2c9403456
http://www.openwall.com/lists/oss-security/2013/06/01/2
*(from redmine: issue id 2040, created on 201...upstream fix:
http://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?id=cea4dcfdad926a27a18e188720efe0f2c9403456
http://www.openwall.com/lists/oss-security/2013/06/01/2
*(from redmine: issue id 2040, created on 2013-06-02, closed on 2013-06-06)*
* Relations:
* parent #2039Alpine 2.6.1https://gitlab.alpinelinux.org/alpine/aports/-/issues/2041[v2.5] CVE-2013-2850: Linux kernel iSCSI target heap overflow2019-07-23T14:21:48ZPeter Kotcauer[v2.5] CVE-2013-2850: Linux kernel iSCSI target heap overflowupstream fix:
http://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?id=cea4dcfdad926a27a18e188720efe0f2c9403456
http://www.openwall.com/lists/oss-security/2013/06/01/2
*(from redmine: issue id 2041, created on 201...upstream fix:
http://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?id=cea4dcfdad926a27a18e188720efe0f2c9403456
http://www.openwall.com/lists/oss-security/2013/06/01/2
*(from redmine: issue id 2041, created on 2013-06-02, closed on 2013-06-06)*
* Relations:
* parent #2039
* Changesets:
* Revision 97a2dc5e64610f100ddcf87f5ed30b5c2aea766d by Natanael Copa on 2013-06-05T13:49:11Z:
```
main/linux-grsec: security fix CVE-2013-2850
ref #2039
fixes #2041
```Alpine 2.5.5https://gitlab.alpinelinux.org/alpine/aports/-/issues/2042[v2.4] CVE-2013-2850: Linux kernel iSCSI target heap overflow2019-07-23T14:21:46ZPeter Kotcauer[v2.4] CVE-2013-2850: Linux kernel iSCSI target heap overflowupstream fix:
http://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?id=cea4dcfdad926a27a18e188720efe0f2c9403456
http://www.openwall.com/lists/oss-security/2013/06/01/2
*(from redmine: issue id 2042, created on 201...upstream fix:
http://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?id=cea4dcfdad926a27a18e188720efe0f2c9403456
http://www.openwall.com/lists/oss-security/2013/06/01/2
*(from redmine: issue id 2042, created on 2013-06-02, closed on 2013-06-06)*
* Relations:
* parent #2039
* Changesets:
* Revision 56028d0155b80c508b86c5b1215f0e444ab33c58 by Natanael Copa on 2013-06-05T14:02:08Z:
```
main/linux-grsec: upgrade to 3.4.47 and fix CVE-2013-2850
ref #2039
fixes #2042
```Alpine 2.4.12https://gitlab.alpinelinux.org/alpine/aports/-/issues/2043Request for package: libJudy2022-05-05T16:20:01ZV KrishnRequest for package: libJudyA Judy array is a complex but very fast associative array data structure
for storing and looking up values using integer or string keys. Unlike
normal arrays, Judy arrays may be sparse; that is, they may have large
ranges of unassigned i...A Judy array is a complex but very fast associative array data structure
for storing and looking up values using integer or string keys. Unlike
normal arrays, Judy arrays may be sparse; that is, they may have large
ranges of unassigned indices.
Url:
http://judy.sourceforge.net/
*(from redmine: issue id 2043, created on 2013-06-03, closed on 2013-08-06)*
* Changesets:
* Revision 2041158f416eb7bc846dbe58a4a67f9b6eab6862 by Carlo Landmeter on 2013-06-17T14:15:22Z:
```
testing/judy: new aport
A C library that implements a dynamic array
fixes #2043
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/2044xen CVE-2013-2076 Information leak on XSAVE/XRSTOR capable AMD CPUs2019-07-23T14:21:45ZPeter Kotcauerxen CVE-2013-2076 Information leak on XSAVE/XRSTOR capable AMD CPUsreference:
http://www.openwall.com/lists/oss-security/2013/06/03/1
ISSUE DESCRIPTION
=
On AMD processors supporting XSAVE/XRSTOR (family 15h and up), when an
exception is pending, these instructions save/restore only the FOP,
F...reference:
http://www.openwall.com/lists/oss-security/2013/06/03/1
ISSUE DESCRIPTION
=
On AMD processors supporting XSAVE/XRSTOR (family 15h and up), when an
exception is pending, these instructions save/restore only the FOP,
FIP, and FDP x87 registers in FXSAVE/FXRSTOR. This allows one domain
to determine portions of the state of floating point instructions of
other domains.
NOTE: This is the documented behavior of AMD64 processors, but it is
inconsistent with Intel processors in a security-relevant fashion that
was not addressed by the original implementation of XSAVE support on
Xen.
This vulnerability is similar to CVE-2006-1056, concerning
FXSAVE/FXRSTOR on AMD processors.
IMPACT
==
A malicious domain may be able to leverage this to obtain sensitive
information such as cryptographic keys from another domain.
VULNERABLE SYSTEMS
==
Xen 4.0 and onwards are vulnerable when run on systems with AMD
processors supporting XSAVE. Any kind of guest can exploit the
vulnerability.
In Xen 4.0.2 through 4.0.4 as well as in Xen 4.1.x XSAVE support is
disabled by default; therefore systems running these versions are not
vulnerable unless support is explicitly enabled using the “xsave”
hypervisor command line option.
Systems not using AMD processors, or using AMD processors not
supporting XSAVE (i.e. families prior to 15h), are not vulnerable.
Xen 3.x and earlier are not vulnerable.
MITIGATION
==
Turning off XSAVE support via the “no-xsave” hypervisor command line
option will avoid the vulnerability.
RESOLUTION
==
Applying the attached patch resolves this issue.
xsa52-4.1.patch Xen 4.1.x
xsa52-4.2-unstable.patch Xen 4.2.x, xen-unstable
$ sha256sum xsa52-\*.patch
058741aae8881774cfe8f8d193fee9b92da62e61459b1e9617798ccee2ce8d75
xsa52-4.1.patch
5b8582185bf90386729e81db1f7780c69a891b074a87d9a619a90d6f639bea13
xsa52-4.2-unstable.patch
*(from redmine: issue id 2044, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* child #2045
* child #2046
* child #2047
* child #2048
* Changesets:
* Revision f6e99451d47fbe7cdb852f48dd11006808db52ae by Natanael Copa on 2013-06-04T11:30:54Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
```
* Revision 793a2f362351c53c4175ab2cc395a92d6d83b209 by Natanael Copa on 2013-06-04T11:57:28Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2045
fixes #2050
fixes #2055
(cherry picked from commit f6e99451d47fbe7cdb852f48dd11006808db52ae)
```
* Revision e466dbbf828a8e83c3f34d7311afcaf02e1d2408 by Natanael Copa on 2013-06-05T15:04:11Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2046
fixes #2051
fixes #2056
(cherry picked from commit f6e99451d47fbe7cdb852f48dd11006808db52ae)
Conflicts:
main/xen/APKBUILD
```
* Revision a2883b66233b3bc958ccb3555996adeacd070c64 by Natanael Copa on 2013-06-05T15:08:29Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2047
fixes #2052
fixes #2057
```
* Revision 9da25b8784e5b39b905e86bdb94e5a0026f10bd4 by Natanael Copa on 2013-06-05T15:21:46Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2048
fixes #2053
fixes #2058
```
* Uploads:
* [xsa52-4.1.patch](/uploads/7cb676c5f29be7dc5521ce91a31a6658/xsa52-4.1.patch)
* [xsa52-4.2-unstable.patch](/uploads/0d24e7535324eefb75a786b3eb43f863/xsa52-4.2-unstable.patch)Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2045[v2.6] xen CVE-2013-2076 Information leak on XSAVE/XRSTOR capable AMD CPUs2019-07-23T14:21:43ZPeter Kotcauer[v2.6] xen CVE-2013-2076 Information leak on XSAVE/XRSTOR capable AMD CPUsISSUE DESCRIPTION
=
On AMD processors supporting XSAVE/XRSTOR (family 15h and up), when an
exception is pending, these instructions save/restore only the FOP,
FIP, and FDP x87 registers in FXSAVE/FXRSTOR. This allows one domain
...ISSUE DESCRIPTION
=
On AMD processors supporting XSAVE/XRSTOR (family 15h and up), when an
exception is pending, these instructions save/restore only the FOP,
FIP, and FDP x87 registers in FXSAVE/FXRSTOR. This allows one domain
to determine portions of the state of floating point instructions of
other domains.
NOTE: This is the documented behavior of AMD64 processors, but it is
inconsistent with Intel processors in a security-relevant fashion that
was not addressed by the original implementation of XSAVE support on
Xen.
This vulnerability is similar to CVE-2006-1056, concerning
FXSAVE/FXRSTOR on AMD processors.
IMPACT
==
A malicious domain may be able to leverage this to obtain sensitive
information such as cryptographic keys from another domain.
VULNERABLE SYSTEMS
==
Xen 4.0 and onwards are vulnerable when run on systems with AMD
processors supporting XSAVE. Any kind of guest can exploit the
vulnerability.
In Xen 4.0.2 through 4.0.4 as well as in Xen 4.1.x XSAVE support is
disabled by default; therefore systems running these versions are not
vulnerable unless support is explicitly enabled using the “xsave”
hypervisor command line option.
Systems not using AMD processors, or using AMD processors not
supporting XSAVE (i.e. families prior to 15h), are not vulnerable.
Xen 3.x and earlier are not vulnerable.
MITIGATION
==
Turning off XSAVE support via the “no-xsave” hypervisor command line
option will avoid the vulnerability.
RESOLUTION
==
Applying the attached patch resolves this issue.
xsa52-4.1.patch Xen 4.1.x
xsa52-4.2-unstable.patch Xen 4.2.x, xen-unstable
$ sha256sum xsa52-\*.patch
058741aae8881774cfe8f8d193fee9b92da62e61459b1e9617798ccee2ce8d75
xsa52-4.1.patch
5b8582185bf90386729e81db1f7780c69a891b074a87d9a619a90d6f639bea13
xsa52-4.2-unstable.patch
*(from redmine: issue id 2045, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* parent #2044
* Changesets:
* Revision 793a2f362351c53c4175ab2cc395a92d6d83b209 by Natanael Copa on 2013-06-04T11:57:28Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2045
fixes #2050
fixes #2055
(cherry picked from commit f6e99451d47fbe7cdb852f48dd11006808db52ae)
```
* Uploads:
* [xsa52-4.1.patch](/uploads/6da78c0b1ce77822c6385a2f30a2012b/xsa52-4.1.patch)
* [xsa52-4.2-unstable.patch](/uploads/2322e281b07aec87de33e3910cf8a909/xsa52-4.2-unstable.patch)Alpine 2.6.1Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2046[v2.5] xen CVE-2013-2076 Information leak on XSAVE/XRSTOR capable AMD CPUs2019-07-23T14:21:42ZPeter Kotcauer[v2.5] xen CVE-2013-2076 Information leak on XSAVE/XRSTOR capable AMD CPUsISSUE DESCRIPTION
=
On AMD processors supporting XSAVE/XRSTOR (family 15h and up), when an
exception is pending, these instructions save/restore only the FOP,
FIP, and FDP x87 registers in FXSAVE/FXRSTOR. This allows one domain
...ISSUE DESCRIPTION
=
On AMD processors supporting XSAVE/XRSTOR (family 15h and up), when an
exception is pending, these instructions save/restore only the FOP,
FIP, and FDP x87 registers in FXSAVE/FXRSTOR. This allows one domain
to determine portions of the state of floating point instructions of
other domains.
NOTE: This is the documented behavior of AMD64 processors, but it is
inconsistent with Intel processors in a security-relevant fashion that
was not addressed by the original implementation of XSAVE support on
Xen.
This vulnerability is similar to CVE-2006-1056, concerning
FXSAVE/FXRSTOR on AMD processors.
IMPACT
==
A malicious domain may be able to leverage this to obtain sensitive
information such as cryptographic keys from another domain.
VULNERABLE SYSTEMS
==
Xen 4.0 and onwards are vulnerable when run on systems with AMD
processors supporting XSAVE. Any kind of guest can exploit the
vulnerability.
In Xen 4.0.2 through 4.0.4 as well as in Xen 4.1.x XSAVE support is
disabled by default; therefore systems running these versions are not
vulnerable unless support is explicitly enabled using the “xsave”
hypervisor command line option.
Systems not using AMD processors, or using AMD processors not
supporting XSAVE (i.e. families prior to 15h), are not vulnerable.
Xen 3.x and earlier are not vulnerable.
MITIGATION
==
Turning off XSAVE support via the “no-xsave” hypervisor command line
option will avoid the vulnerability.
RESOLUTION
==
Applying the attached patch resolves this issue.
xsa52-4.1.patch Xen 4.1.x
xsa52-4.2-unstable.patch Xen 4.2.x, xen-unstable
$ sha256sum xsa52-\*.patch
058741aae8881774cfe8f8d193fee9b92da62e61459b1e9617798ccee2ce8d75
xsa52-4.1.patch
5b8582185bf90386729e81db1f7780c69a891b074a87d9a619a90d6f639bea13
xsa52-4.2-unstable.patch
*(from redmine: issue id 2046, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* parent #2044
* Changesets:
* Revision e466dbbf828a8e83c3f34d7311afcaf02e1d2408 by Natanael Copa on 2013-06-05T15:04:11Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2046
fixes #2051
fixes #2056
(cherry picked from commit f6e99451d47fbe7cdb852f48dd11006808db52ae)
Conflicts:
main/xen/APKBUILD
```
* Uploads:
* [xsa52-4.1.patch](/uploads/7a045c34d9e9119a2da3ab993ce97855/xsa52-4.1.patch)
* [xsa52-4.2-unstable.patch](/uploads/eb9a425166fc104ae3a0d6ca4fb437c7/xsa52-4.2-unstable.patch)Alpine 2.5.5Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2047[v2.4] xen CVE-2013-2076 Information leak on XSAVE/XRSTOR capable AMD CPUs2019-07-23T14:21:41ZPeter Kotcauer[v2.4] xen CVE-2013-2076 Information leak on XSAVE/XRSTOR capable AMD CPUsISSUE DESCRIPTION
=
On AMD processors supporting XSAVE/XRSTOR (family 15h and up), when an
exception is pending, these instructions save/restore only the FOP,
FIP, and FDP x87 registers in FXSAVE/FXRSTOR. This allows one domain
...ISSUE DESCRIPTION
=
On AMD processors supporting XSAVE/XRSTOR (family 15h and up), when an
exception is pending, these instructions save/restore only the FOP,
FIP, and FDP x87 registers in FXSAVE/FXRSTOR. This allows one domain
to determine portions of the state of floating point instructions of
other domains.
NOTE: This is the documented behavior of AMD64 processors, but it is
inconsistent with Intel processors in a security-relevant fashion that
was not addressed by the original implementation of XSAVE support on
Xen.
This vulnerability is similar to CVE-2006-1056, concerning
FXSAVE/FXRSTOR on AMD processors.
IMPACT
==
A malicious domain may be able to leverage this to obtain sensitive
information such as cryptographic keys from another domain.
VULNERABLE SYSTEMS
==
Xen 4.0 and onwards are vulnerable when run on systems with AMD
processors supporting XSAVE. Any kind of guest can exploit the
vulnerability.
In Xen 4.0.2 through 4.0.4 as well as in Xen 4.1.x XSAVE support is
disabled by default; therefore systems running these versions are not
vulnerable unless support is explicitly enabled using the “xsave”
hypervisor command line option.
Systems not using AMD processors, or using AMD processors not
supporting XSAVE (i.e. families prior to 15h), are not vulnerable.
Xen 3.x and earlier are not vulnerable.
MITIGATION
==
Turning off XSAVE support via the “no-xsave” hypervisor command line
option will avoid the vulnerability.
RESOLUTION
==
Applying the attached patch resolves this issue.
xsa52-4.1.patch Xen 4.1.x
xsa52-4.2-unstable.patch Xen 4.2.x, xen-unstable
$ sha256sum xsa52-\*.patch
058741aae8881774cfe8f8d193fee9b92da62e61459b1e9617798ccee2ce8d75
xsa52-4.1.patch
5b8582185bf90386729e81db1f7780c69a891b074a87d9a619a90d6f639bea13
xsa52-4.2-unstable.patch
*(from redmine: issue id 2047, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* parent #2044
* Changesets:
* Revision a2883b66233b3bc958ccb3555996adeacd070c64 by Natanael Copa on 2013-06-05T15:08:29Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2047
fixes #2052
fixes #2057
```
* Uploads:
* [xsa52-4.1.patch](/uploads/5ae30620ed645908170349275c2a8b6a/xsa52-4.1.patch)
* [xsa52-4.2-unstable.patch](/uploads/ee88ac70650a77574021fd0e729b1e1b/xsa52-4.2-unstable.patch)Alpine 2.4.12Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2048[v2.3] xen CVE-2013-2076 Information leak on XSAVE/XRSTOR capable AMD CPUs2019-07-23T14:21:40ZPeter Kotcauer[v2.3] xen CVE-2013-2076 Information leak on XSAVE/XRSTOR capable AMD CPUsISSUE DESCRIPTION
=
On AMD processors supporting XSAVE/XRSTOR (family 15h and up), when an
exception is pending, these instructions save/restore only the FOP,
FIP, and FDP x87 registers in FXSAVE/FXRSTOR. This allows one domain
...ISSUE DESCRIPTION
=
On AMD processors supporting XSAVE/XRSTOR (family 15h and up), when an
exception is pending, these instructions save/restore only the FOP,
FIP, and FDP x87 registers in FXSAVE/FXRSTOR. This allows one domain
to determine portions of the state of floating point instructions of
other domains.
NOTE: This is the documented behavior of AMD64 processors, but it is
inconsistent with Intel processors in a security-relevant fashion that
was not addressed by the original implementation of XSAVE support on
Xen.
This vulnerability is similar to CVE-2006-1056, concerning
FXSAVE/FXRSTOR on AMD processors.
IMPACT
==
A malicious domain may be able to leverage this to obtain sensitive
information such as cryptographic keys from another domain.
VULNERABLE SYSTEMS
==
Xen 4.0 and onwards are vulnerable when run on systems with AMD
processors supporting XSAVE. Any kind of guest can exploit the
vulnerability.
In Xen 4.0.2 through 4.0.4 as well as in Xen 4.1.x XSAVE support is
disabled by default; therefore systems running these versions are not
vulnerable unless support is explicitly enabled using the “xsave”
hypervisor command line option.
Systems not using AMD processors, or using AMD processors not
supporting XSAVE (i.e. families prior to 15h), are not vulnerable.
Xen 3.x and earlier are not vulnerable.
MITIGATION
==
Turning off XSAVE support via the “no-xsave” hypervisor command line
option will avoid the vulnerability.
RESOLUTION
==
Applying the attached patch resolves this issue.
xsa52-4.1.patch Xen 4.1.x
xsa52-4.2-unstable.patch Xen 4.2.x, xen-unstable
$ sha256sum xsa52-\*.patch
058741aae8881774cfe8f8d193fee9b92da62e61459b1e9617798ccee2ce8d75
xsa52-4.1.patch
5b8582185bf90386729e81db1f7780c69a891b074a87d9a619a90d6f639bea13
xsa52-4.2-unstable.patch
*(from redmine: issue id 2048, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* parent #2044
* Changesets:
* Revision 9da25b8784e5b39b905e86bdb94e5a0026f10bd4 by Natanael Copa on 2013-06-05T15:21:46Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2048
fixes #2053
fixes #2058
```
* Uploads:
* [xsa52-4.1.patch](/uploads/bc8155eba58cfcb2e23208dee5ca629a/xsa52-4.1.patch)
* [xsa52-4.2-unstable.patch](/uploads/1fceb5f62b03c7c43617ef9d59de0011/xsa52-4.2-unstable.patch)Alpine 2.3.7Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2049xen CVE-2013-2077 Hypervisor crash due to missing exception recovery on XRSTOR2019-07-23T14:21:38ZPeter Kotcauerxen CVE-2013-2077 Hypervisor crash due to missing exception recovery on XRSTORreference:
http://www.openwall.com/lists/oss-security/2013/06/03/2
ISSUE DESCRIPTION
=
Processors do certain validity checks on the data passed to XRSTOR.
While the hypervisor controls the placement of that memory block, it
doe...reference:
http://www.openwall.com/lists/oss-security/2013/06/03/2
ISSUE DESCRIPTION
=
Processors do certain validity checks on the data passed to XRSTOR.
While the hypervisor controls the placement of that memory block, it
doesn’t restrict the contents in any way. Thus the hypervisor exposes
itself to a fault occurring on XRSTOR. Other than for FXRSTOR, which
behaves similarly, there was no exception recovery code attached to
XRSTOR.
IMPACT
==
Malicious or buggy unprivileged user space can cause the entire host
to crash.
VULNERABLE SYSTEMS
==
Xen 4.0 and onwards are vulnerable when run on systems with processors
supporting XSAVE. Only PV guests can exploit the vulnerability; for
HVM guests only the control tools have access to the respective
hypervisor functions.
In Xen 4.0.2 through 4.0.4 as well as in Xen 4.1.x XSAVE support is
disabled by default; therefore systems running these versions are not
vulnerable unless support is explicitly enabled using the “xsave”
hypervisor command line option.
Systems using processors not supporting XSAVE are not vulnerable.
Xen 3.x and earlier are not vulnerable.
MITIGATION
==
Turning off XSAVE support via the “no-xsave” hypervisor command line
option will avoid the vulnerability.
RESOLUTION
==
Applying the attached patch resolves this issue.
xsa53-4.1.patch Xen 4.1.x
xsa53-4.2.patch Xen 4.2.x
xsa53-unstable.patch xen-unstable
$ sha256sum xsa53-\*.patch
2deedb983ef6ffb24375e5ae33fd271e4fb94f938be143919310daf1163de182
xsa53-4.1.patch
785f7612bd229f7501f4e98e4760f307d90c64305ee14707d262b77f05fa683d
xsa53-4.2.patch
b9804e081afbc5e7308176841d0249e1f934f75e7fcc8f937bad6b95eb6944a5
xsa53-unstable.patch
*(from redmine: issue id 2049, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* child #2050
* child #2051
* child #2052
* child #2053
* Changesets:
* Revision f6e99451d47fbe7cdb852f48dd11006808db52ae by Natanael Copa on 2013-06-04T11:30:54Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
```
* Revision 793a2f362351c53c4175ab2cc395a92d6d83b209 by Natanael Copa on 2013-06-04T11:57:28Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2045
fixes #2050
fixes #2055
(cherry picked from commit f6e99451d47fbe7cdb852f48dd11006808db52ae)
```
* Revision e466dbbf828a8e83c3f34d7311afcaf02e1d2408 by Natanael Copa on 2013-06-05T15:04:11Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2046
fixes #2051
fixes #2056
(cherry picked from commit f6e99451d47fbe7cdb852f48dd11006808db52ae)
Conflicts:
main/xen/APKBUILD
```
* Revision a2883b66233b3bc958ccb3555996adeacd070c64 by Natanael Copa on 2013-06-05T15:08:29Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2047
fixes #2052
fixes #2057
```
* Revision 9da25b8784e5b39b905e86bdb94e5a0026f10bd4 by Natanael Copa on 2013-06-05T15:21:46Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2048
fixes #2053
fixes #2058
```
* Uploads:
* [xsa53-4.1.patch](/uploads/b2bcf19730673bb77b947df4ea1d2fbb/xsa53-4.1.patch)
* [xsa53-4.2.patch](/uploads/dfe2df99acb0e7497da5d2d2957483f6/xsa53-4.2.patch)
* [xsa53-unstable.patch](/uploads/d8b5494fa54393e1e31ae7aa81a707fd/xsa53-unstable.patch)Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2050[v2.6] xen CVE-2013-2077 Hypervisor crash due to missing exception recovery o...2019-07-23T14:21:37ZPeter Kotcauer[v2.6] xen CVE-2013-2077 Hypervisor crash due to missing exception recovery on XRSTORreference:
http://www.openwall.com/lists/oss-security/2013/06/03/2
ISSUE DESCRIPTION
=
Processors do certain validity checks on the data passed to XRSTOR.
While the hypervisor controls the placement of that memory block, it
doe...reference:
http://www.openwall.com/lists/oss-security/2013/06/03/2
ISSUE DESCRIPTION
=
Processors do certain validity checks on the data passed to XRSTOR.
While the hypervisor controls the placement of that memory block, it
doesn’t restrict the contents in any way. Thus the hypervisor exposes
itself to a fault occurring on XRSTOR. Other than for FXRSTOR, which
behaves similarly, there was no exception recovery code attached to
XRSTOR.
IMPACT
==
Malicious or buggy unprivileged user space can cause the entire host
to crash.
VULNERABLE SYSTEMS
==
Xen 4.0 and onwards are vulnerable when run on systems with processors
supporting XSAVE. Only PV guests can exploit the vulnerability; for
HVM guests only the control tools have access to the respective
hypervisor functions.
In Xen 4.0.2 through 4.0.4 as well as in Xen 4.1.x XSAVE support is
disabled by default; therefore systems running these versions are not
vulnerable unless support is explicitly enabled using the “xsave”
hypervisor command line option.
Systems using processors not supporting XSAVE are not vulnerable.
Xen 3.x and earlier are not vulnerable.
MITIGATION
==
Turning off XSAVE support via the “no-xsave” hypervisor command line
option will avoid the vulnerability.
RESOLUTION
==
Applying the attached patch resolves this issue.
xsa53-4.1.patch Xen 4.1.x
xsa53-4.2.patch Xen 4.2.x
xsa53-unstable.patch xen-unstable
$ sha256sum xsa53-\*.patch
2deedb983ef6ffb24375e5ae33fd271e4fb94f938be143919310daf1163de182
xsa53-4.1.patch
785f7612bd229f7501f4e98e4760f307d90c64305ee14707d262b77f05fa683d
xsa53-4.2.patch
b9804e081afbc5e7308176841d0249e1f934f75e7fcc8f937bad6b95eb6944a5
xsa53-unstable.patch
*(from redmine: issue id 2050, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* parent #2049
* Changesets:
* Revision 793a2f362351c53c4175ab2cc395a92d6d83b209 by Natanael Copa on 2013-06-04T11:57:28Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2045
fixes #2050
fixes #2055
(cherry picked from commit f6e99451d47fbe7cdb852f48dd11006808db52ae)
```
* Uploads:
* [xsa53-4.1.patch](/uploads/30ee5f1d8e7de63da323237885193dae/xsa53-4.1.patch)
* [xsa53-4.2.patch](/uploads/06a91c11692149fc0c07f4c8703c5552/xsa53-4.2.patch)
* [xsa53-unstable.patch](/uploads/3d71c80c76095fcdeafdd09ba809da39/xsa53-unstable.patch)Alpine 2.6.1Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2051[v2.5] xen CVE-2013-2077 Hypervisor crash due to missing exception recovery o...2019-07-23T14:21:36ZPeter Kotcauer[v2.5] xen CVE-2013-2077 Hypervisor crash due to missing exception recovery on XRSTORreference:
http://www.openwall.com/lists/oss-security/2013/06/03/2
ISSUE DESCRIPTION
=
Processors do certain validity checks on the data passed to XRSTOR.
While the hypervisor controls the placement of that memory block, it
doe...reference:
http://www.openwall.com/lists/oss-security/2013/06/03/2
ISSUE DESCRIPTION
=
Processors do certain validity checks on the data passed to XRSTOR.
While the hypervisor controls the placement of that memory block, it
doesn’t restrict the contents in any way. Thus the hypervisor exposes
itself to a fault occurring on XRSTOR. Other than for FXRSTOR, which
behaves similarly, there was no exception recovery code attached to
XRSTOR.
IMPACT
==
Malicious or buggy unprivileged user space can cause the entire host
to crash.
VULNERABLE SYSTEMS
==
Xen 4.0 and onwards are vulnerable when run on systems with processors
supporting XSAVE. Only PV guests can exploit the vulnerability; for
HVM guests only the control tools have access to the respective
hypervisor functions.
In Xen 4.0.2 through 4.0.4 as well as in Xen 4.1.x XSAVE support is
disabled by default; therefore systems running these versions are not
vulnerable unless support is explicitly enabled using the “xsave”
hypervisor command line option.
Systems using processors not supporting XSAVE are not vulnerable.
Xen 3.x and earlier are not vulnerable.
MITIGATION
==
Turning off XSAVE support via the “no-xsave” hypervisor command line
option will avoid the vulnerability.
RESOLUTION
==
Applying the attached patch resolves this issue.
xsa53-4.1.patch Xen 4.1.x
xsa53-4.2.patch Xen 4.2.x
xsa53-unstable.patch xen-unstable
$ sha256sum xsa53-\*.patch
2deedb983ef6ffb24375e5ae33fd271e4fb94f938be143919310daf1163de182
xsa53-4.1.patch
785f7612bd229f7501f4e98e4760f307d90c64305ee14707d262b77f05fa683d
xsa53-4.2.patch
b9804e081afbc5e7308176841d0249e1f934f75e7fcc8f937bad6b95eb6944a5
xsa53-unstable.patch
*(from redmine: issue id 2051, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* parent #2049
* Changesets:
* Revision e466dbbf828a8e83c3f34d7311afcaf02e1d2408 by Natanael Copa on 2013-06-05T15:04:11Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2046
fixes #2051
fixes #2056
(cherry picked from commit f6e99451d47fbe7cdb852f48dd11006808db52ae)
Conflicts:
main/xen/APKBUILD
```
* Uploads:
* [xsa53-4.1.patch](/uploads/56250a11b875bea404e15b502fd8e69c/xsa53-4.1.patch)
* [xsa53-4.2.patch](/uploads/bc3bf2304e85507ba8a30c8394106152/xsa53-4.2.patch)
* [xsa53-unstable.patch](/uploads/3a914752527d6c830e454a9c83e2b2ec/xsa53-unstable.patch)Alpine 2.5.5Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2052[v2.4] xen CVE-2013-2077 Hypervisor crash due to missing exception recovery o...2019-07-23T14:21:35ZPeter Kotcauer[v2.4] xen CVE-2013-2077 Hypervisor crash due to missing exception recovery on XRSTORreference:
http://www.openwall.com/lists/oss-security/2013/06/03/2
ISSUE DESCRIPTION
=
Processors do certain validity checks on the data passed to XRSTOR.
While the hypervisor controls the placement of that memory block, it
doe...reference:
http://www.openwall.com/lists/oss-security/2013/06/03/2
ISSUE DESCRIPTION
=
Processors do certain validity checks on the data passed to XRSTOR.
While the hypervisor controls the placement of that memory block, it
doesn’t restrict the contents in any way. Thus the hypervisor exposes
itself to a fault occurring on XRSTOR. Other than for FXRSTOR, which
behaves similarly, there was no exception recovery code attached to
XRSTOR.
IMPACT
==
Malicious or buggy unprivileged user space can cause the entire host
to crash.
VULNERABLE SYSTEMS
==
Xen 4.0 and onwards are vulnerable when run on systems with processors
supporting XSAVE. Only PV guests can exploit the vulnerability; for
HVM guests only the control tools have access to the respective
hypervisor functions.
In Xen 4.0.2 through 4.0.4 as well as in Xen 4.1.x XSAVE support is
disabled by default; therefore systems running these versions are not
vulnerable unless support is explicitly enabled using the “xsave”
hypervisor command line option.
Systems using processors not supporting XSAVE are not vulnerable.
Xen 3.x and earlier are not vulnerable.
MITIGATION
==
Turning off XSAVE support via the “no-xsave” hypervisor command line
option will avoid the vulnerability.
RESOLUTION
==
Applying the attached patch resolves this issue.
xsa53-4.1.patch Xen 4.1.x
xsa53-4.2.patch Xen 4.2.x
xsa53-unstable.patch xen-unstable
$ sha256sum xsa53-\*.patch
2deedb983ef6ffb24375e5ae33fd271e4fb94f938be143919310daf1163de182
xsa53-4.1.patch
785f7612bd229f7501f4e98e4760f307d90c64305ee14707d262b77f05fa683d
xsa53-4.2.patch
b9804e081afbc5e7308176841d0249e1f934f75e7fcc8f937bad6b95eb6944a5
xsa53-unstable.patch
*(from redmine: issue id 2052, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* parent #2049
* Changesets:
* Revision a2883b66233b3bc958ccb3555996adeacd070c64 by Natanael Copa on 2013-06-05T15:08:29Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2047
fixes #2052
fixes #2057
```
* Uploads:
* [xsa53-4.1.patch](/uploads/72f9f6d9cd1bf2c5b623ac27a7f6597a/xsa53-4.1.patch)
* [xsa53-4.2.patch](/uploads/a66c5c5a42626e4acaf11e168c0eb210/xsa53-4.2.patch)
* [xsa53-unstable.patch](/uploads/b3ea97397c3bb8219df222c7d2d8c07a/xsa53-unstable.patch)Alpine 2.4.12Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2053[v2.3] xen CVE-2013-2077 Hypervisor crash due to missing exception recovery o...2019-07-23T14:21:34ZPeter Kotcauer[v2.3] xen CVE-2013-2077 Hypervisor crash due to missing exception recovery on XRSTORreference:
http://www.openwall.com/lists/oss-security/2013/06/03/2
ISSUE DESCRIPTION
=
Processors do certain validity checks on the data passed to XRSTOR.
While the hypervisor controls the placement of that memory block, it
doe...reference:
http://www.openwall.com/lists/oss-security/2013/06/03/2
ISSUE DESCRIPTION
=
Processors do certain validity checks on the data passed to XRSTOR.
While the hypervisor controls the placement of that memory block, it
doesn’t restrict the contents in any way. Thus the hypervisor exposes
itself to a fault occurring on XRSTOR. Other than for FXRSTOR, which
behaves similarly, there was no exception recovery code attached to
XRSTOR.
IMPACT
==
Malicious or buggy unprivileged user space can cause the entire host
to crash.
VULNERABLE SYSTEMS
==
Xen 4.0 and onwards are vulnerable when run on systems with processors
supporting XSAVE. Only PV guests can exploit the vulnerability; for
HVM guests only the control tools have access to the respective
hypervisor functions.
In Xen 4.0.2 through 4.0.4 as well as in Xen 4.1.x XSAVE support is
disabled by default; therefore systems running these versions are not
vulnerable unless support is explicitly enabled using the “xsave”
hypervisor command line option.
Systems using processors not supporting XSAVE are not vulnerable.
Xen 3.x and earlier are not vulnerable.
MITIGATION
==
Turning off XSAVE support via the “no-xsave” hypervisor command line
option will avoid the vulnerability.
RESOLUTION
==
Applying the attached patch resolves this issue.
xsa53-4.1.patch Xen 4.1.x
xsa53-4.2.patch Xen 4.2.x
xsa53-unstable.patch xen-unstable
$ sha256sum xsa53-\*.patch
2deedb983ef6ffb24375e5ae33fd271e4fb94f938be143919310daf1163de182
xsa53-4.1.patch
785f7612bd229f7501f4e98e4760f307d90c64305ee14707d262b77f05fa683d
xsa53-4.2.patch
b9804e081afbc5e7308176841d0249e1f934f75e7fcc8f937bad6b95eb6944a5
xsa53-unstable.patch
*(from redmine: issue id 2053, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* parent #2049
* Changesets:
* Revision 9da25b8784e5b39b905e86bdb94e5a0026f10bd4 by Natanael Copa on 2013-06-05T15:21:46Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2048
fixes #2053
fixes #2058
```
* Uploads:
* [xsa53-4.1.patch](/uploads/878b96789fe32841daf8c8b395e3dd98/xsa53-4.1.patch)
* [xsa53-4.2.patch](/uploads/4a90c37de030b4330e34d638637177af/xsa53-4.2.patch)
* [xsa53-unstable.patch](/uploads/13df9652a9e516c6ae3b10ff68c02b44/xsa53-unstable.patch)Alpine 2.3.7Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2054xen CVE-2013-2078 Hypervisor crash due to missing exception recovery on XSETBV2019-07-23T14:21:32ZPeter Kotcauerxen CVE-2013-2078 Hypervisor crash due to missing exception recovery on XSETBVreference:
http://www.openwall.com/lists/oss-security/2013/06/03/3
ISSUE DESCRIPTION
=
Processors do certain validity checks on the register values passed to
XSETBV. For the PV emulation path for that instruction the hypervisor ...reference:
http://www.openwall.com/lists/oss-security/2013/06/03/3
ISSUE DESCRIPTION
=
Processors do certain validity checks on the register values passed to
XSETBV. For the PV emulation path for that instruction the hypervisor
code didn’t check for certain invalid bit combinations, thus exposing
itself to a fault occurring when invoking that instruction on behalf
of the guest.
IMPACT
==
Malicious or buggy unprivileged user space can cause the entire host
to crash.
VULNERABLE SYSTEMS
==
Xen 4.0 and onwards are vulnerable when run on systems with processors
supporting XSAVE. Only PV guests can exploit the vulnerability.
In Xen 4.0.2 through 4.0.4 as well as in Xen 4.1.x XSAVE support is
disabled by default; therefore systems running these versions are not
vulnerable unless support is explicitly enabled using the “xsave”
hypervisor command line option.
Systems using processors not supporting XSAVE are not vulnerable.
Xen 3.x and earlier are not vulnerable.
MITIGATION
==
Turning off XSAVE support via the “no-xsave” hypervisor command line
option will avoid the vulnerability.
RESOLUTION
==
Applying the attached patch resolves this issue.
xsa54.patch Xen 4.1.x, Xen 4.2.x, xen-unstable
$ sha256sum xsa54-\*.patch
5d94946b3c9cba52aae2bffd4b0ebb11d09181650b5322a3c85170674a05f6b7
xsa54.patch
$
*(from redmine: issue id 2054, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* child #2055
* child #2058
* child #2057
* child #2056
* Changesets:
* Revision f6e99451d47fbe7cdb852f48dd11006808db52ae by Natanael Copa on 2013-06-04T11:30:54Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
```
* Revision 793a2f362351c53c4175ab2cc395a92d6d83b209 by Natanael Copa on 2013-06-04T11:57:28Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2045
fixes #2050
fixes #2055
(cherry picked from commit f6e99451d47fbe7cdb852f48dd11006808db52ae)
```
* Revision e466dbbf828a8e83c3f34d7311afcaf02e1d2408 by Natanael Copa on 2013-06-05T15:04:11Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2046
fixes #2051
fixes #2056
(cherry picked from commit f6e99451d47fbe7cdb852f48dd11006808db52ae)
Conflicts:
main/xen/APKBUILD
```
* Revision a2883b66233b3bc958ccb3555996adeacd070c64 by Natanael Copa on 2013-06-05T15:08:29Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2047
fixes #2052
fixes #2057
```
* Revision 9da25b8784e5b39b905e86bdb94e5a0026f10bd4 by Natanael Copa on 2013-06-05T15:21:46Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2048
fixes #2053
fixes #2058
```
* Uploads:
* [xsa54.patch](/uploads/384ee1e9b0f4f17393c3e3a7caa32e80/xsa54.patch)Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2055[v2.6] xen CVE-2013-2078 Hypervisor crash due to missing exception recovery o...2019-07-23T14:21:31ZPeter Kotcauer[v2.6] xen CVE-2013-2078 Hypervisor crash due to missing exception recovery on XSETBVreference:
http://www.openwall.com/lists/oss-security/2013/06/03/3
ISSUE DESCRIPTION
=
Processors do certain validity checks on the register values passed to
XSETBV. For the PV emulation path for that instruction the hypervisor ...reference:
http://www.openwall.com/lists/oss-security/2013/06/03/3
ISSUE DESCRIPTION
=
Processors do certain validity checks on the register values passed to
XSETBV. For the PV emulation path for that instruction the hypervisor
code didn’t check for certain invalid bit combinations, thus exposing
itself to a fault occurring when invoking that instruction on behalf
of the guest.
IMPACT
==
Malicious or buggy unprivileged user space can cause the entire host
to crash.
VULNERABLE SYSTEMS
==
Xen 4.0 and onwards are vulnerable when run on systems with processors
supporting XSAVE. Only PV guests can exploit the vulnerability.
In Xen 4.0.2 through 4.0.4 as well as in Xen 4.1.x XSAVE support is
disabled by default; therefore systems running these versions are not
vulnerable unless support is explicitly enabled using the “xsave”
hypervisor command line option.
Systems using processors not supporting XSAVE are not vulnerable.
Xen 3.x and earlier are not vulnerable.
MITIGATION
==
Turning off XSAVE support via the “no-xsave” hypervisor command line
option will avoid the vulnerability.
RESOLUTION
==
Applying the attached patch resolves this issue.
xsa54.patch Xen 4.1.x, Xen 4.2.x, xen-unstable
$ sha256sum xsa54-\*.patch
5d94946b3c9cba52aae2bffd4b0ebb11d09181650b5322a3c85170674a05f6b7
xsa54.patch
$
*(from redmine: issue id 2055, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* parent #2054
* Changesets:
* Revision 793a2f362351c53c4175ab2cc395a92d6d83b209 by Natanael Copa on 2013-06-04T11:57:28Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2045
fixes #2050
fixes #2055
(cherry picked from commit f6e99451d47fbe7cdb852f48dd11006808db52ae)
```
* Uploads:
* [xsa54.patch](/uploads/f84b81dbb0d71ab64df3a1b19b4901b4/xsa54.patch)Alpine 2.6.1Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2056[v2.5] xen CVE-2013-2078 Hypervisor crash due to missing exception recovery o...2019-07-23T14:21:30ZPeter Kotcauer[v2.5] xen CVE-2013-2078 Hypervisor crash due to missing exception recovery on XSETBVreference:
http://www.openwall.com/lists/oss-security/2013/06/03/3
ISSUE DESCRIPTION
=
Processors do certain validity checks on the register values passed to
XSETBV. For the PV emulation path for that instruction the hypervisor ...reference:
http://www.openwall.com/lists/oss-security/2013/06/03/3
ISSUE DESCRIPTION
=
Processors do certain validity checks on the register values passed to
XSETBV. For the PV emulation path for that instruction the hypervisor
code didn’t check for certain invalid bit combinations, thus exposing
itself to a fault occurring when invoking that instruction on behalf
of the guest.
IMPACT
==
Malicious or buggy unprivileged user space can cause the entire host
to crash.
VULNERABLE SYSTEMS
==
Xen 4.0 and onwards are vulnerable when run on systems with processors
supporting XSAVE. Only PV guests can exploit the vulnerability.
In Xen 4.0.2 through 4.0.4 as well as in Xen 4.1.x XSAVE support is
disabled by default; therefore systems running these versions are not
vulnerable unless support is explicitly enabled using the “xsave”
hypervisor command line option.
Systems using processors not supporting XSAVE are not vulnerable.
Xen 3.x and earlier are not vulnerable.
MITIGATION
==
Turning off XSAVE support via the “no-xsave” hypervisor command line
option will avoid the vulnerability.
RESOLUTION
==
Applying the attached patch resolves this issue.
xsa54.patch Xen 4.1.x, Xen 4.2.x, xen-unstable
$ sha256sum xsa54-\*.patch
5d94946b3c9cba52aae2bffd4b0ebb11d09181650b5322a3c85170674a05f6b7
xsa54.patch
$
*(from redmine: issue id 2056, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* parent #2054
* Changesets:
* Revision e466dbbf828a8e83c3f34d7311afcaf02e1d2408 by Natanael Copa on 2013-06-05T15:04:11Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2046
fixes #2051
fixes #2056
(cherry picked from commit f6e99451d47fbe7cdb852f48dd11006808db52ae)
Conflicts:
main/xen/APKBUILD
```
* Uploads:
* [xsa54.patch](/uploads/3ef9e604b2eea8d0f5a8ec4dd6f20fe1/xsa54.patch)Alpine 2.5.5Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2057[v2.4] xen CVE-2013-2078 Hypervisor crash due to missing exception recovery o...2019-07-23T14:21:29ZPeter Kotcauer[v2.4] xen CVE-2013-2078 Hypervisor crash due to missing exception recovery on XSETBVreference:
http://www.openwall.com/lists/oss-security/2013/06/03/3
ISSUE DESCRIPTION
=
Processors do certain validity checks on the register values passed to
XSETBV. For the PV emulation path for that instruction the hypervisor ...reference:
http://www.openwall.com/lists/oss-security/2013/06/03/3
ISSUE DESCRIPTION
=
Processors do certain validity checks on the register values passed to
XSETBV. For the PV emulation path for that instruction the hypervisor
code didn’t check for certain invalid bit combinations, thus exposing
itself to a fault occurring when invoking that instruction on behalf
of the guest.
IMPACT
==
Malicious or buggy unprivileged user space can cause the entire host
to crash.
VULNERABLE SYSTEMS
==
Xen 4.0 and onwards are vulnerable when run on systems with processors
supporting XSAVE. Only PV guests can exploit the vulnerability.
In Xen 4.0.2 through 4.0.4 as well as in Xen 4.1.x XSAVE support is
disabled by default; therefore systems running these versions are not
vulnerable unless support is explicitly enabled using the “xsave”
hypervisor command line option.
Systems using processors not supporting XSAVE are not vulnerable.
Xen 3.x and earlier are not vulnerable.
MITIGATION
==
Turning off XSAVE support via the “no-xsave” hypervisor command line
option will avoid the vulnerability.
RESOLUTION
==
Applying the attached patch resolves this issue.
xsa54.patch Xen 4.1.x, Xen 4.2.x, xen-unstable
$ sha256sum xsa54-\*.patch
5d94946b3c9cba52aae2bffd4b0ebb11d09181650b5322a3c85170674a05f6b7
xsa54.patch
$
*(from redmine: issue id 2057, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* parent #2054
* Changesets:
* Revision a2883b66233b3bc958ccb3555996adeacd070c64 by Natanael Copa on 2013-06-05T15:08:29Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2047
fixes #2052
fixes #2057
```
* Uploads:
* [xsa54.patch](/uploads/c22094e4e9977acbe2535ba424100d4e/xsa54.patch)Alpine 2.4.12Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2058[v2.3] xen CVE-2013-2078 Hypervisor crash due to missing exception recovery o...2019-07-23T14:21:28ZPeter Kotcauer[v2.3] xen CVE-2013-2078 Hypervisor crash due to missing exception recovery on XSETBVreference:
http://www.openwall.com/lists/oss-security/2013/06/03/3
ISSUE DESCRIPTION
=
Processors do certain validity checks on the register values passed to
XSETBV. For the PV emulation path for that instruction the hypervisor ...reference:
http://www.openwall.com/lists/oss-security/2013/06/03/3
ISSUE DESCRIPTION
=
Processors do certain validity checks on the register values passed to
XSETBV. For the PV emulation path for that instruction the hypervisor
code didn’t check for certain invalid bit combinations, thus exposing
itself to a fault occurring when invoking that instruction on behalf
of the guest.
IMPACT
==
Malicious or buggy unprivileged user space can cause the entire host
to crash.
VULNERABLE SYSTEMS
==
Xen 4.0 and onwards are vulnerable when run on systems with processors
supporting XSAVE. Only PV guests can exploit the vulnerability.
In Xen 4.0.2 through 4.0.4 as well as in Xen 4.1.x XSAVE support is
disabled by default; therefore systems running these versions are not
vulnerable unless support is explicitly enabled using the “xsave”
hypervisor command line option.
Systems using processors not supporting XSAVE are not vulnerable.
Xen 3.x and earlier are not vulnerable.
MITIGATION
==
Turning off XSAVE support via the “no-xsave” hypervisor command line
option will avoid the vulnerability.
RESOLUTION
==
Applying the attached patch resolves this issue.
xsa54.patch Xen 4.1.x, Xen 4.2.x, xen-unstable
$ sha256sum xsa54-\*.patch
5d94946b3c9cba52aae2bffd4b0ebb11d09181650b5322a3c85170674a05f6b7
xsa54.patch
$
*(from redmine: issue id 2058, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* parent #2054
* Changesets:
* Revision 9da25b8784e5b39b905e86bdb94e5a0026f10bd4 by Natanael Copa on 2013-06-05T15:21:46Z:
```
main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)
ref #2044
ref #2049
ref #2054
fixes #2048
fixes #2053
fixes #2058
```
* Uploads:
* [xsa54.patch](/uploads/d8c759bdc6e8dbd52ee60088a996d080/xsa54.patch)Alpine 2.3.7Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2059qemu CVE-2013-2007: guest agent creates files with insecure permissions in de...2019-07-23T14:21:27ZPeter Kotcauerqemu CVE-2013-2007: guest agent creates files with insecure permissions in deamon modereferences:
http://www.openwall.com/lists/oss-security/2013/05/06/5
https://bugzilla.redhat.com/show\_bug.cgi?id=956082\#c6
upstream fix:
http://git.qemu.org/?p=qemu.git;a=commit;h=c689b4f1bac352dcfd6ecb9a1d45337de0f1de67
DESCRIPTI...references:
http://www.openwall.com/lists/oss-security/2013/05/06/5
https://bugzilla.redhat.com/show\_bug.cgi?id=956082\#c6
upstream fix:
http://git.qemu.org/?p=qemu.git;a=commit;h=c689b4f1bac352dcfd6ecb9a1d45337de0f1de67
DESCRIPTION ==
The upstream qemu guest agent creates files with insecure permissions
when started in daemon mode, which could potentially lead local
privilege escalation.
The Red Hat Enterprise Linux 6 qemu-ga, when started in daemon mode,
creates logfiles in /var/log/ world writable allowing any one on the
system to wipe the contents of the log file or to store data within the
log file. An unprivileged guest user could use this flaw to consume all
free space on the partition
with qemu-ga log file, or modify the contents of the log. When a UNIX
domain socket transport were explicitly configured to be used
(non-default), an unprivileged guest user could potentially use this
flaw to escalate their privileges in the guest.
Acknowledgements:
This issue was discovered by Laszlo Ersek of Red Hat.
*(from redmine: issue id 2059, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* child #2060
* child #2061
* child #2062
* child #2063
* Changesets:
* Revision 0a719315035072323f00ba0aadcf16849598923f by Natanael Copa on 2013-06-05T11:30:09Z:
```
main/qemu: fix 2013-2007
ref #2059
fixes #2061
```
* Revision 563e2f3d73036c1b799204edd5a7742c90ee711d by Natanael Copa on 2013-06-05T12:02:17Z:
```
main/qemu: security fix CVE-2013-2007
ref #2059
fixes #2063
```
* Revision ef7cc55e6635a229f49ae024c7b4f92945b1aa2d by Natanael Copa on 2013-06-05T13:01:01Z:
```
main/qemu: security fix CVE-2013-2007
ref #2059
fixes #2062
```Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2060[v2.6] qemu CVE-2013-2007: guest agent creates files with insecure permission...2019-07-23T14:21:26ZPeter Kotcauer[v2.6] qemu CVE-2013-2007: guest agent creates files with insecure permissions in deamon modereferences:
http://www.openwall.com/lists/oss-security/2013/05/06/5
https://bugzilla.redhat.com/show\_bug.cgi?id=956082\#c6
upstream fix:
http://git.qemu.org/?p=qemu.git;a=commit;h=c689b4f1bac352dcfd6ecb9a1d45337de0f1de67
DESCRIPTI...references:
http://www.openwall.com/lists/oss-security/2013/05/06/5
https://bugzilla.redhat.com/show\_bug.cgi?id=956082\#c6
upstream fix:
http://git.qemu.org/?p=qemu.git;a=commit;h=c689b4f1bac352dcfd6ecb9a1d45337de0f1de67
DESCRIPTION ==
The upstream qemu guest agent creates files with insecure permissions
when started in daemon mode, which could potentially lead local
privilege escalation.
The Red Hat Enterprise Linux 6 qemu-ga, when started in daemon mode,
creates logfiles in /var/log/ world writable allowing any one on the
system to wipe the contents of the log file or to store data within the
log file. An unprivileged guest user could use this flaw to consume all
free space on the partition
with qemu-ga log file, or modify the contents of the log. When a UNIX
domain socket transport were explicitly configured to be used
(non-default), an unprivileged guest user could potentially use this
flaw to escalate their privileges in the guest.
Acknowledgements:
This issue was discovered by Laszlo Ersek of Red Hat.
*(from redmine: issue id 2060, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* parent #2059
* Changesets:
* Revision 3fe8d5a2ee5d338106f55639b69337377618e91b by Natanael Copa on 2013-06-04T10:53:28Z:
```
main/qemu: security upgrade to 1.4.2 (CVE-2013-2007)
fixes #2060
```Alpine 2.6.1Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2061[v2.5] qemu CVE-2013-2007: guest agent creates files with insecure permission...2019-07-23T14:21:25ZPeter Kotcauer[v2.5] qemu CVE-2013-2007: guest agent creates files with insecure permissions in deamon modereferences:
http://www.openwall.com/lists/oss-security/2013/05/06/5
https://bugzilla.redhat.com/show\_bug.cgi?id=956082\#c6
upstream fix:
http://git.qemu.org/?p=qemu.git;a=commit;h=c689b4f1bac352dcfd6ecb9a1d45337de0f1de67
DESCRIPTI...references:
http://www.openwall.com/lists/oss-security/2013/05/06/5
https://bugzilla.redhat.com/show\_bug.cgi?id=956082\#c6
upstream fix:
http://git.qemu.org/?p=qemu.git;a=commit;h=c689b4f1bac352dcfd6ecb9a1d45337de0f1de67
DESCRIPTION ==
The upstream qemu guest agent creates files with insecure permissions
when started in daemon mode, which could potentially lead local
privilege escalation.
The Red Hat Enterprise Linux 6 qemu-ga, when started in daemon mode,
creates logfiles in /var/log/ world writable allowing any one on the
system to wipe the contents of the log file or to store data within the
log file. An unprivileged guest user could use this flaw to consume all
free space on the partition
with qemu-ga log file, or modify the contents of the log. When a UNIX
domain socket transport were explicitly configured to be used
(non-default), an unprivileged guest user could potentially use this
flaw to escalate their privileges in the guest.
Acknowledgements:
This issue was discovered by Laszlo Ersek of Red Hat.
*(from redmine: issue id 2061, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* parent #2059
* Changesets:
* Revision 0a719315035072323f00ba0aadcf16849598923f by Natanael Copa on 2013-06-05T11:30:09Z:
```
main/qemu: fix 2013-2007
ref #2059
fixes #2061
```Alpine 2.5.5Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2062[v2.4] qemu CVE-2013-2007: guest agent creates files with insecure permission...2019-07-23T14:21:24ZPeter Kotcauer[v2.4] qemu CVE-2013-2007: guest agent creates files with insecure permissions in deamon modereferences:
http://www.openwall.com/lists/oss-security/2013/05/06/5
https://bugzilla.redhat.com/show\_bug.cgi?id=956082\#c6
upstream fix:
http://git.qemu.org/?p=qemu.git;a=commit;h=c689b4f1bac352dcfd6ecb9a1d45337de0f1de67
DESCRIPTI...references:
http://www.openwall.com/lists/oss-security/2013/05/06/5
https://bugzilla.redhat.com/show\_bug.cgi?id=956082\#c6
upstream fix:
http://git.qemu.org/?p=qemu.git;a=commit;h=c689b4f1bac352dcfd6ecb9a1d45337de0f1de67
DESCRIPTION ==
The upstream qemu guest agent creates files with insecure permissions
when started in daemon mode, which could potentially lead local
privilege escalation.
The Red Hat Enterprise Linux 6 qemu-ga, when started in daemon mode,
creates logfiles in /var/log/ world writable allowing any one on the
system to wipe the contents of the log file or to store data within the
log file. An unprivileged guest user could use this flaw to consume all
free space on the partition
with qemu-ga log file, or modify the contents of the log. When a UNIX
domain socket transport were explicitly configured to be used
(non-default), an unprivileged guest user could potentially use this
flaw to escalate their privileges in the guest.
Acknowledgements:
This issue was discovered by Laszlo Ersek of Red Hat.
*(from redmine: issue id 2062, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* parent #2059
* Changesets:
* Revision ef7cc55e6635a229f49ae024c7b4f92945b1aa2d by Natanael Copa on 2013-06-05T13:01:01Z:
```
main/qemu: security fix CVE-2013-2007
ref #2059
fixes #2062
```Alpine 2.4.12Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2063[v2.3] qemu CVE-2013-2007: guest agent creates files with insecure permission...2019-07-23T14:21:23ZPeter Kotcauer[v2.3] qemu CVE-2013-2007: guest agent creates files with insecure permissions in deamon modereferences:
http://www.openwall.com/lists/oss-security/2013/05/06/5
https://bugzilla.redhat.com/show\_bug.cgi?id=956082\#c6
upstream fix:
http://git.qemu.org/?p=qemu.git;a=commit;h=c689b4f1bac352dcfd6ecb9a1d45337de0f1de67
DESCRIPTI...references:
http://www.openwall.com/lists/oss-security/2013/05/06/5
https://bugzilla.redhat.com/show\_bug.cgi?id=956082\#c6
upstream fix:
http://git.qemu.org/?p=qemu.git;a=commit;h=c689b4f1bac352dcfd6ecb9a1d45337de0f1de67
DESCRIPTION ==
The upstream qemu guest agent creates files with insecure permissions
when started in daemon mode, which could potentially lead local
privilege escalation.
The Red Hat Enterprise Linux 6 qemu-ga, when started in daemon mode,
creates logfiles in /var/log/ world writable allowing any one on the
system to wipe the contents of the log file or to store data within the
log file. An unprivileged guest user could use this flaw to consume all
free space on the partition
with qemu-ga log file, or modify the contents of the log. When a UNIX
domain socket transport were explicitly configured to be used
(non-default), an unprivileged guest user could potentially use this
flaw to escalate their privileges in the guest.
Acknowledgements:
This issue was discovered by Laszlo Ersek of Red Hat.
*(from redmine: issue id 2063, created on 2013-06-03, closed on 2013-06-06)*
* Relations:
* parent #2059
* Changesets:
* Revision 563e2f3d73036c1b799204edd5a7742c90ee711d by Natanael Copa on 2013-06-05T12:02:17Z:
```
main/qemu: security fix CVE-2013-2007
ref #2059
fixes #2063
```Alpine 2.3.7Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2064userskins link invalid2019-07-23T14:21:22ZJan-Hendrik Dörneruserskins link invalidAfter a normal setup I see a symbolic link from
/usr/shar/acf/www/userskins to /etc/acf/skins, but this directory does
not exist.
(I think I saw this bug in pre 2.6.0 versions as well.)
*(from redmine: issue id 2064, created on 2013-...After a normal setup I see a symbolic link from
/usr/shar/acf/www/userskins to /etc/acf/skins, but this directory does
not exist.
(I think I saw this bug in pre 2.6.0 versions as well.)
*(from redmine: issue id 2064, created on 2013-06-04, closed on 2013-08-06)*
* Changesets:
* Revision 1ffa83ee5db171b8e38ce7b3ef187565c8e11b54 by Natanael Copa on 2013-07-03T08:33:32Z:
```
main/acf-core: create /etc/acf/skins directory
ref #2064
```
* Revision 077f36e3ecdfe1b065d4a496b78875e1dec773c3 by Natanael Copa on 2013-07-11T13:54:23Z:
```
main/acf-core: create /etc/acf/skins directory
fixes #2064
```
* Revision ffba227d985b7eb50bb5e1828459e91e27d00773 by Natanael Copa on 2013-08-28T08:12:29Z:
```
main/acf-core: create /etc/acf/skins directory
ref #2064
(cherry picked from commit 1ffa83ee5db171b8e38ce7b3ef187565c8e11b54)
```Alpine 2.6.3Ted TraskTed Trask2013-08-05https://gitlab.alpinelinux.org/alpine/aports/-/issues/2065dovecot-logrotate2019-07-23T14:21:21Zalgitbotdovecot-logrotateThe dovecot package should be split so one package has logrotate listed
as a depend and one does not.
*(from redmine: issue id 2065, created on 2013-06-04, closed on 2013-08-06)*
* Changesets:
* Revision 4808497ef7054c04f8e985b22cbf...The dovecot package should be split so one package has logrotate listed
as a depend and one does not.
*(from redmine: issue id 2065, created on 2013-06-04, closed on 2013-08-06)*
* Changesets:
* Revision 4808497ef7054c04f8e985b22cbf86f59aa103f5 by Natanael Copa on 2013-06-12T13:19:22Z:
```
main/dovecot: do not depend on logrotate
use of logrotate should be optional
fixes #2065
```Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2074Package request: module to concatenate files together in webservers2019-07-23T14:21:13ZV KrishnPackage request: module to concatenate files together in webserversAdd mod\_concat modules for webservers.
mod\_conat: improves the overall http request time.
URLs:
lighttpd: http://code.google.com/p/lighttpd-mod-concat
apache2: http://code.google.com/p/modconcat/
*(from redmine: issue id 2074,...Add mod\_concat modules for webservers.
mod\_conat: improves the overall http request time.
URLs:
lighttpd: http://code.google.com/p/lighttpd-mod-concat
apache2: http://code.google.com/p/modconcat/
*(from redmine: issue id 2074, created on 2013-06-07, closed on 2019-05-03)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/2075Java Runtime Environment Fails with SIGSEGV2019-07-23T14:21:11ZRichard JohnsonJava Runtime Environment Fails with SIGSEGVI
tried to run a precompiled class file, which resulted in the following
error:
Error occurred during initialization of VM
Could not reserve enough space for object heap
More Details:
\- I have installed this instance of alpine f...I
tried to run a precompiled class file, which resulted in the following
error:
Error occurred during initialization of VM
Could not reserve enough space for object heap
More Details:
\- I have installed this instance of alpine from
alpine-xen-2.6.0\_rc3-x86\_64.iso,
However I did “apk upgrade” just after installing the JRE.
\- I am running Java in dom0
\- I have allocated more than 800MB for dom0
\- Even when running trivial commands such as “java -version” I get the
same
error message
- My goal is to run a Swing application in the X environment
The Test case is attached
*(from redmine: issue id 2075, created on 2013-06-10, closed on 2013-07-03)*
* Changesets:
* Revision 6da42db662737f4c7d76b27bafb754717667772a by Timo Teräs on 2013-06-10T16:51:42Z:
```
main/openjdk6: fix ipv6 related startup crash
fixes #2075
(cherry picked from commit a733d5ca3c5b38a12b6d7a185325ee4bbe65a749)
Conflicts:
main/openjdk6/APKBUILD
```
* Revision b89cea880276f1791d948a779161687e13d56039 by Timo Teräs on 2013-06-11T15:02:09Z:
```
main/openjdk6: fix ipv6 related startup crash
ref #2075
(cherry picked from commit a733d5ca3c5b38a12b6d7a185325ee4bbe65a749)
```
* Uploads:
* [Test.java](/uploads/937320df32c00847a8a0d2faca162c21/Test.java)
* [logs.zip](/uploads/6b56630ce3b38e038830c00e750622d7/logs.zip)Alpine 2.4.12Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2076Request for additional kernel feature - zram, zcache, and zswap2022-02-27T00:10:43ZV KrishnRequest for additional kernel feature - zram, zcache, and zswapKindly evaluate following in-kernal memory-compression i.e. zram,
zcache, and zswap
InfoUrl:
http://lwn.net/Articles/545244/
zram seems quite stable, if possible have it enabled.
*(from redmine: issue id 2076, created on 2013-06-10...Kindly evaluate following in-kernal memory-compression i.e. zram,
zcache, and zswap
InfoUrl:
http://lwn.net/Articles/545244/
zram seems quite stable, if possible have it enabled.
*(from redmine: issue id 2076, created on 2013-06-10, closed on 2014-05-30)*
* Changesets:
* Revision baf906cc51bdd0fba6928bb252eb4120821b290f by Natanael Copa on 2014-05-07T11:21:14Z:
```
main/linux-grsec: upgrade to 3.14.2
fixes #2076
```3.0.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/2077CVE-2013-2164 Linux Kernel - Leak information in cdrom driver2019-07-23T14:21:09ZPeter KotcauerCVE-2013-2164 Linux Kernel - Leak information in cdrom driverupstream fix:
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/cdrom/cdrom.c?id=050e4b8fb7cdd7096c987a9cd556029c622c7fe2
In drivers/cdrom/cdrom.c mmc\_ioctl\_cdrom\_read\_data() allocates a
memory
area ...upstream fix:
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/cdrom/cdrom.c?id=050e4b8fb7cdd7096c987a9cd556029c622c7fe2
In drivers/cdrom/cdrom.c mmc\_ioctl\_cdrom\_read\_data() allocates a
memory
area with kmalloc in line 2885.
2885 cgc->buffer = kmalloc(blocksize, GFP\_KERNEL);
2886 if (cgc->buffer == NULL)
2887 return -ENOMEM;
In line 2908 we can find the copy\_to\_user function:
2908 if (!ret && copy\_to\_user(arg, cgc->buffer, blocksize))
The cgc->buffer is never cleaned and initialized before this
function. If
ret = 0 with the previous basic block, it’s possible to display some
memory bytes in kernel space from userspace.
When we read a block from the disk it normally fills the ->buffer but
if
the drive is malfunctioning there is a chance that it would only be
partially filled. The result is an leak information to userspace.
*(from redmine: issue id 2077, created on 2013-06-10, closed on 2013-07-03)*
* Relations:
* child #2078
* child #2079
* child #2082
* child #2083
* Changesets:
* Revision f84874803ecddea53abaa8b2ae68a789794c359f by Natanael Copa on 2013-06-26T11:55:04Z:
```
main/linux-grsec: security fix (CVE-2013-2164)
ref #2077
fixes #2082
```
* Revision 25d456a566f8d7bdc343a3a55219b23a29433f5f by Natanael Copa on 2013-06-26T14:10:30Z:
```
main/linux-grsec: security fixes (CVE-2013-2164,CVE-2013-2851,CVE-2013-2852)
ref #2077
ref #2088
ref #2093
fixes #2083
fixes #2092
fixes #2097
```Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2078[v2.6] CVE-2013-2164 Linux Kernel - Leak information in cdrom driver2019-07-23T14:21:08ZPeter Kotcauer[v2.6] CVE-2013-2164 Linux Kernel - Leak information in cdrom driverupstream fix:
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/cdrom/cdrom.c?id=050e4b8fb7cdd7096c987a9cd556029c622c7fe2
In drivers/cdrom/cdrom.c mmc\_ioctl\_cdrom\_read\_data() allocates a
memory
area ...upstream fix:
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/cdrom/cdrom.c?id=050e4b8fb7cdd7096c987a9cd556029c622c7fe2
In drivers/cdrom/cdrom.c mmc\_ioctl\_cdrom\_read\_data() allocates a
memory
area with kmalloc in line 2885.
2885 cgc->buffer = kmalloc(blocksize, GFP\_KERNEL);
2886 if (cgc->buffer == NULL)
2887 return -ENOMEM;
In line 2908 we can find the copy\_to\_user function:
2908 if (!ret && copy\_to\_user(arg, cgc->buffer, blocksize))
The cgc->buffer is never cleaned and initialized before this
function. If
ret = 0 with the previous basic block, it’s possible to display some
memory bytes in kernel space from userspace.
When we read a block from the disk it normally fills the ->buffer but
if
the drive is malfunctioning there is a chance that it would only be
partially filled. The result is an leak information to userspace.
*(from redmine: issue id 2078, created on 2013-06-10, closed on 2013-07-02)*
* Relations:
* parent #2077
* Changesets:
* Revision f535ac0d0ba8351b98b4658280277391bf4e03c1 by Natanael Copa on 2013-06-19T08:38:19Z:
```
main/linux-grsec: upgrade to 3.9.5
(cherry picked from commit 26c4e189e825d62d0249fb5f499bcb545d40e1ab)
fixes #2078
```
* Revision bcbc45908a6264b88bb5f2f62f182f27d167bcf8 by Natanael Copa on 2013-06-19T08:38:20Z:
```
main/linux-grsec: upgrade to 3.9.6 and fix CVE-2013-2851
fixes #2078
fixes #2089
fixes #2094
(cherry picked from commit b52eb6193eb9c18980886ff25d2e4e41dd887078)
```Alpine 2.6.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2079[v2.5] CVE-2013-2164 Linux Kernel - Leak information in cdrom driver2019-07-23T14:21:07ZPeter Kotcauer[v2.5] CVE-2013-2164 Linux Kernel - Leak information in cdrom driverupstream fix:
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/cdrom/cdrom.c?id=050e4b8fb7cdd7096c987a9cd556029c622c7fe2
In drivers/cdrom/cdrom.c mmc\_ioctl\_cdrom\_read\_data() allocates a
memory
area ...upstream fix:
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/cdrom/cdrom.c?id=050e4b8fb7cdd7096c987a9cd556029c622c7fe2
In drivers/cdrom/cdrom.c mmc\_ioctl\_cdrom\_read\_data() allocates a
memory
area with kmalloc in line 2885.
2885 cgc->buffer = kmalloc(blocksize, GFP\_KERNEL);
2886 if (cgc->buffer == NULL)
2887 return -ENOMEM;
In line 2908 we can find the copy\_to\_user function:
2908 if (!ret && copy\_to\_user(arg, cgc->buffer, blocksize))
The cgc->buffer is never cleaned and initialized before this
function. If
ret = 0 with the previous basic block, it’s possible to display some
memory bytes in kernel space from userspace.
When we read a block from the disk it normally fills the ->buffer but
if
the drive is malfunctioning there is a chance that it would only be
partially filled. The result is an leak information to userspace.
*(from redmine: issue id 2079, created on 2013-06-10, closed on 2013-06-21)*
* Relations:
* parent #2077
* Changesets:
* Revision 8522b076581da9643a6adcb4a1177d9ede8b9977 by Natanael Copa on 2013-06-18T15:21:24Z:
```
main/linux-grsec: fix CVE-2013-2164,CVE-2013-2851,CVE-2013-2052
fixes #2079
fixes #2090
fixes #2093
```Alpine 2.5.5Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2082[v2.4] CVE-2013-2164 Linux Kernel - Leak information in cdrom driver2019-07-23T14:21:06ZPeter Kotcauer[v2.4] CVE-2013-2164 Linux Kernel - Leak information in cdrom driverupstream fix:
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/cdrom/cdrom.c?id=050e4b8fb7cdd7096c987a9cd556029c622c7fe2
In drivers/cdrom/cdrom.c mmc\_ioctl\_cdrom\_read\_data() allocates a
memory
area ...upstream fix:
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/cdrom/cdrom.c?id=050e4b8fb7cdd7096c987a9cd556029c622c7fe2
In drivers/cdrom/cdrom.c mmc\_ioctl\_cdrom\_read\_data() allocates a
memory
area with kmalloc in line 2885.
2885 cgc->buffer = kmalloc(blocksize, GFP\_KERNEL);
2886 if (cgc->buffer == NULL)
2887 return -ENOMEM;
In line 2908 we can find the copy\_to\_user function:
2908 if (!ret && copy\_to\_user(arg, cgc->buffer, blocksize))
The cgc->buffer is never cleaned and initialized before this
function. If
ret = 0 with the previous basic block, it’s possible to display some
memory bytes in kernel space from userspace.
When we read a block from the disk it normally fills the ->buffer but
if
the drive is malfunctioning there is a chance that it would only be
partially filled. The result is an leak information to userspace.
*(from redmine: issue id 2082, created on 2013-06-10, closed on 2013-07-03)*
* Relations:
* parent #2077
* Changesets:
* Revision f84874803ecddea53abaa8b2ae68a789794c359f by Natanael Copa on 2013-06-26T11:55:04Z:
```
main/linux-grsec: security fix (CVE-2013-2164)
ref #2077
fixes #2082
```Alpine 2.4.12Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2083[v2.3] CVE-2013-2164 Linux Kernel - Leak information in cdrom driver2019-07-23T14:21:05ZPeter Kotcauer[v2.3] CVE-2013-2164 Linux Kernel - Leak information in cdrom driverupstream fix:
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/cdrom/cdrom.c?id=050e4b8fb7cdd7096c987a9cd556029c622c7fe2
In drivers/cdrom/cdrom.c mmc\_ioctl\_cdrom\_read\_data() allocates a
memory
area ...upstream fix:
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/cdrom/cdrom.c?id=050e4b8fb7cdd7096c987a9cd556029c622c7fe2
In drivers/cdrom/cdrom.c mmc\_ioctl\_cdrom\_read\_data() allocates a
memory
area with kmalloc in line 2885.
2885 cgc->buffer = kmalloc(blocksize, GFP\_KERNEL);
2886 if (cgc->buffer == NULL)
2887 return -ENOMEM;
In line 2908 we can find the copy\_to\_user function:
2908 if (!ret && copy\_to\_user(arg, cgc->buffer, blocksize))
The cgc->buffer is never cleaned and initialized before this
function. If
ret = 0 with the previous basic block, it’s possible to display some
memory bytes in kernel space from userspace.
When we read a block from the disk it normally fills the ->buffer but
if
the drive is malfunctioning there is a chance that it would only be
partially filled. The result is an leak information to userspace.
*(from redmine: issue id 2083, created on 2013-06-10, closed on 2013-07-03)*
* Relations:
* parent #2077
* Changesets:
* Revision 25d456a566f8d7bdc343a3a55219b23a29433f5f by Natanael Copa on 2013-06-26T14:10:30Z:
```
main/linux-grsec: security fixes (CVE-2013-2164,CVE-2013-2851,CVE-2013-2852)
ref #2077
ref #2088
ref #2093
fixes #2083
fixes #2092
fixes #2097
```Alpine 2.3.7Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2085Apache2 mod_ldap crashes2021-11-29T02:02:41ZJeff Bilykjbilyk@gmail.comApache2 mod_ldap crashesDuring a build on current edge to try to resolve a crash in mod\_ldap, I
received the following output. I’m not sure how to track down TEXTRELs
though.
>>>ERROR: apache2\*: Found textrels:
TEXTREL
/home/jbilyk/aports/main/apache...During a build on current edge to try to resolve a crash in mod\_ldap, I
received the following output. I’m not sure how to track down TEXTRELs
though.
>>>ERROR: apache2\*: Found textrels:
TEXTREL
/home/jbilyk/aports/main/apache2/pkg/apache2-ldap/usr/lib/apache2/mod\_ldap.so
TEXTREL
/home/jbilyk/aports/main/apache2/pkg/apache2-ldap/usr/lib/apache2/mod\_authnz\_ldap.so
>>>ERROR: apache2\*: prepare\_subpackages failed
>>>ERROR: apache2: all failed
However, the root issue I’m trying to fix is an apache
server(apache2-2.4.4-r0) with mod\_ldap(apache2-ldap-2.4.4-r0) enabled
crashes as soon as it tries to authenticate with mod\_ldap with the
following error (domain name has been replaced in the following logs and
config with example.com):
\[Thu Jun 13 18:39:15.411076 2013\] \[authnz\_ldap:debug\] \[pid 21921\]
mod\_authnz\_ldap.c(501): \[client 10.14.59.106:48231\] AH01691:
auth\_ldap authenticate: using URL
ldaps://example.com/dc=example,dc=com?sAMAccountName?sub?(objectClass=\*)
\[Thu Jun 13 18:39:15.411244 2013\] \[authnz\_ldap:info\] \[pid 21921\]
\[client 10.14.59.106:48231\] AH01695: auth\_ldap authenticate: user
jbilyk@example.com authentication failed; URI /racktables/ \[LDAP: ldap
initialization failed\]\[Unknown (private extension) error\]
Apache auth config on the virtual directory is:
AuthType Basic
AuthName “AD Authentication”
AuthBasicProvider ldap
AuthLDAPAuthoritative Off
AuthLDAPURL
“ldap://example.com:389/OU=testOU,DC=example,DC=com?sAMAccountName?sub?(objectClass=\*)”
AuthLDAPBindDN “CN=user,OU=Users,OU=testOU,DC=example,DC=com”
AuthLDAPBindPassword passforuser
Require valid-user
*(from redmine: issue id 2085, created on 2013-06-13, closed on 2013-06-26)*
* Changesets:
* Revision 23b112fa0b4c683178bf2038c2719d4889575ee1 by Natanael Copa on 2013-06-18T15:50:26Z:
```
main/apache2: fix deps for apache2-ldap
it needs apr-util-ldap
ref #2085
```
* Revision a628280d18a5ecf904c8498961e973fb82946389 by Natanael Copa on 2013-06-19T08:38:20Z:
```
main/apache2: fix deps for apache2-ldap
it needs apr-util-ldap
ref #2085
(cherry picked from commit 23b112fa0b4c683178bf2038c2719d4889575ee1)
```
* Revision 9974c43a8e517a749c44bf06b17e5f5fd5665f0f by Natanael Copa on 2013-06-19T12:56:17Z:
```
main/apache2: fix deps for apache2-ldap
it needs apr-util-ldap
fixes #2085
(cherry picked from commit 23b112fa0b4c683178bf2038c2719d4889575ee1)
```
* Uploads:
* [httpd.conf](/uploads/711100acd93b3a158bfaa972f49665a2/httpd.conf)
* [ssl.conf](/uploads/d6ac2a79674c9d430c99e10d57e71cd8/ssl.conf)
* [php5-module.conf](/uploads/3c2e937138fe4903920a5d4110aa4479/php5-module.conf)
* [mod-auth-radius.conf](/uploads/bda0ee735244ae80728e7754a1bb0719/mod-auth-radius.conf)Alpine 2.5.5Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2086Bacula-FD needs a link to libxz2021-11-29T02:02:41ZFlorian HeiglBacula-FD needs a link to libxzBacula has support for two compression algorithms since version 5.2.
The choice of algorithm is done server-side with a setting like this:
Include {
Options {
\#compression = GZIP1
compression = LZO }
… stuff …
}
So the age...Bacula has support for two compression algorithms since version 5.2.
The choice of algorithm is done server-side with a setting like this:
Include {
Options {
\#compression = GZIP1
compression = LZO }
… stuff …
}
So the agent (if of 5.2+ version) is just told “how” and “if” to
compress and if it doesn’t the link to the specifc compression algorythm
it’ll just turn off compression.
As a result, you get bigger and possibly slower backups.
The bacula-fd package would need to depend on some of these:
:~\# apk search xz
xz-dev-5.0.4-r1
xz-doc-5.0.4-r1
xz-libs-5.0.4-r1
xz-5.0.4-r1
I suspect dev and libs are enough.
ldd
checking sub-depends for ‘/usr/lib/libbacfind-5.2.12.so’
checking sub-depends for ‘/usr/lib/libbacpy-5.2.12.so’
checking sub-depends for ‘/usr/lib/libbaccfg-5.2.12.so’
checking sub-depends for ‘/usr/lib/libbac-5.2.12.so’
checking sub-depends for ‘/lib/libz.so.1’
checking sub-depends for ‘/lib/libpthread.so.0.9.32’
checking sub-depends for ‘/lib/libc.so.0.9.32’
checking sub-depends for ‘/lib/libdl.so.0.9.32’
checking sub-depends for ‘/lib/libssl.so.1.0.0’
checking sub-depends for ‘/lib/libcrypto.so.1.0.0’
checking sub-depends for ‘/usr/lib/libstdc<span
class="underline"></span>.so.6’
checking sub-depends for ‘/lib/libm.so.0.9.32’
checking sub-depends for ‘/usr/lib/libgcc\_s.so.1’
checking sub-depends for ‘/lib/libubacktrace.so.0.9.32’
libbacfind-5.2.12.so =>/usr/lib/libbacfind-5.2.12.so (0x00000000)
libbacpy-5.2.12.so =>/usr/lib/libbacpy-5.2.12.so (0x00000000)
libbaccfg-5.2.12.so =>/usr/lib/libbaccfg-5.2.12.so (0x00000000)
libbac-5.2.12.so =>/usr/lib/libbac-5.2.12.so (0x00000000)
libz.so.1 =>/lib/libz.so.1 (0x00000000)
libpthread.so.0.9.32 =>/lib/libpthread.so.0.9.32 (0x00000000)
libc.so.0.9.32 =>/lib/libc.so.0.9.32 (0x00000000)
libdl.so.0.9.32 =>/lib/libdl.so.0.9.32 (0x00000000)
libssl.so.1.0.0 =>/lib/libssl.so.1.0.0 (0x00000000)
libcrypto.so.1.0.0 =>/lib/libcrypto.so.1.0.0 (0x00000000)
libstdc<span class="underline"></span>.so.6 =>/usr/lib/libstdc<span
class="underline"></span>.so.6 (0x00000000)
libm.so.0.9.32 =>/lib/libm.so.0.9.32 (0x00000000)
libgcc\_s.so.1 =>/usr/lib/libgcc\_s.so.1 (0x00000000)
libubacktrace.so.0.9.32 =>/lib/libubacktrace.so.0.9.32
(0x00000000)
ld64-uClibc.so.0.9.32 =>ld64-uClibc.so.0.9.32 (0x00000000)
ld64-uClibc.so.0.9.32 =>ld64-uClibc.so.0.9.32 (0x00000000)
*(from redmine: issue id 2086, created on 2013-06-13, closed on 2013-07-03)*
* Changesets:
* Revision 8ffcd2e1271f9baf1831f8568df75d977e173073 by Carlo Landmeter on 2013-06-17T13:42:26Z:
```
main/bacula: add lzo support
fixes #2086
```
* Revision af657d90a1ff1118c8be76209ad3baeb078971b0 by Carlo Landmeter on 2013-07-03T08:26:03Z:
```
main/bacula: add lzo support
fixes #2086
(cherry picked from commit 8ffcd2e1271f9baf1831f8568df75d977e173073)
```Alpine 2.6.3Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2088CVE-2013-2852 Linux-Kernel: b43 wireless driver2019-07-23T14:21:01ZPeter KotcauerCVE-2013-2852 Linux-Kernel: b43 wireless driverThe b43 driver reports error strings that can be interpreted as format
strings. Under normal conditions, this is not a problem, but it is
possible for the “fwpostfix” module parameter to change the filenames
used to fetch firmware....The b43 driver reports error strings that can be interpreted as format
strings. Under normal conditions, this is not a problem, but it is
possible for the “fwpostfix” module parameter to change the filenames
used to fetch firmware. When such a file is not found, the filename
will be processed as a format string. This flaw could potentially
allow
escalation from uid-0 to ring-0, so except for certain environments,
it is not too serious.
If b43 hardware is available, this should show itself easily. I don’t
have
any available for testing, but it seems it would show itself like this:
1. rmmod b43
2. modprobe b43 fwpostfix=AA%xBB
…
3. dmesg
…
b43-0 ERROR: Firmware file “b43AAdeff80ccBB/a0g1bsinitvals5.fw” not
found
Using %n instead of %x would lead to exciting crashes. :)
It has been fixed in the upstream wireless tree:
http://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/commit/?id=9538cbaab6e8b8046039b4b2eb6c9d614dc782bd
*(from redmine: issue id 2088, created on 2013-06-18, closed on 2013-07-03)*
* Relations:
* child #2089
* child #2090
* child #2091
* child #2092
* Changesets:
* Revision 25d456a566f8d7bdc343a3a55219b23a29433f5f by Natanael Copa on 2013-06-26T14:10:30Z:
```
main/linux-grsec: security fixes (CVE-2013-2164,CVE-2013-2851,CVE-2013-2852)
ref #2077
ref #2088
ref #2093
fixes #2083
fixes #2092
fixes #2097
```Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2089[v2.6] CVE-2013-2852 Linux-Kernel: b43 wireless driver2019-07-23T14:21:00ZPeter Kotcauer[v2.6] CVE-2013-2852 Linux-Kernel: b43 wireless driverThe b43 driver reports error strings that can be interpreted as format
strings. Under normal conditions, this is not a problem, but it is
possible for the “fwpostfix” module parameter to change the filenames
used to fetch firmware....The b43 driver reports error strings that can be interpreted as format
strings. Under normal conditions, this is not a problem, but it is
possible for the “fwpostfix” module parameter to change the filenames
used to fetch firmware. When such a file is not found, the filename
will be processed as a format string. This flaw could potentially
allow
escalation from uid-0 to ring-0, so except for certain environments,
it is not too serious.
If b43 hardware is available, this should show itself easily. I don’t
have
any available for testing, but it seems it would show itself like this:
1. rmmod b43
2. modprobe b43 fwpostfix=AA%xBB
…
3. dmesg
…
b43-0 ERROR: Firmware file “b43AAdeff80ccBB/a0g1bsinitvals5.fw” not
found
Using %n instead of %x would lead to exciting crashes. :)
It has been fixed in the upstream wireless tree:
http://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/commit/?id=9538cbaab6e8b8046039b4b2eb6c9d614dc782bd
*(from redmine: issue id 2089, created on 2013-06-18, closed on 2013-07-02)*
* Relations:
* parent #2088
* Changesets:
* Revision bcbc45908a6264b88bb5f2f62f182f27d167bcf8 by Natanael Copa on 2013-06-19T08:38:20Z:
```
main/linux-grsec: upgrade to 3.9.6 and fix CVE-2013-2851
fixes #2078
fixes #2089
fixes #2094
(cherry picked from commit b52eb6193eb9c18980886ff25d2e4e41dd887078)
```Alpine 2.6.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2090[v2.5] CVE-2013-2852 Linux-Kernel: b43 wireless driver2019-07-23T14:20:59ZPeter Kotcauer[v2.5] CVE-2013-2852 Linux-Kernel: b43 wireless driverThe b43 driver reports error strings that can be interpreted as format
strings. Under normal conditions, this is not a problem, but it is
possible for the “fwpostfix” module parameter to change the filenames
used to fetch firmware....The b43 driver reports error strings that can be interpreted as format
strings. Under normal conditions, this is not a problem, but it is
possible for the “fwpostfix” module parameter to change the filenames
used to fetch firmware. When such a file is not found, the filename
will be processed as a format string. This flaw could potentially
allow
escalation from uid-0 to ring-0, so except for certain environments,
it is not too serious.
If b43 hardware is available, this should show itself easily. I don’t
have
any available for testing, but it seems it would show itself like this:
1. rmmod b43
2. modprobe b43 fwpostfix=AA%xBB
…
3. dmesg
…
b43-0 ERROR: Firmware file “b43AAdeff80ccBB/a0g1bsinitvals5.fw” not
found
Using %n instead of %x would lead to exciting crashes. :)
It has been fixed in the upstream wireless tree:
http://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/commit/?id=9538cbaab6e8b8046039b4b2eb6c9d614dc782bd
*(from redmine: issue id 2090, created on 2013-06-18, closed on 2013-07-03)*
* Relations:
* parent #2088
* Changesets:
* Revision 8522b076581da9643a6adcb4a1177d9ede8b9977 by Natanael Copa on 2013-06-18T15:21:24Z:
```
main/linux-grsec: fix CVE-2013-2164,CVE-2013-2851,CVE-2013-2052
fixes #2079
fixes #2090
fixes #2093
```Alpine 2.5.5Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2091[v2.4] CVE-2013-2852 Linux-Kernel: b43 wireless driver2019-07-23T14:20:58ZPeter Kotcauer[v2.4] CVE-2013-2852 Linux-Kernel: b43 wireless driverThe b43 driver reports error strings that can be interpreted as format
strings. Under normal conditions, this is not a problem, but it is
possible for the “fwpostfix” module parameter to change the filenames
used to fetch firmware....The b43 driver reports error strings that can be interpreted as format
strings. Under normal conditions, this is not a problem, but it is
possible for the “fwpostfix” module parameter to change the filenames
used to fetch firmware. When such a file is not found, the filename
will be processed as a format string. This flaw could potentially
allow
escalation from uid-0 to ring-0, so except for certain environments,
it is not too serious.
If b43 hardware is available, this should show itself easily. I don’t
have
any available for testing, but it seems it would show itself like this:
1. rmmod b43
2. modprobe b43 fwpostfix=AA%xBB
…
3. dmesg
…
b43-0 ERROR: Firmware file “b43AAdeff80ccBB/a0g1bsinitvals5.fw” not
found
Using %n instead of %x would lead to exciting crashes. :)
It has been fixed in the upstream wireless tree:
http://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/commit/?id=9538cbaab6e8b8046039b4b2eb6c9d614dc782bd
*(from redmine: issue id 2091, created on 2013-06-18, closed on 2013-07-03)*
* Relations:
* parent #2088
* Changesets:
* Revision fe9af505b4a99ba6560870a89e982299adb76b2b by Natanael Copa on 2013-06-21T16:20:03Z:
```
main/linux-grsec: upgrade to 3.4.50 kernel (CVE-2013-2851,CVE-2013-2852)
fixes #2091
fixes #2096
```Alpine 2.4.12Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2092[v2.3] CVE-2013-2852 Linux-Kernel: b43 wireless driver2019-07-23T14:20:58ZPeter Kotcauer[v2.3] CVE-2013-2852 Linux-Kernel: b43 wireless driverThe b43 driver reports error strings that can be interpreted as format
strings. Under normal conditions, this is not a problem, but it is
possible for the “fwpostfix” module parameter to change the filenames
used to fetch firmware....The b43 driver reports error strings that can be interpreted as format
strings. Under normal conditions, this is not a problem, but it is
possible for the “fwpostfix” module parameter to change the filenames
used to fetch firmware. When such a file is not found, the filename
will be processed as a format string. This flaw could potentially
allow
escalation from uid-0 to ring-0, so except for certain environments,
it is not too serious.
If b43 hardware is available, this should show itself easily. I don’t
have
any available for testing, but it seems it would show itself like this:
1. rmmod b43
2. modprobe b43 fwpostfix=AA%xBB
…
3. dmesg
…
b43-0 ERROR: Firmware file “b43AAdeff80ccBB/a0g1bsinitvals5.fw” not
found
Using %n instead of %x would lead to exciting crashes. :)
It has been fixed in the upstream wireless tree:
http://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/commit/?id=9538cbaab6e8b8046039b4b2eb6c9d614dc782bd
*(from redmine: issue id 2092, created on 2013-06-18, closed on 2013-07-03)*
* Relations:
* parent #2088
* Changesets:
* Revision 25d456a566f8d7bdc343a3a55219b23a29433f5f by Natanael Copa on 2013-06-26T14:10:30Z:
```
main/linux-grsec: security fixes (CVE-2013-2164,CVE-2013-2851,CVE-2013-2852)
ref #2077
ref #2088
ref #2093
fixes #2083
fixes #2092
fixes #2097
```Alpine 2.3.7Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2093CVE-2013-2851 Linux-Kernel: block layer2019-07-23T14:20:57ZPeter KotcauerCVE-2013-2851 Linux-Kernel: block layerThe block layer uses the “disk\_name” field as a format
string in a number of places. While this is normally not a problem due
to how disk names are created (statically or incrementally), there
is currently at least one way to defi...The block layer uses the “disk\_name” field as a format
string in a number of places. While this is normally not a problem due
to how disk names are created (statically or incrementally), there
is currently at least one way to define nearly arbitrary names via
md. Instead of filtering md, this should be fixed within the kernel’s
interfaces. This flaw could potentially allow escalation from uid-0 to
ring-0, so except for certain environments, it is not too serious.
The test case is trivial:
1. echo md\_%x.%x.%x.%x >/sys/module/md\_mod/parameters/new\_array
2. ls /dev/md\_\*
/dev/md\_c12cc370.df66d800.df66d80c.c13da45b
Using %n instead of %x leads to exciting crashes. :)
The fix has been sent upstream:
http://marc.info/?l=linux-kernel&m=137055204522556&w=2
With the above fixes, a series of additional format string related
clean
ups has also been sent upstream:
http://marc.info/?l=linux-kernel&m=137055207522563&w=2
*(from redmine: issue id 2093, created on 2013-06-18, closed on 2013-07-03)*
* Relations:
* child #2094
* child #2095
* child #2096
* child #2097
* Changesets:
* Revision 8522b076581da9643a6adcb4a1177d9ede8b9977 by Natanael Copa on 2013-06-18T15:21:24Z:
```
main/linux-grsec: fix CVE-2013-2164,CVE-2013-2851,CVE-2013-2052
fixes #2079
fixes #2090
fixes #2093
```
* Revision 25d456a566f8d7bdc343a3a55219b23a29433f5f by Natanael Copa on 2013-06-26T14:10:30Z:
```
main/linux-grsec: security fixes (CVE-2013-2164,CVE-2013-2851,CVE-2013-2852)
ref #2077
ref #2088
ref #2093
fixes #2083
fixes #2092
fixes #2097
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/2094[v2.6] CVE-2013-2851 Linux-Kernel: block layer2019-07-23T14:20:56ZPeter Kotcauer[v2.6] CVE-2013-2851 Linux-Kernel: block layerThe block layer uses the “disk\_name” field as a format
string in a number of places. While this is normally not a problem due
to how disk names are created (statically or incrementally), there
is currently at least one way to defi...The block layer uses the “disk\_name” field as a format
string in a number of places. While this is normally not a problem due
to how disk names are created (statically or incrementally), there
is currently at least one way to define nearly arbitrary names via
md. Instead of filtering md, this should be fixed within the kernel’s
interfaces. This flaw could potentially allow escalation from uid-0 to
ring-0, so except for certain environments, it is not too serious.
The test case is trivial:
1. echo md\_%x.%x.%x.%x >/sys/module/md\_mod/parameters/new\_array
2. ls /dev/md\_\*
/dev/md\_c12cc370.df66d800.df66d80c.c13da45b
Using %n instead of %x leads to exciting crashes. :)
The fix has been sent upstream:
http://marc.info/?l=linux-kernel&m=137055204522556&w=2
With the above fixes, a series of additional format string related
clean
ups has also been sent upstream:
http://marc.info/?l=linux-kernel&m=137055207522563&w=2
*(from redmine: issue id 2094, created on 2013-06-18, closed on 2013-07-02)*
* Relations:
* parent #2093
* Changesets:
* Revision bcbc45908a6264b88bb5f2f62f182f27d167bcf8 by Natanael Copa on 2013-06-19T08:38:20Z:
```
main/linux-grsec: upgrade to 3.9.6 and fix CVE-2013-2851
fixes #2078
fixes #2089
fixes #2094
(cherry picked from commit b52eb6193eb9c18980886ff25d2e4e41dd887078)
```Alpine 2.6.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2095[v2.5] CVE-2013-2851 Linux-Kernel: block layer2019-07-23T14:20:55ZPeter Kotcauer[v2.5] CVE-2013-2851 Linux-Kernel: block layerThe block layer uses the “disk\_name” field as a format
string in a number of places. While this is normally not a problem due
to how disk names are created (statically or incrementally), there
is currently at least one way to defi...The block layer uses the “disk\_name” field as a format
string in a number of places. While this is normally not a problem due
to how disk names are created (statically or incrementally), there
is currently at least one way to define nearly arbitrary names via
md. Instead of filtering md, this should be fixed within the kernel’s
interfaces. This flaw could potentially allow escalation from uid-0 to
ring-0, so except for certain environments, it is not too serious.
The test case is trivial:
1. echo md\_%x.%x.%x.%x >/sys/module/md\_mod/parameters/new\_array
2. ls /dev/md\_\*
/dev/md\_c12cc370.df66d800.df66d80c.c13da45b
Using %n instead of %x leads to exciting crashes. :)
The fix has been sent upstream:
http://marc.info/?l=linux-kernel&m=137055204522556&w=2
With the above fixes, a series of additional format string related
clean
ups has also been sent upstream:
http://marc.info/?l=linux-kernel&m=137055207522563&w=2
*(from redmine: issue id 2095, created on 2013-06-18, closed on 2013-07-03)*
* Relations:
* parent #2093Alpine 2.5.5Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2096[v2.4] CVE-2013-2851 Linux-Kernel: block layer2019-07-23T14:20:53ZPeter Kotcauer[v2.4] CVE-2013-2851 Linux-Kernel: block layerThe block layer uses the “disk\_name” field as a format
string in a number of places. While this is normally not a problem due
to how disk names are created (statically or incrementally), there
is currently at least one way to defi...The block layer uses the “disk\_name” field as a format
string in a number of places. While this is normally not a problem due
to how disk names are created (statically or incrementally), there
is currently at least one way to define nearly arbitrary names via
md. Instead of filtering md, this should be fixed within the kernel’s
interfaces. This flaw could potentially allow escalation from uid-0 to
ring-0, so except for certain environments, it is not too serious.
The test case is trivial:
1. echo md\_%x.%x.%x.%x >/sys/module/md\_mod/parameters/new\_array
2. ls /dev/md\_\*
/dev/md\_c12cc370.df66d800.df66d80c.c13da45b
Using %n instead of %x leads to exciting crashes. :)
The fix has been sent upstream:
http://marc.info/?l=linux-kernel&m=137055204522556&w=2
With the above fixes, a series of additional format string related
clean
ups has also been sent upstream:
http://marc.info/?l=linux-kernel&m=137055207522563&w=2
*(from redmine: issue id 2096, created on 2013-06-18, closed on 2013-07-03)*
* Relations:
* parent #2093
* Changesets:
* Revision fe9af505b4a99ba6560870a89e982299adb76b2b by Natanael Copa on 2013-06-21T16:20:03Z:
```
main/linux-grsec: upgrade to 3.4.50 kernel (CVE-2013-2851,CVE-2013-2852)
fixes #2091
fixes #2096
```Alpine 2.4.12Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2097[v2.3] CVE-2013-2851 Linux-Kernel: block layer2019-07-23T14:20:53ZPeter Kotcauer[v2.3] CVE-2013-2851 Linux-Kernel: block layerThe block layer uses the “disk\_name” field as a format
string in a number of places. While this is normally not a problem due
to how disk names are created (statically or incrementally), there
is currently at least one way to defi...The block layer uses the “disk\_name” field as a format
string in a number of places. While this is normally not a problem due
to how disk names are created (statically or incrementally), there
is currently at least one way to define nearly arbitrary names via
md. Instead of filtering md, this should be fixed within the kernel’s
interfaces. This flaw could potentially allow escalation from uid-0 to
ring-0, so except for certain environments, it is not too serious.
The test case is trivial:
1. echo md\_%x.%x.%x.%x >/sys/module/md\_mod/parameters/new\_array
2. ls /dev/md\_\*
/dev/md\_c12cc370.df66d800.df66d80c.c13da45b
Using %n instead of %x leads to exciting crashes. :)
The fix has been sent upstream:
http://marc.info/?l=linux-kernel&m=137055204522556&w=2
With the above fixes, a series of additional format string related
clean
ups has also been sent upstream:
http://marc.info/?l=linux-kernel&m=137055207522563&w=2
*(from redmine: issue id 2097, created on 2013-06-18, closed on 2013-07-03)*
* Relations:
* parent #2093
* Changesets:
* Revision 25d456a566f8d7bdc343a3a55219b23a29433f5f by Natanael Copa on 2013-06-26T14:10:30Z:
```
main/linux-grsec: security fixes (CVE-2013-2164,CVE-2013-2851,CVE-2013-2852)
ref #2077
ref #2088
ref #2093
fixes #2083
fixes #2092
fixes #2097
```Alpine 2.3.7Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2098CVE-2013-2175 : haproxy may crash when using header occurrences relative to t...2019-07-23T14:20:51ZPeter KotcauerCVE-2013-2175 : haproxy may crash when using header occurrences relative to the tailDavid Torgerson reported an haproxy crash with enough traces to
diagnose
the cause as being related to the use of a negative occurrence number
in
a header extraction, which is used to extract an entry starting from
the
last occurre...David Torgerson reported an haproxy crash with enough traces to
diagnose
the cause as being related to the use of a negative occurrence number
in
a header extraction, which is used to extract an entry starting from
the
last occurrence.
—- summary —-
Configurations at risk are those which make use of “hdr\_ip(name,–1)”
(in
1.4) or any hdr\_\* variant with a negative occurrence count in 1.5,
or
the “usesrc hdr\_ip(name)” statement in both 1.4 and 1.5. These
configurations may be crashed when run with haproxy 1.4.4 to 1.4.23 or
development versions up to and including 1.5-dev18. Versions 1.4.24
and
1.5-dev19 are safe.
—- quick workaround —-
A workaround consists in rejecting dangerous requests early using
hdr\_cnt(<name>), which is available both in 1.4 and 1.5 :
block if { hdr\_cnt(<name>) ge 10 }
—- details —-
When a config makes use of hdr\_ip(x-forwarded-for,–1) or any such
thing
involving a negative occurrence count, the header is still parsed in
the
order it appears, and an array of up to MAX\_HDR\_HISTORY entries is
created.
When more entries are used, the entries simply wrap and continue this
way.
A problem happens when the incoming header field count exactly divides
MAX\_HDR\_HISTORY, because the computation removes the number of
requested
occurrences from the count, but does not care about the risk of
wrapping
with a negative number. Thus we can dereference the array with a
negative
number and randomly crash the process.
The bug is located in http\_get\_hdr() in haproxy 1.5, and
get\_ip\_from\_hdr2()
in haproxy 1.4. It affects configurations making use of one of the
following
functions with a negative <value> occurence number :
\- hdr\_ip(<name>, <value>) (in 1.4)
- hdr\_\*(<name>, <value>) (in 1.5)
It also affects “source” statements involving “hdr\_ip(<name>)” since
that
statement implicitly uses –1 for <value> :
\- source 0.0.0.0 usesrc hdr\_ip(<name>)
This bug has been present since the introduction of the negative
offset
count in 1.4.4 via commit bce70882.
CVE-2013-2175 was assigned to this bug.
Special thanks to David Torgerson who provided a significant number of
traces, and to Ryan O’Hara from Red Hat for providing a CVE id.
—- links —-
1.4-stable patch for version <= 1.4.23 :
http://git.1wt.eu/web?p=haproxy-1.4.git;a=commitdiff;h=f534af74ed
1.4.24 source code:
http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.24.tar.gz
1.5-dev patch for versions <= 1.5-dev18 :
http://git.1wt.eu/web?p=haproxy.git;a=commitdiff;h=67dad2715b
1.5-dev19 source code:
http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev19.tar.gz
*(from redmine: issue id 2098, created on 2013-06-18, closed on 2013-07-03)*
* Relations:
* child #2099
* child #2100
* child #2101
* child #2102
* child #2114Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2099[v2.6] CVE-2013-2175 : haproxy may crash when using header occurrences relati...2019-07-23T14:20:50ZPeter Kotcauer[v2.6] CVE-2013-2175 : haproxy may crash when using header occurrences relative to the tailDavid Torgerson reported an haproxy crash with enough traces to
diagnose
the cause as being related to the use of a negative occurrence number
in
a header extraction, which is used to extract an entry starting from
the
last occurre...David Torgerson reported an haproxy crash with enough traces to
diagnose
the cause as being related to the use of a negative occurrence number
in
a header extraction, which is used to extract an entry starting from
the
last occurrence.
—- summary —-
Configurations at risk are those which make use of “hdr\_ip(name,–1)”
(in
1.4) or any hdr\_\* variant with a negative occurrence count in 1.5,
or
the “usesrc hdr\_ip(name)” statement in both 1.4 and 1.5. These
configurations may be crashed when run with haproxy 1.4.4 to 1.4.23 or
development versions up to and including 1.5-dev18. Versions 1.4.24
and
1.5-dev19 are safe.
—- quick workaround —-
A workaround consists in rejecting dangerous requests early using
hdr\_cnt(<name>), which is available both in 1.4 and 1.5 :
block if { hdr\_cnt(<name>) ge 10 }
—- details —-
When a config makes use of hdr\_ip(x-forwarded-for,–1) or any such
thing
involving a negative occurrence count, the header is still parsed in
the
order it appears, and an array of up to MAX\_HDR\_HISTORY entries is
created.
When more entries are used, the entries simply wrap and continue this
way.
A problem happens when the incoming header field count exactly divides
MAX\_HDR\_HISTORY, because the computation removes the number of
requested
occurrences from the count, but does not care about the risk of
wrapping
with a negative number. Thus we can dereference the array with a
negative
number and randomly crash the process.
The bug is located in http\_get\_hdr() in haproxy 1.5, and
get\_ip\_from\_hdr2()
in haproxy 1.4. It affects configurations making use of one of the
following
functions with a negative <value> occurence number :
\- hdr\_ip(<name>, <value>) (in 1.4)
- hdr\_\*(<name>, <value>) (in 1.5)
It also affects “source” statements involving “hdr\_ip(<name>)” since
that
statement implicitly uses –1 for <value> :
\- source 0.0.0.0 usesrc hdr\_ip(<name>)
This bug has been present since the introduction of the negative
offset
count in 1.4.4 via commit bce70882.
CVE-2013-2175 was assigned to this bug.
Special thanks to David Torgerson who provided a significant number of
traces, and to Ryan O’Hara from Red Hat for providing a CVE id.
—- links —-
1.4-stable patch for version <= 1.4.23 :
http://git.1wt.eu/web?p=haproxy-1.4.git;a=commitdiff;h=f534af74ed
1.4.24 source code:
http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.24.tar.gz
1.5-dev patch for versions <= 1.5-dev18 :
http://git.1wt.eu/web?p=haproxy.git;a=commitdiff;h=67dad2715b
1.5-dev19 source code:
http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev19.tar.gz
*(from redmine: issue id 2099, created on 2013-06-18, closed on 2013-07-02)*
* Relations:
* parent #2098
* Changesets:
* Revision f7f59c5c4bc4eb186d2346ccde23948d8d1d6586 by Natanael Copa on 2013-06-21T13:38:56Z:
```
main/haproxy: security upgrade to 1.4.24 (CVE-2013-2175)
fixes #2099
(cherry picked from commit d2207b3c4708cac6038cfbb0b7c58722e49c5c4e)
```Alpine 2.6.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2100[v2.5] CVE-2013-2175 : haproxy may crash when using header occurrences relati...2019-07-23T14:20:49ZPeter Kotcauer[v2.5] CVE-2013-2175 : haproxy may crash when using header occurrences relative to the tailDavid Torgerson reported an haproxy crash with enough traces to
diagnose
the cause as being related to the use of a negative occurrence number
in
a header extraction, which is used to extract an entry starting from
the
last occurre...David Torgerson reported an haproxy crash with enough traces to
diagnose
the cause as being related to the use of a negative occurrence number
in
a header extraction, which is used to extract an entry starting from
the
last occurrence.
—- summary —-
Configurations at risk are those which make use of “hdr\_ip(name,–1)”
(in
1.4) or any hdr\_\* variant with a negative occurrence count in 1.5,
or
the “usesrc hdr\_ip(name)” statement in both 1.4 and 1.5. These
configurations may be crashed when run with haproxy 1.4.4 to 1.4.23 or
development versions up to and including 1.5-dev18. Versions 1.4.24
and
1.5-dev19 are safe.
—- quick workaround —-
A workaround consists in rejecting dangerous requests early using
hdr\_cnt(<name>), which is available both in 1.4 and 1.5 :
block if { hdr\_cnt(<name>) ge 10 }
—- details —-
When a config makes use of hdr\_ip(x-forwarded-for,–1) or any such
thing
involving a negative occurrence count, the header is still parsed in
the
order it appears, and an array of up to MAX\_HDR\_HISTORY entries is
created.
When more entries are used, the entries simply wrap and continue this
way.
A problem happens when the incoming header field count exactly divides
MAX\_HDR\_HISTORY, because the computation removes the number of
requested
occurrences from the count, but does not care about the risk of
wrapping
with a negative number. Thus we can dereference the array with a
negative
number and randomly crash the process.
The bug is located in http\_get\_hdr() in haproxy 1.5, and
get\_ip\_from\_hdr2()
in haproxy 1.4. It affects configurations making use of one of the
following
functions with a negative <value> occurence number :
\- hdr\_ip(<name>, <value>) (in 1.4)
- hdr\_\*(<name>, <value>) (in 1.5)
It also affects “source” statements involving “hdr\_ip(<name>)” since
that
statement implicitly uses –1 for <value> :
\- source 0.0.0.0 usesrc hdr\_ip(<name>)
This bug has been present since the introduction of the negative
offset
count in 1.4.4 via commit bce70882.
CVE-2013-2175 was assigned to this bug.
Special thanks to David Torgerson who provided a significant number of
traces, and to Ryan O’Hara from Red Hat for providing a CVE id.
—- links —-
1.4-stable patch for version <= 1.4.23 :
http://git.1wt.eu/web?p=haproxy-1.4.git;a=commitdiff;h=f534af74ed
1.4.24 source code:
http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.24.tar.gz
1.5-dev patch for versions <= 1.5-dev18 :
http://git.1wt.eu/web?p=haproxy.git;a=commitdiff;h=67dad2715b
1.5-dev19 source code:
http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev19.tar.gz
*(from redmine: issue id 2100, created on 2013-06-18, closed on 2013-06-21)*
* Relations:
* parent #2098
* Changesets:
* Revision 71014d6f0f81d932ba86312a8c361e134cfe6978 by Natanael Copa on 2013-06-21T14:01:29Z:
```
main/haproxy: security upgrade to 1.4.24 (CVE-2013-2175)
fixes #2100
(cherry picked from commit d2207b3c4708cac6038cfbb0b7c58722e49c5c4e)
Conflicts:
main/haproxy/APKBUILD
```Alpine 2.5.5Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2101[v2.4] CVE-2013-2175 : haproxy may crash when using header occurrences relati...2019-07-23T14:20:48ZPeter Kotcauer[v2.4] CVE-2013-2175 : haproxy may crash when using header occurrences relative to the tailDavid Torgerson reported an haproxy crash with enough traces to
diagnose
the cause as being related to the use of a negative occurrence number
in
a header extraction, which is used to extract an entry starting from
the
last occurre...David Torgerson reported an haproxy crash with enough traces to
diagnose
the cause as being related to the use of a negative occurrence number
in
a header extraction, which is used to extract an entry starting from
the
last occurrence.
—- summary —-
Configurations at risk are those which make use of “hdr\_ip(name,–1)”
(in
1.4) or any hdr\_\* variant with a negative occurrence count in 1.5,
or
the “usesrc hdr\_ip(name)” statement in both 1.4 and 1.5. These
configurations may be crashed when run with haproxy 1.4.4 to 1.4.23 or
development versions up to and including 1.5-dev18. Versions 1.4.24
and
1.5-dev19 are safe.
—- quick workaround —-
A workaround consists in rejecting dangerous requests early using
hdr\_cnt(<name>), which is available both in 1.4 and 1.5 :
block if { hdr\_cnt(<name>) ge 10 }
—- details —-
When a config makes use of hdr\_ip(x-forwarded-for,–1) or any such
thing
involving a negative occurrence count, the header is still parsed in
the
order it appears, and an array of up to MAX\_HDR\_HISTORY entries is
created.
When more entries are used, the entries simply wrap and continue this
way.
A problem happens when the incoming header field count exactly divides
MAX\_HDR\_HISTORY, because the computation removes the number of
requested
occurrences from the count, but does not care about the risk of
wrapping
with a negative number. Thus we can dereference the array with a
negative
number and randomly crash the process.
The bug is located in http\_get\_hdr() in haproxy 1.5, and
get\_ip\_from\_hdr2()
in haproxy 1.4. It affects configurations making use of one of the
following
functions with a negative <value> occurence number :
\- hdr\_ip(<name>, <value>) (in 1.4)
- hdr\_\*(<name>, <value>) (in 1.5)
It also affects “source” statements involving “hdr\_ip(<name>)” since
that
statement implicitly uses –1 for <value> :
\- source 0.0.0.0 usesrc hdr\_ip(<name>)
This bug has been present since the introduction of the negative
offset
count in 1.4.4 via commit bce70882.
CVE-2013-2175 was assigned to this bug.
Special thanks to David Torgerson who provided a significant number of
traces, and to Ryan O’Hara from Red Hat for providing a CVE id.
—- links —-
1.4-stable patch for version <= 1.4.23 :
http://git.1wt.eu/web?p=haproxy-1.4.git;a=commitdiff;h=f534af74ed
1.4.24 source code:
http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.24.tar.gz
1.5-dev patch for versions <= 1.5-dev18 :
http://git.1wt.eu/web?p=haproxy.git;a=commitdiff;h=67dad2715b
1.5-dev19 source code:
http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev19.tar.gz
*(from redmine: issue id 2101, created on 2013-06-18, closed on 2013-06-21)*
* Relations:
* parent #2098
* Changesets:
* Revision b9073a5009143c15d717fadaf3e8b37febf839f4 by Natanael Copa on 2013-06-21T14:03:36Z:
```
main/haproxy: security upgrade to 1.4.24 (CVE-2013-2175)
fixes #2101
(cherry picked from commit d2207b3c4708cac6038cfbb0b7c58722e49c5c4e)
Conflicts:
main/haproxy/APKBUILD
```Alpine 2.4.12Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2102[v2.3] CVE-2013-2175 : haproxy may crash when using header occurrences relati...2019-07-23T14:20:46ZPeter Kotcauer[v2.3] CVE-2013-2175 : haproxy may crash when using header occurrences relative to the tailDavid Torgerson reported an haproxy crash with enough traces to
diagnose
the cause as being related to the use of a negative occurrence number
in
a header extraction, which is used to extract an entry starting from
the
last occurre...David Torgerson reported an haproxy crash with enough traces to
diagnose
the cause as being related to the use of a negative occurrence number
in
a header extraction, which is used to extract an entry starting from
the
last occurrence.
—- summary —-
Configurations at risk are those which make use of “hdr\_ip(name,–1)”
(in
1.4) or any hdr\_\* variant with a negative occurrence count in 1.5,
or
the “usesrc hdr\_ip(name)” statement in both 1.4 and 1.5. These
configurations may be crashed when run with haproxy 1.4.4 to 1.4.23 or
development versions up to and including 1.5-dev18. Versions 1.4.24
and
1.5-dev19 are safe.
—- quick workaround —-
A workaround consists in rejecting dangerous requests early using
hdr\_cnt(<name>), which is available both in 1.4 and 1.5 :
block if { hdr\_cnt(<name>) ge 10 }
—- details —-
When a config makes use of hdr\_ip(x-forwarded-for,–1) or any such
thing
involving a negative occurrence count, the header is still parsed in
the
order it appears, and an array of up to MAX\_HDR\_HISTORY entries is
created.
When more entries are used, the entries simply wrap and continue this
way.
A problem happens when the incoming header field count exactly divides
MAX\_HDR\_HISTORY, because the computation removes the number of
requested
occurrences from the count, but does not care about the risk of
wrapping
with a negative number. Thus we can dereference the array with a
negative
number and randomly crash the process.
The bug is located in http\_get\_hdr() in haproxy 1.5, and
get\_ip\_from\_hdr2()
in haproxy 1.4. It affects configurations making use of one of the
following
functions with a negative <value> occurence number :
\- hdr\_ip(<name>, <value>) (in 1.4)
- hdr\_\*(<name>, <value>) (in 1.5)
It also affects “source” statements involving “hdr\_ip(<name>)” since
that
statement implicitly uses –1 for <value> :
\- source 0.0.0.0 usesrc hdr\_ip(<name>)
This bug has been present since the introduction of the negative
offset
count in 1.4.4 via commit bce70882.
CVE-2013-2175 was assigned to this bug.
Special thanks to David Torgerson who provided a significant number of
traces, and to Ryan O’Hara from Red Hat for providing a CVE id.
—- links —-
1.4-stable patch for version <= 1.4.23 :
http://git.1wt.eu/web?p=haproxy-1.4.git;a=commitdiff;h=f534af74ed
1.4.24 source code:
http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.24.tar.gz
1.5-dev patch for versions <= 1.5-dev18 :
http://git.1wt.eu/web?p=haproxy.git;a=commitdiff;h=67dad2715b
1.5-dev19 source code:
http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev19.tar.gz
*(from redmine: issue id 2102, created on 2013-06-18, closed on 2013-06-21)*
* Relations:
* parent #2098
* Changesets:
* Revision d18986df20f642070086bc7da1c238a7aa986c87 by Natanael Copa on 2013-06-21T14:04:56Z:
```
main/haproxy: security upgrade to 1.4.24 (CVE-2013-2175)
fixes #2102
(cherry picked from commit d2207b3c4708cac6038cfbb0b7c58722e49c5c4e)
Conflicts:
main/haproxy/APKBUILD
```Alpine 2.3.7Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2103ACF SQL Injection2019-07-23T14:20:45ZAlan LacerdaACF SQL InjectionOn Kamailio Search Database Tab, it is possible to Inject malicious SQL
instructions.
\[ POC \]
Table.Column: **subscriber.id**
Comparison: **<span style="text-align:center;"></span>**
Value: **1’; DELETE from speed\_dial; —**
\...On Kamailio Search Database Tab, it is possible to Inject malicious SQL
instructions.
\[ POC \]
Table.Column: **subscriber.id**
Comparison: **<span style="text-align:center;"></span>**
Value: **1’; DELETE from speed\_dial; —**
\[ End POC \]
See attached file.
*(from redmine: issue id 2103, created on 2013-06-18, closed on 2013-08-05)*
* Uploads:
* ![SQL_Injection_on_Alpine_ACF_Kamailio_Search_Database_Mod](/uploads/b872955854a6ae71c795c5fcd6e1aaed/SQL_Injection_on_Alpine_ACF_Kamailio_Search_Database_Mod.PNG)Ted TraskTed Traskhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2105CVE-2013-2206 Linux kernel: sctp: duplicate cookie handling NULL pointer dere...2019-07-23T14:20:45ZPeter KotcauerCVE-2013-2206 Linux kernel: sctp: duplicate cookie handling NULL pointer dereferenceA flaw was found in the way Linux kernel’s SCTP network protocol
implementation handled duplicate cookies. A transient empty
association
is created while processing the duplicate cookie chunk that userspace
could query, potentially...A flaw was found in the way Linux kernel’s SCTP network protocol
implementation handled duplicate cookies. A transient empty
association
is created while processing the duplicate cookie chunk that userspace
could query, potentially leading to NULL pointer dereference. A remote
attacker able to initiate SCTP connection to the system could use this
flaw to create transient conditions that could lead to remote system
crash if remote system user is querying SCTP connection info at the
time
these conditions exist.
Upstream fix:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f2815633504b442ca0b0605c16bf3d88a3a0fcea
(already in stable)
References:
https://bugzilla.redhat.com/show\_bug.cgi?id=976562
*(from redmine: issue id 2105, created on 2013-06-21, closed on 2013-07-03)*
* Relations:
* child #2106
* child #2107https://gitlab.alpinelinux.org/alpine/aports/-/issues/2106[v2.5] CVE-2013-2206 Linux kernel: sctp: duplicate cookie handling NULL point...2019-07-23T14:20:44ZPeter Kotcauer[v2.5] CVE-2013-2206 Linux kernel: sctp: duplicate cookie handling NULL pointer dereferenceA flaw was found in the way Linux kernel’s SCTP network protocol
implementation handled duplicate cookies. A transient empty
association
is created while processing the duplicate cookie chunk that userspace
could query, potentially...A flaw was found in the way Linux kernel’s SCTP network protocol
implementation handled duplicate cookies. A transient empty
association
is created while processing the duplicate cookie chunk that userspace
could query, potentially leading to NULL pointer dereference. A remote
attacker able to initiate SCTP connection to the system could use this
flaw to create transient conditions that could lead to remote system
crash if remote system user is querying SCTP connection info at the
time
these conditions exist.
Upstream fix:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f2815633504b442ca0b0605c16bf3d88a3a0fcea
(already in stable)
References:
https://bugzilla.redhat.com/show\_bug.cgi?id=976562
*(from redmine: issue id 2106, created on 2013-06-21, closed on 2013-07-03)*
* Relations:
* parent #2105
* Changesets:
* Revision ce1529a88f3e2b023cff957c6dc7f9d094ae77f1 by Natanael Copa on 2013-06-26T10:27:53Z:
```
main/linux-grsec: security fix (CVE-2013-2206)
fixes #2106
```Alpine 2.5.5Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2107[v2.3] CVE-2013-2206 Linux kernel: sctp: duplicate cookie handling NULL point...2019-07-12T14:40:05ZPeter Kotcauer[v2.3] CVE-2013-2206 Linux kernel: sctp: duplicate cookie handling NULL pointer dereferenceA flaw was found in the way Linux kernel’s SCTP network protocol
implementation handled duplicate cookies. A transient empty
association
is created while processing the duplicate cookie chunk that userspace
could query, potentially...A flaw was found in the way Linux kernel’s SCTP network protocol
implementation handled duplicate cookies. A transient empty
association
is created while processing the duplicate cookie chunk that userspace
could query, potentially leading to NULL pointer dereference. A remote
attacker able to initiate SCTP connection to the system could use this
flaw to create transient conditions that could lead to remote system
crash if remote system user is querying SCTP connection info at the
time
these conditions exist.
Upstream fix:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f2815633504b442ca0b0605c16bf3d88a3a0fcea
(already in stable)
References:
https://bugzilla.redhat.com/show\_bug.cgi?id=976562
*(from redmine: issue id 2107, created on 2013-06-21, closed on 2013-06-26)*
* Relations:
* parent #2105Alpine 2.3.7Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2108Xen Security Advisory 55 (CVE-2013-2194, CVE-2013-2195, CVE-2013-2196) - Mult...2019-07-23T14:20:43ZPeter KotcauerXen Security Advisory 55 (CVE-2013-2194, CVE-2013-2195, CVE-2013-2196) - Multiple vulnerabilities in libelf PV kernel handling——<s>BEGIN PGP SIGNED MESSAGE——</s>
Hash: SHA1
Xen Security Advisory CVE-2013-2194,CVE-2013-2195,CVE-2013-2196 /
XSA-55
version 5
Multiple vulnerabilities in libelf PV kernel handling
UPDATES IN VERSION 5
CVE numbers have been ...——<s>BEGIN PGP SIGNED MESSAGE——</s>
Hash: SHA1
Xen Security Advisory CVE-2013-2194,CVE-2013-2195,CVE-2013-2196 /
XSA-55
version 5
Multiple vulnerabilities in libelf PV kernel handling
UPDATES IN VERSION 5
CVE numbers have been assigned.
ISSUE DESCRIPTION
=
The ELF parser used by the Xen tools to read domains’ kernels and
construct domains has multiple integer overflows, pointer dereferences
based on calculations from unchecked input values, and other problems.
This corresponds to the following CVEs:
CVE-2013-2194 XEN XSA-55 integer overflows
CVE-2013-2195 XEN XSA-55 pointer dereferences
CVE-2013-2196 XEN XSA-55 other problems
IMPACT
==
A malicious PV domain administrator who can specify their own kernel
can escalate their privilege to that of the domain construction tools
(i.e., normally, to control of the host).
Additionally a malicious HVM domain administrator who is able to
supply their own firmware (“hvmloader”) can do likewise; however we
think this would be very unusual and it is unlikely that such
configurations exist in production systems.
VULNERABLE SYSTEMS
==
All Xen versions are affected.
Installations which only allow the use of trustworthy kernels for PV
domains are not affected.
MITIGATION
==
Ensuring that PV guests use only trustworthy kernels will avoid this
problem.
RESOLUTION
==
Applying the appropriate patch series will resolve this issue.
These were attached to v3 of the advisory which can be found here:
http://lists.xen.org/archives/html/xen-devel/2013-06/msg01626.html
These are available in xen.git
http://xenbits.xen.org/gitweb/?p=xen.git
git://xenbits.xen.org/xen.git
http://xenbits.xen.org/git-http/xen.git
in the git changesets listed below.
xen-unstable:
82cb4113b6ace16de192021de20f6cbd991e478f libxc: Better range check in
xc\_dom\_alloc\_segment
966070058d02cce9684e30073b61d6465e4b351c libxc: check blob size before
proceeding in xc\_dom\_check\_gzip
de7911eaef98b6643d80e4612fe4dcd4528d15b9 libxc: range checks in
xc\_dom\_p2m\_host
and \_guest
3d5a1d4733e55e33521cd5004cab1313e5c5d5ff libxc: check return values from
malloc
aaebaba5ae225f591e0602e071037a935bb281b6 libxc: check failure of
xc\_dom\_\*\_to\_ptr, xc\_map\_foreign\_range
2bcee4b3c316379f4b52cb308947eb6db3faf1a0 libxc: Add range checking to
xc\_dom\_binloader
66fe2726fe8492676f9970b9c2c511bce6186ece libelf: abolish obsolete
macros
39bf7b9d0ae534491745e54df5232127c0bddaf1 libelf: check loops for running
away
a004800f8fc607b96527815c8e3beabcb455d8e0 libelf: use only unsigned
integers
7a549a6aa04dba807f8dd4c1577ab6a7592c4c76 libelf: use C99 bool for
booleans
c84481fbc7de7d15ff7476b3b9cd2713f81feaa3 libelf: Make all callers call
elf\_check\_broken
943de71cf07d9d04ccb215bd46153b04930e9f25 libelf: Check pointer
references in
elf\_is\_elfbinary
65808a8ed41cc7c044f588bd6cab5af0fdc0e029 libelf: check all pointer
accesses
04877847ade4ac9216e9f408fd544ade8f90cf9a libelf: check nul-terminated
strings
properly
50421bd56bf164f490d7d0bf5741e58936de41e8 tools/xcutils/readnotes:
adjust
print\_l1\_mfn\_valid\_note
85256359995587df00001dca22e9a76ba6ea8258 libelf: introduce macros for
memory
access and pointer handling
95dd49bed681af93f71a401b0a35bf2f917c6e68
libelf/xc\_dom\_load\_elf\_symtab: Do not
use “syms” uninitialised
f7aa72ec00aec71eed055dac5e8a151966d75c9c libelf: move include of
<asm/guest\_access.h>to top of file
13e2c808f7ea721c8f200062e2b9b977ee924471 libelf: abolish elf\_sval and
elf\_access\_signed
009ddca51504ce80889937e485d44ac0f9290d63 libelf: add \`struct
elf\_binary\*’
parameter to elf\_load\_image
b5a869209998fedadfe205d37addbd50a802998b libxc: Fix range checking in
xc\_dom\_pfn\_to\_ptr etc.
53bfcf585b09eb4ac2240f89d1ade77421cd2451 libxc: introduce
xc\_dom\_seg\_to\_ptr\_pages
14573b974850d82de7aebad17e6471d27d847f2c libelf: abolish
libelf-relocate.c
Xen 4.2.x:
d21d36e84354c04638b60a739a5f7c3d9f8adaf8 libxc: Better range check in
xc\_dom\_alloc\_segment
2a548e22915535ac13694eb38222903bca7245e3 libxc: check blob size before
proceeding in xc\_dom\_check\_gzip
052a689aa526ca51fd70528d4b0f83dfb2de99c1 libxc: range checks in
xc\_dom\_p2m\_host
and \_guest
8dc90d163650ce8aa36ae0b46debab83cc61edb6 libxc: check return values from
malloc
77c0829fa751f052f7b8ec08287aef6e7ba97bc5 libxc: check failure of
xc\_dom\_\*\_to\_ptr, xc\_map\_foreign\_range
b06e277b1fc08c7da3befeb3ac3950e1d941585d libxc: Add range checking to
xc\_dom\_binloader
3baaa4ffcd3e7dd6227f9bdf817f90e5b75aeda2 libelf: abolish obsolete
macros
52d8cc2dd3bb3e0f6d51e00280da934e8d91653a libelf: check loops for running
away
e673ca50127b6c1263727aa31de0b8bb966ca7a2 libelf: use only unsigned
integers
3fb6ccf2faccaf5e22e33a3155ccc72d732896d8 libelf: use C99 bool for
booleans
a965b8f80388603d439ae2b8ee7b9b018a079f90 libelf: Make all callers call
elf\_check\_broken
d0790bdad7496e720416b2d4a04563c4c27e7b95 libelf: Check pointer
references in
elf\_is\_elfbinary
cc8761371aac432318530c2ddfe2c8234bc0621f libelf: check all pointer
accesses
db14d5bd9b6508adfcd2b910f454fae12fa4ba00 libelf: check nul-terminated
strings
properly
59f66d58180832af6b99a9e4489031b5c2f627ab tools/xcutils/readnotes:
adjust
print\_l1\_mfn\_valid\_note
40020ab55a1e9a1674ddecdb70299fab4fe8579d libelf: introduce macros for
memory
access and pointer handling
de9089b449d2508b1ba05590905c7ebaee00c8c4
libelf/xc\_dom\_load\_elf\_symtab: Do not
use “syms” uninitialised
682a04488e7b3bd6c3448ab60599566eb7c6177a libelf: move include of
<asm/guest\_access.h>to top of file
83ec905922b496e1a5756e3a88405eb6c2c6ba88 libelf: abolish elf\_sval and
elf\_access\_signed
035634047d10c678cbb8801c4263747bdaf4e5b1 libelf: add \`struct
elf\_binary\*’
parameter to elf\_load\_image
8c738fa5c1f3cfcd935b6191b3526f7ac8b2a5bd libxc: Fix range checking in
xc\_dom\_pfn\_to\_ptr etc.
a672da4b2d58ef12be9d7407160e9fb43cac75d9 libxc: introduce
xc\_dom\_seg\_to\_ptr\_pages
9737484becab4a25159f1e985700eaee89690d34 libelf: abolish
libelf-relocate.c
Xen 4.1.x:
ac63ddd70a5ccf5ebf790f06ea4cd4ed794c3978 libxc: check blob size before
proceeding in xc\_dom\_check\_gzip
6eca85d5c144ee8c899ee3cf8791f9087b15f2e8 libxc: range checks in
xc\_dom\_p2m\_host
and \_guest
a2986a7959919bc748784bb75970bfbd42697d3b libxc: check return values from
malloc
117a538dbef62f8d39159dea652e633e01b50a9a libxc: check failure of
xc\_dom\_\*\_to\_ptr, xc\_map\_foreign\_range
40b76f1fb04af421c1415f7bcb168dfaa6960d0d libxc: Add range checking to
xc\_dom\_binloader
4a3a60d8caee49af6951a672c55b08436a8d1f86 libelf: abolish obsolete
macros
968c0399159c65e24bb8b9969259e18791e1f4d8 libelf: check loops for running
away
282188ea84b9e0f9c4865f0609e7740f2f28e7b0 libxc: Introduce xc\_bitops.h
86e39ce58e91fe55d4fdbc914cb1955c45acc20e libelf: use only unsigned
integers
bd3dba9f435fa59f305407f7d9b34e1e164ddd98 libelf: use C99 bool for
booleans
44c74b1ed31c75ed9026abf62ab7427a46d8027a libelf: Make all callers call
elf\_check\_broken
9962d7ffcce97ec2d69a15ef861996b1ead33694 libelf: Check pointer
references in
elf\_is\_elfbinary
39923542bb43e67776c4e8292d4a5a1adef2bd3b libelf: check all pointer
accesses
8ce60b35beaac91a97b79c004ca6bf5d58e7390b libelf: check nul-terminated
strings
properly
4e46085972d2367dff2345a73361c1c17b47ce73 tools/xcutils/readnotes:
adjust
print\_l1\_mfn\_valid\_note
de49d6e83c3a8c753646b007972140ddbb746ba8 libelf: introduce macros for
memory
access and pointer handling
4d3339de1fe3cbf7b05487fdb6cadd7267950948
libelf/xc\_dom\_load\_elf\_symtab: Do not
use “syms” uninitialised
e719b136b750e5eee87c4647d1846e4e1e70eac0 libelf: abolish elf\_sval and
elf\_access\_signed
f7fb94409c562beec06094141ef262dc85f28dac libxc: Fix range checking in
xc\_dom\_pfn\_to\_ptr etc.
bbf40e6b6d47809f4289a866d7d167c25104ecc0 libxc: introduce
xc\_dom\_seg\_to\_ptr\_pages
64a0206c451920b72a9c5721a6f2427baf99e3dd libelf: abolish
libelf-relocate.c
——<s>BEGIN PGP SIGNATURE——</s>
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJRwticAAoJEIP+FMlX6CvZFbEIAMjbI64TpgYSm3cRSFmdHol/
FC2d4mo/aeb8e24RCTnJvxP3oE+o1Oar5FGJi+AATDynzbqcuv7yK7iDQ9ZfwGm5
xZR+knkFKymWLsutb8uhDRT8eYCgmK8aQEXorvcjr69sxrxJascPGv4aHesNihxO
t4tRqRbqGhAzkm9Gm32LaVz3UYCW2ZRs4lxDBjtW5HmsugaOarCYNTqSpftAiAkn
XE8UChNUVO95PAJKRtmihLQ+TGJ9cyujBACrl6RsxdD8JZU6EP4rq7fccdzyqD6D
+c5pw859mtukyy56fwfP5Ji6G9O2VrrZyf4kq13V74SPZ/LV3VKDalfaVVItLGQ=
=RVh5
——<s>END PGP SIGNATURE——</s>
*(from redmine: issue id 2108, created on 2013-06-21, closed on 2013-07-03)*
* Relations:
* child #2109
* child #2110
* child #2111
* child #2112
* child #2115
* Changesets:
* Revision 19901df1bcb30f294ee615cd161ba33d67c75771 by Natanael Copa on 2013-06-26T11:51:52Z:
```
main/xen: security fix (CVE-2013-2194,CVE-2013-2195,CVE-2013-2196)
ref #2108
fixes #2110
(cherry picked from commit f78e9dea47b7c130cb417d9826c984d8664f01ec)
Conflicts:
main/xen/APKBUILD
```
* Revision 386d947eaf640de1a5515087a2b65d5960e5624b by Natanael Copa on 2013-06-26T13:59:41Z:
```
main/xen: fix xsa55 and xsa57 (CVE-2013-2194,CVE-2013-2195,CVE-2013-2196,CVE-2013-2211)
ref #2108
ref #2117
fixes #2111
fixes #2120
```
* Revision dac4485dfa4d8ae59e99caf4b911c196dc2b717f by Natanael Copa on 2013-06-26T14:10:30Z:
```
main/xen: fix xsa55 and xsa57 (CVE-2013-2194,CVE-2013-2195,CVE-2013-2196,CV
E-2013-2211)
ref #2108
ref #2117
fixes #2112
fixes #2121
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/2109[v2.6] Xen Security Advisory 55 (CVE-2013-2194, CVE-2013-2195, CVE-2013-2196)...2019-07-23T14:20:41ZPeter Kotcauer[v2.6] Xen Security Advisory 55 (CVE-2013-2194, CVE-2013-2195, CVE-2013-2196) - Multiple vulnerabilities in libelf PV kernel handling——<s>BEGIN PGP SIGNED MESSAGE——</s>
Hash: SHA1
Xen Security Advisory CVE-2013-2194,CVE-2013-2195,CVE-2013-2196 /
XSA-55
version 5
Multiple vulnerabilities in libelf PV kernel handling
UPDATES IN VERSION 5
CVE numbers have been ...——<s>BEGIN PGP SIGNED MESSAGE——</s>
Hash: SHA1
Xen Security Advisory CVE-2013-2194,CVE-2013-2195,CVE-2013-2196 /
XSA-55
version 5
Multiple vulnerabilities in libelf PV kernel handling
UPDATES IN VERSION 5
CVE numbers have been assigned.
ISSUE DESCRIPTION
=
The ELF parser used by the Xen tools to read domains’ kernels and
construct domains has multiple integer overflows, pointer dereferences
based on calculations from unchecked input values, and other problems.
This corresponds to the following CVEs:
CVE-2013-2194 XEN XSA-55 integer overflows
CVE-2013-2195 XEN XSA-55 pointer dereferences
CVE-2013-2196 XEN XSA-55 other problems
IMPACT
==
A malicious PV domain administrator who can specify their own kernel
can escalate their privilege to that of the domain construction tools
(i.e., normally, to control of the host).
Additionally a malicious HVM domain administrator who is able to
supply their own firmware (“hvmloader”) can do likewise; however we
think this would be very unusual and it is unlikely that such
configurations exist in production systems.
VULNERABLE SYSTEMS
==
All Xen versions are affected.
Installations which only allow the use of trustworthy kernels for PV
domains are not affected.
MITIGATION
==
Ensuring that PV guests use only trustworthy kernels will avoid this
problem.
RESOLUTION
==
Applying the appropriate patch series will resolve this issue.
These were attached to v3 of the advisory which can be found here:
http://lists.xen.org/archives/html/xen-devel/2013-06/msg01626.html
These are available in xen.git
http://xenbits.xen.org/gitweb/?p=xen.git
git://xenbits.xen.org/xen.git
http://xenbits.xen.org/git-http/xen.git
in the git changesets listed below.
xen-unstable:
82cb4113b6ace16de192021de20f6cbd991e478f libxc: Better range check in
xc\_dom\_alloc\_segment
966070058d02cce9684e30073b61d6465e4b351c libxc: check blob size before
proceeding in xc\_dom\_check\_gzip
de7911eaef98b6643d80e4612fe4dcd4528d15b9 libxc: range checks in
xc\_dom\_p2m\_host
and \_guest
3d5a1d4733e55e33521cd5004cab1313e5c5d5ff libxc: check return values from
malloc
aaebaba5ae225f591e0602e071037a935bb281b6 libxc: check failure of
xc\_dom\_\*\_to\_ptr, xc\_map\_foreign\_range
2bcee4b3c316379f4b52cb308947eb6db3faf1a0 libxc: Add range checking to
xc\_dom\_binloader
66fe2726fe8492676f9970b9c2c511bce6186ece libelf: abolish obsolete
macros
39bf7b9d0ae534491745e54df5232127c0bddaf1 libelf: check loops for running
away
a004800f8fc607b96527815c8e3beabcb455d8e0 libelf: use only unsigned
integers
7a549a6aa04dba807f8dd4c1577ab6a7592c4c76 libelf: use C99 bool for
booleans
c84481fbc7de7d15ff7476b3b9cd2713f81feaa3 libelf: Make all callers call
elf\_check\_broken
943de71cf07d9d04ccb215bd46153b04930e9f25 libelf: Check pointer
references in
elf\_is\_elfbinary
65808a8ed41cc7c044f588bd6cab5af0fdc0e029 libelf: check all pointer
accesses
04877847ade4ac9216e9f408fd544ade8f90cf9a libelf: check nul-terminated
strings
properly
50421bd56bf164f490d7d0bf5741e58936de41e8 tools/xcutils/readnotes:
adjust
print\_l1\_mfn\_valid\_note
85256359995587df00001dca22e9a76ba6ea8258 libelf: introduce macros for
memory
access and pointer handling
95dd49bed681af93f71a401b0a35bf2f917c6e68
libelf/xc\_dom\_load\_elf\_symtab: Do not
use “syms” uninitialised
f7aa72ec00aec71eed055dac5e8a151966d75c9c libelf: move include of
<asm/guest\_access.h>to top of file
13e2c808f7ea721c8f200062e2b9b977ee924471 libelf: abolish elf\_sval and
elf\_access\_signed
009ddca51504ce80889937e485d44ac0f9290d63 libelf: add \`struct
elf\_binary\*’
parameter to elf\_load\_image
b5a869209998fedadfe205d37addbd50a802998b libxc: Fix range checking in
xc\_dom\_pfn\_to\_ptr etc.
53bfcf585b09eb4ac2240f89d1ade77421cd2451 libxc: introduce
xc\_dom\_seg\_to\_ptr\_pages
14573b974850d82de7aebad17e6471d27d847f2c libelf: abolish
libelf-relocate.c
Xen 4.2.x:
d21d36e84354c04638b60a739a5f7c3d9f8adaf8 libxc: Better range check in
xc\_dom\_alloc\_segment
2a548e22915535ac13694eb38222903bca7245e3 libxc: check blob size before
proceeding in xc\_dom\_check\_gzip
052a689aa526ca51fd70528d4b0f83dfb2de99c1 libxc: range checks in
xc\_dom\_p2m\_host
and \_guest
8dc90d163650ce8aa36ae0b46debab83cc61edb6 libxc: check return values from
malloc
77c0829fa751f052f7b8ec08287aef6e7ba97bc5 libxc: check failure of
xc\_dom\_\*\_to\_ptr, xc\_map\_foreign\_range
b06e277b1fc08c7da3befeb3ac3950e1d941585d libxc: Add range checking to
xc\_dom\_binloader
3baaa4ffcd3e7dd6227f9bdf817f90e5b75aeda2 libelf: abolish obsolete
macros
52d8cc2dd3bb3e0f6d51e00280da934e8d91653a libelf: check loops for running
away
e673ca50127b6c1263727aa31de0b8bb966ca7a2 libelf: use only unsigned
integers
3fb6ccf2faccaf5e22e33a3155ccc72d732896d8 libelf: use C99 bool for
booleans
a965b8f80388603d439ae2b8ee7b9b018a079f90 libelf: Make all callers call
elf\_check\_broken
d0790bdad7496e720416b2d4a04563c4c27e7b95 libelf: Check pointer
references in
elf\_is\_elfbinary
cc8761371aac432318530c2ddfe2c8234bc0621f libelf: check all pointer
accesses
db14d5bd9b6508adfcd2b910f454fae12fa4ba00 libelf: check nul-terminated
strings
properly
59f66d58180832af6b99a9e4489031b5c2f627ab tools/xcutils/readnotes:
adjust
print\_l1\_mfn\_valid\_note
40020ab55a1e9a1674ddecdb70299fab4fe8579d libelf: introduce macros for
memory
access and pointer handling
de9089b449d2508b1ba05590905c7ebaee00c8c4
libelf/xc\_dom\_load\_elf\_symtab: Do not
use “syms” uninitialised
682a04488e7b3bd6c3448ab60599566eb7c6177a libelf: move include of
<asm/guest\_access.h>to top of file
83ec905922b496e1a5756e3a88405eb6c2c6ba88 libelf: abolish elf\_sval and
elf\_access\_signed
035634047d10c678cbb8801c4263747bdaf4e5b1 libelf: add \`struct
elf\_binary\*’
parameter to elf\_load\_image
8c738fa5c1f3cfcd935b6191b3526f7ac8b2a5bd libxc: Fix range checking in
xc\_dom\_pfn\_to\_ptr etc.
a672da4b2d58ef12be9d7407160e9fb43cac75d9 libxc: introduce
xc\_dom\_seg\_to\_ptr\_pages
9737484becab4a25159f1e985700eaee89690d34 libelf: abolish
libelf-relocate.c
Xen 4.1.x:
ac63ddd70a5ccf5ebf790f06ea4cd4ed794c3978 libxc: check blob size before
proceeding in xc\_dom\_check\_gzip
6eca85d5c144ee8c899ee3cf8791f9087b15f2e8 libxc: range checks in
xc\_dom\_p2m\_host
and \_guest
a2986a7959919bc748784bb75970bfbd42697d3b libxc: check return values from
malloc
117a538dbef62f8d39159dea652e633e01b50a9a libxc: check failure of
xc\_dom\_\*\_to\_ptr, xc\_map\_foreign\_range
40b76f1fb04af421c1415f7bcb168dfaa6960d0d libxc: Add range checking to
xc\_dom\_binloader
4a3a60d8caee49af6951a672c55b08436a8d1f86 libelf: abolish obsolete
macros
968c0399159c65e24bb8b9969259e18791e1f4d8 libelf: check loops for running
away
282188ea84b9e0f9c4865f0609e7740f2f28e7b0 libxc: Introduce xc\_bitops.h
86e39ce58e91fe55d4fdbc914cb1955c45acc20e libelf: use only unsigned
integers
bd3dba9f435fa59f305407f7d9b34e1e164ddd98 libelf: use C99 bool for
booleans
44c74b1ed31c75ed9026abf62ab7427a46d8027a libelf: Make all callers call
elf\_check\_broken
9962d7ffcce97ec2d69a15ef861996b1ead33694 libelf: Check pointer
references in
elf\_is\_elfbinary
39923542bb43e67776c4e8292d4a5a1adef2bd3b libelf: check all pointer
accesses
8ce60b35beaac91a97b79c004ca6bf5d58e7390b libelf: check nul-terminated
strings
properly
4e46085972d2367dff2345a73361c1c17b47ce73 tools/xcutils/readnotes:
adjust
print\_l1\_mfn\_valid\_note
de49d6e83c3a8c753646b007972140ddbb746ba8 libelf: introduce macros for
memory
access and pointer handling
4d3339de1fe3cbf7b05487fdb6cadd7267950948
libelf/xc\_dom\_load\_elf\_symtab: Do not
use “syms” uninitialised
e719b136b750e5eee87c4647d1846e4e1e70eac0 libelf: abolish elf\_sval and
elf\_access\_signed
f7fb94409c562beec06094141ef262dc85f28dac libxc: Fix range checking in
xc\_dom\_pfn\_to\_ptr etc.
bbf40e6b6d47809f4289a866d7d167c25104ecc0 libxc: introduce
xc\_dom\_seg\_to\_ptr\_pages
64a0206c451920b72a9c5721a6f2427baf99e3dd libelf: abolish
libelf-relocate.c
——<s>BEGIN PGP SIGNATURE——</s>
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJRwticAAoJEIP+FMlX6CvZFbEIAMjbI64TpgYSm3cRSFmdHol/
FC2d4mo/aeb8e24RCTnJvxP3oE+o1Oar5FGJi+AATDynzbqcuv7yK7iDQ9ZfwGm5
xZR+knkFKymWLsutb8uhDRT8eYCgmK8aQEXorvcjr69sxrxJascPGv4aHesNihxO
t4tRqRbqGhAzkm9Gm32LaVz3UYCW2ZRs4lxDBjtW5HmsugaOarCYNTqSpftAiAkn
XE8UChNUVO95PAJKRtmihLQ+TGJ9cyujBACrl6RsxdD8JZU6EP4rq7fccdzyqD6D
+c5pw859mtukyy56fwfP5Ji6G9O2VrrZyf4kq13V74SPZ/LV3VKDalfaVVItLGQ=
=RVh5
——<s>END PGP SIGNATURE——</s>
*(from redmine: issue id 2109, created on 2013-06-21, closed on 2013-07-02)*
* Relations:
* parent #2108
* Changesets:
* Revision 50869d41a1af768fb0c39ff2d059a8bec102bc91 by Natanael Copa on 2013-06-26T10:36:24Z:
```
main/xen: security fix (CVE-2013-2194,CVE-2013-2195,CVE-2013-2196)
fixes #2109
(cherry picked from commit f78e9dea47b7c130cb417d9826c984d8664f01ec)
Conflicts:
main/xen/APKBUILD
```Alpine 2.6.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2110[v2.5] Xen Security Advisory 55 (CVE-2013-2194, CVE-2013-2195, CVE-2013-2196)...2019-07-23T14:20:40ZPeter Kotcauer[v2.5] Xen Security Advisory 55 (CVE-2013-2194, CVE-2013-2195, CVE-2013-2196) - Multiple vulnerabilities in libelf PV kernel handling——<s>BEGIN PGP SIGNED MESSAGE——</s>
Hash: SHA1
Xen Security Advisory CVE-2013-2194,CVE-2013-2195,CVE-2013-2196 /
XSA-55
version 5
Multiple vulnerabilities in libelf PV kernel handling
UPDATES IN VERSION 5
CVE numbers have been ...——<s>BEGIN PGP SIGNED MESSAGE——</s>
Hash: SHA1
Xen Security Advisory CVE-2013-2194,CVE-2013-2195,CVE-2013-2196 /
XSA-55
version 5
Multiple vulnerabilities in libelf PV kernel handling
UPDATES IN VERSION 5
CVE numbers have been assigned.
ISSUE DESCRIPTION
=
The ELF parser used by the Xen tools to read domains’ kernels and
construct domains has multiple integer overflows, pointer dereferences
based on calculations from unchecked input values, and other problems.
This corresponds to the following CVEs:
CVE-2013-2194 XEN XSA-55 integer overflows
CVE-2013-2195 XEN XSA-55 pointer dereferences
CVE-2013-2196 XEN XSA-55 other problems
IMPACT
==
A malicious PV domain administrator who can specify their own kernel
can escalate their privilege to that of the domain construction tools
(i.e., normally, to control of the host).
Additionally a malicious HVM domain administrator who is able to
supply their own firmware (“hvmloader”) can do likewise; however we
think this would be very unusual and it is unlikely that such
configurations exist in production systems.
VULNERABLE SYSTEMS
==
All Xen versions are affected.
Installations which only allow the use of trustworthy kernels for PV
domains are not affected.
MITIGATION
==
Ensuring that PV guests use only trustworthy kernels will avoid this
problem.
RESOLUTION
==
Applying the appropriate patch series will resolve this issue.
These were attached to v3 of the advisory which can be found here:
http://lists.xen.org/archives/html/xen-devel/2013-06/msg01626.html
These are available in xen.git
http://xenbits.xen.org/gitweb/?p=xen.git
git://xenbits.xen.org/xen.git
http://xenbits.xen.org/git-http/xen.git
in the git changesets listed below.
xen-unstable:
82cb4113b6ace16de192021de20f6cbd991e478f libxc: Better range check in
xc\_dom\_alloc\_segment
966070058d02cce9684e30073b61d6465e4b351c libxc: check blob size before
proceeding in xc\_dom\_check\_gzip
de7911eaef98b6643d80e4612fe4dcd4528d15b9 libxc: range checks in
xc\_dom\_p2m\_host
and \_guest
3d5a1d4733e55e33521cd5004cab1313e5c5d5ff libxc: check return values from
malloc
aaebaba5ae225f591e0602e071037a935bb281b6 libxc: check failure of
xc\_dom\_\*\_to\_ptr, xc\_map\_foreign\_range
2bcee4b3c316379f4b52cb308947eb6db3faf1a0 libxc: Add range checking to
xc\_dom\_binloader
66fe2726fe8492676f9970b9c2c511bce6186ece libelf: abolish obsolete
macros
39bf7b9d0ae534491745e54df5232127c0bddaf1 libelf: check loops for running
away
a004800f8fc607b96527815c8e3beabcb455d8e0 libelf: use only unsigned
integers
7a549a6aa04dba807f8dd4c1577ab6a7592c4c76 libelf: use C99 bool for
booleans
c84481fbc7de7d15ff7476b3b9cd2713f81feaa3 libelf: Make all callers call
elf\_check\_broken
943de71cf07d9d04ccb215bd46153b04930e9f25 libelf: Check pointer
references in
elf\_is\_elfbinary
65808a8ed41cc7c044f588bd6cab5af0fdc0e029 libelf: check all pointer
accesses
04877847ade4ac9216e9f408fd544ade8f90cf9a libelf: check nul-terminated
strings
properly
50421bd56bf164f490d7d0bf5741e58936de41e8 tools/xcutils/readnotes:
adjust
print\_l1\_mfn\_valid\_note
85256359995587df00001dca22e9a76ba6ea8258 libelf: introduce macros for
memory
access and pointer handling
95dd49bed681af93f71a401b0a35bf2f917c6e68
libelf/xc\_dom\_load\_elf\_symtab: Do not
use “syms” uninitialised
f7aa72ec00aec71eed055dac5e8a151966d75c9c libelf: move include of
<asm/guest\_access.h>to top of file
13e2c808f7ea721c8f200062e2b9b977ee924471 libelf: abolish elf\_sval and
elf\_access\_signed
009ddca51504ce80889937e485d44ac0f9290d63 libelf: add \`struct
elf\_binary\*’
parameter to elf\_load\_image
b5a869209998fedadfe205d37addbd50a802998b libxc: Fix range checking in
xc\_dom\_pfn\_to\_ptr etc.
53bfcf585b09eb4ac2240f89d1ade77421cd2451 libxc: introduce
xc\_dom\_seg\_to\_ptr\_pages
14573b974850d82de7aebad17e6471d27d847f2c libelf: abolish
libelf-relocate.c
Xen 4.2.x:
d21d36e84354c04638b60a739a5f7c3d9f8adaf8 libxc: Better range check in
xc\_dom\_alloc\_segment
2a548e22915535ac13694eb38222903bca7245e3 libxc: check blob size before
proceeding in xc\_dom\_check\_gzip
052a689aa526ca51fd70528d4b0f83dfb2de99c1 libxc: range checks in
xc\_dom\_p2m\_host
and \_guest
8dc90d163650ce8aa36ae0b46debab83cc61edb6 libxc: check return values from
malloc
77c0829fa751f052f7b8ec08287aef6e7ba97bc5 libxc: check failure of
xc\_dom\_\*\_to\_ptr, xc\_map\_foreign\_range
b06e277b1fc08c7da3befeb3ac3950e1d941585d libxc: Add range checking to
xc\_dom\_binloader
3baaa4ffcd3e7dd6227f9bdf817f90e5b75aeda2 libelf: abolish obsolete
macros
52d8cc2dd3bb3e0f6d51e00280da934e8d91653a libelf: check loops for running
away
e673ca50127b6c1263727aa31de0b8bb966ca7a2 libelf: use only unsigned
integers
3fb6ccf2faccaf5e22e33a3155ccc72d732896d8 libelf: use C99 bool for
booleans
a965b8f80388603d439ae2b8ee7b9b018a079f90 libelf: Make all callers call
elf\_check\_broken
d0790bdad7496e720416b2d4a04563c4c27e7b95 libelf: Check pointer
references in
elf\_is\_elfbinary
cc8761371aac432318530c2ddfe2c8234bc0621f libelf: check all pointer
accesses
db14d5bd9b6508adfcd2b910f454fae12fa4ba00 libelf: check nul-terminated
strings
properly
59f66d58180832af6b99a9e4489031b5c2f627ab tools/xcutils/readnotes:
adjust
print\_l1\_mfn\_valid\_note
40020ab55a1e9a1674ddecdb70299fab4fe8579d libelf: introduce macros for
memory
access and pointer handling
de9089b449d2508b1ba05590905c7ebaee00c8c4
libelf/xc\_dom\_load\_elf\_symtab: Do not
use “syms” uninitialised
682a04488e7b3bd6c3448ab60599566eb7c6177a libelf: move include of
<asm/guest\_access.h>to top of file
83ec905922b496e1a5756e3a88405eb6c2c6ba88 libelf: abolish elf\_sval and
elf\_access\_signed
035634047d10c678cbb8801c4263747bdaf4e5b1 libelf: add \`struct
elf\_binary\*’
parameter to elf\_load\_image
8c738fa5c1f3cfcd935b6191b3526f7ac8b2a5bd libxc: Fix range checking in
xc\_dom\_pfn\_to\_ptr etc.
a672da4b2d58ef12be9d7407160e9fb43cac75d9 libxc: introduce
xc\_dom\_seg\_to\_ptr\_pages
9737484becab4a25159f1e985700eaee89690d34 libelf: abolish
libelf-relocate.c
Xen 4.1.x:
ac63ddd70a5ccf5ebf790f06ea4cd4ed794c3978 libxc: check blob size before
proceeding in xc\_dom\_check\_gzip
6eca85d5c144ee8c899ee3cf8791f9087b15f2e8 libxc: range checks in
xc\_dom\_p2m\_host
and \_guest
a2986a7959919bc748784bb75970bfbd42697d3b libxc: check return values from
malloc
117a538dbef62f8d39159dea652e633e01b50a9a libxc: check failure of
xc\_dom\_\*\_to\_ptr, xc\_map\_foreign\_range
40b76f1fb04af421c1415f7bcb168dfaa6960d0d libxc: Add range checking to
xc\_dom\_binloader
4a3a60d8caee49af6951a672c55b08436a8d1f86 libelf: abolish obsolete
macros
968c0399159c65e24bb8b9969259e18791e1f4d8 libelf: check loops for running
away
282188ea84b9e0f9c4865f0609e7740f2f28e7b0 libxc: Introduce xc\_bitops.h
86e39ce58e91fe55d4fdbc914cb1955c45acc20e libelf: use only unsigned
integers
bd3dba9f435fa59f305407f7d9b34e1e164ddd98 libelf: use C99 bool for
booleans
44c74b1ed31c75ed9026abf62ab7427a46d8027a libelf: Make all callers call
elf\_check\_broken
9962d7ffcce97ec2d69a15ef861996b1ead33694 libelf: Check pointer
references in
elf\_is\_elfbinary
39923542bb43e67776c4e8292d4a5a1adef2bd3b libelf: check all pointer
accesses
8ce60b35beaac91a97b79c004ca6bf5d58e7390b libelf: check nul-terminated
strings
properly
4e46085972d2367dff2345a73361c1c17b47ce73 tools/xcutils/readnotes:
adjust
print\_l1\_mfn\_valid\_note
de49d6e83c3a8c753646b007972140ddbb746ba8 libelf: introduce macros for
memory
access and pointer handling
4d3339de1fe3cbf7b05487fdb6cadd7267950948
libelf/xc\_dom\_load\_elf\_symtab: Do not
use “syms” uninitialised
e719b136b750e5eee87c4647d1846e4e1e70eac0 libelf: abolish elf\_sval and
elf\_access\_signed
f7fb94409c562beec06094141ef262dc85f28dac libxc: Fix range checking in
xc\_dom\_pfn\_to\_ptr etc.
bbf40e6b6d47809f4289a866d7d167c25104ecc0 libxc: introduce
xc\_dom\_seg\_to\_ptr\_pages
64a0206c451920b72a9c5721a6f2427baf99e3dd libelf: abolish
libelf-relocate.c
——<s>BEGIN PGP SIGNATURE——</s>
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJRwticAAoJEIP+FMlX6CvZFbEIAMjbI64TpgYSm3cRSFmdHol/
FC2d4mo/aeb8e24RCTnJvxP3oE+o1Oar5FGJi+AATDynzbqcuv7yK7iDQ9ZfwGm5
xZR+knkFKymWLsutb8uhDRT8eYCgmK8aQEXorvcjr69sxrxJascPGv4aHesNihxO
t4tRqRbqGhAzkm9Gm32LaVz3UYCW2ZRs4lxDBjtW5HmsugaOarCYNTqSpftAiAkn
XE8UChNUVO95PAJKRtmihLQ+TGJ9cyujBACrl6RsxdD8JZU6EP4rq7fccdzyqD6D
+c5pw859mtukyy56fwfP5Ji6G9O2VrrZyf4kq13V74SPZ/LV3VKDalfaVVItLGQ=
=RVh5
——<s>END PGP SIGNATURE——</s>
*(from redmine: issue id 2110, created on 2013-06-21, closed on 2013-07-03)*
* Relations:
* parent #2108
* Changesets:
* Revision 19901df1bcb30f294ee615cd161ba33d67c75771 by Natanael Copa on 2013-06-26T11:51:52Z:
```
main/xen: security fix (CVE-2013-2194,CVE-2013-2195,CVE-2013-2196)
ref #2108
fixes #2110
(cherry picked from commit f78e9dea47b7c130cb417d9826c984d8664f01ec)
Conflicts:
main/xen/APKBUILD
```Alpine 2.5.5Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2111[v2.4] Xen Security Advisory 55 (CVE-2013-2194, CVE-2013-2195, CVE-2013-2196)...2019-07-23T14:20:38ZPeter Kotcauer[v2.4] Xen Security Advisory 55 (CVE-2013-2194, CVE-2013-2195, CVE-2013-2196) - Multiple vulnerabilities in libelf PV kernel handling——<s>BEGIN PGP SIGNED MESSAGE——</s>
Hash: SHA1
Xen Security Advisory CVE-2013-2194,CVE-2013-2195,CVE-2013-2196 /
XSA-55
version 5
Multiple vulnerabilities in libelf PV kernel handling
UPDATES IN VERSION 5
CVE numbers have been ...——<s>BEGIN PGP SIGNED MESSAGE——</s>
Hash: SHA1
Xen Security Advisory CVE-2013-2194,CVE-2013-2195,CVE-2013-2196 /
XSA-55
version 5
Multiple vulnerabilities in libelf PV kernel handling
UPDATES IN VERSION 5
CVE numbers have been assigned.
ISSUE DESCRIPTION
=
The ELF parser used by the Xen tools to read domains’ kernels and
construct domains has multiple integer overflows, pointer dereferences
based on calculations from unchecked input values, and other problems.
This corresponds to the following CVEs:
CVE-2013-2194 XEN XSA-55 integer overflows
CVE-2013-2195 XEN XSA-55 pointer dereferences
CVE-2013-2196 XEN XSA-55 other problems
IMPACT
==
A malicious PV domain administrator who can specify their own kernel
can escalate their privilege to that of the domain construction tools
(i.e., normally, to control of the host).
Additionally a malicious HVM domain administrator who is able to
supply their own firmware (“hvmloader”) can do likewise; however we
think this would be very unusual and it is unlikely that such
configurations exist in production systems.
VULNERABLE SYSTEMS
==
All Xen versions are affected.
Installations which only allow the use of trustworthy kernels for PV
domains are not affected.
MITIGATION
==
Ensuring that PV guests use only trustworthy kernels will avoid this
problem.
RESOLUTION
==
Applying the appropriate patch series will resolve this issue.
These were attached to v3 of the advisory which can be found here:
http://lists.xen.org/archives/html/xen-devel/2013-06/msg01626.html
These are available in xen.git
http://xenbits.xen.org/gitweb/?p=xen.git
git://xenbits.xen.org/xen.git
http://xenbits.xen.org/git-http/xen.git
in the git changesets listed below.
xen-unstable:
82cb4113b6ace16de192021de20f6cbd991e478f libxc: Better range check in
xc\_dom\_alloc\_segment
966070058d02cce9684e30073b61d6465e4b351c libxc: check blob size before
proceeding in xc\_dom\_check\_gzip
de7911eaef98b6643d80e4612fe4dcd4528d15b9 libxc: range checks in
xc\_dom\_p2m\_host
and \_guest
3d5a1d4733e55e33521cd5004cab1313e5c5d5ff libxc: check return values from
malloc
aaebaba5ae225f591e0602e071037a935bb281b6 libxc: check failure of
xc\_dom\_\*\_to\_ptr, xc\_map\_foreign\_range
2bcee4b3c316379f4b52cb308947eb6db3faf1a0 libxc: Add range checking to
xc\_dom\_binloader
66fe2726fe8492676f9970b9c2c511bce6186ece libelf: abolish obsolete
macros
39bf7b9d0ae534491745e54df5232127c0bddaf1 libelf: check loops for running
away
a004800f8fc607b96527815c8e3beabcb455d8e0 libelf: use only unsigned
integers
7a549a6aa04dba807f8dd4c1577ab6a7592c4c76 libelf: use C99 bool for
booleans
c84481fbc7de7d15ff7476b3b9cd2713f81feaa3 libelf: Make all callers call
elf\_check\_broken
943de71cf07d9d04ccb215bd46153b04930e9f25 libelf: Check pointer
references in
elf\_is\_elfbinary
65808a8ed41cc7c044f588bd6cab5af0fdc0e029 libelf: check all pointer
accesses
04877847ade4ac9216e9f408fd544ade8f90cf9a libelf: check nul-terminated
strings
properly
50421bd56bf164f490d7d0bf5741e58936de41e8 tools/xcutils/readnotes:
adjust
print\_l1\_mfn\_valid\_note
85256359995587df00001dca22e9a76ba6ea8258 libelf: introduce macros for
memory
access and pointer handling
95dd49bed681af93f71a401b0a35bf2f917c6e68
libelf/xc\_dom\_load\_elf\_symtab: Do not
use “syms” uninitialised
f7aa72ec00aec71eed055dac5e8a151966d75c9c libelf: move include of
<asm/guest\_access.h>to top of file
13e2c808f7ea721c8f200062e2b9b977ee924471 libelf: abolish elf\_sval and
elf\_access\_signed
009ddca51504ce80889937e485d44ac0f9290d63 libelf: add \`struct
elf\_binary\*’
parameter to elf\_load\_image
b5a869209998fedadfe205d37addbd50a802998b libxc: Fix range checking in
xc\_dom\_pfn\_to\_ptr etc.
53bfcf585b09eb4ac2240f89d1ade77421cd2451 libxc: introduce
xc\_dom\_seg\_to\_ptr\_pages
14573b974850d82de7aebad17e6471d27d847f2c libelf: abolish
libelf-relocate.c
Xen 4.2.x:
d21d36e84354c04638b60a739a5f7c3d9f8adaf8 libxc: Better range check in
xc\_dom\_alloc\_segment
2a548e22915535ac13694eb38222903bca7245e3 libxc: check blob size before
proceeding in xc\_dom\_check\_gzip
052a689aa526ca51fd70528d4b0f83dfb2de99c1 libxc: range checks in
xc\_dom\_p2m\_host
and \_guest
8dc90d163650ce8aa36ae0b46debab83cc61edb6 libxc: check return values from
malloc
77c0829fa751f052f7b8ec08287aef6e7ba97bc5 libxc: check failure of
xc\_dom\_\*\_to\_ptr, xc\_map\_foreign\_range
b06e277b1fc08c7da3befeb3ac3950e1d941585d libxc: Add range checking to
xc\_dom\_binloader
3baaa4ffcd3e7dd6227f9bdf817f90e5b75aeda2 libelf: abolish obsolete
macros
52d8cc2dd3bb3e0f6d51e00280da934e8d91653a libelf: check loops for running
away
e673ca50127b6c1263727aa31de0b8bb966ca7a2 libelf: use only unsigned
integers
3fb6ccf2faccaf5e22e33a3155ccc72d732896d8 libelf: use C99 bool for
booleans
a965b8f80388603d439ae2b8ee7b9b018a079f90 libelf: Make all callers call
elf\_check\_broken
d0790bdad7496e720416b2d4a04563c4c27e7b95 libelf: Check pointer
references in
elf\_is\_elfbinary
cc8761371aac432318530c2ddfe2c8234bc0621f libelf: check all pointer
accesses
db14d5bd9b6508adfcd2b910f454fae12fa4ba00 libelf: check nul-terminated
strings
properly
59f66d58180832af6b99a9e4489031b5c2f627ab tools/xcutils/readnotes:
adjust
print\_l1\_mfn\_valid\_note
40020ab55a1e9a1674ddecdb70299fab4fe8579d libelf: introduce macros for
memory
access and pointer handling
de9089b449d2508b1ba05590905c7ebaee00c8c4
libelf/xc\_dom\_load\_elf\_symtab: Do not
use “syms” uninitialised
682a04488e7b3bd6c3448ab60599566eb7c6177a libelf: move include of
<asm/guest\_access.h>to top of file
83ec905922b496e1a5756e3a88405eb6c2c6ba88 libelf: abolish elf\_sval and
elf\_access\_signed
035634047d10c678cbb8801c4263747bdaf4e5b1 libelf: add \`struct
elf\_binary\*’
parameter to elf\_load\_image
8c738fa5c1f3cfcd935b6191b3526f7ac8b2a5bd libxc: Fix range checking in
xc\_dom\_pfn\_to\_ptr etc.
a672da4b2d58ef12be9d7407160e9fb43cac75d9 libxc: introduce
xc\_dom\_seg\_to\_ptr\_pages
9737484becab4a25159f1e985700eaee89690d34 libelf: abolish
libelf-relocate.c
Xen 4.1.x:
ac63ddd70a5ccf5ebf790f06ea4cd4ed794c3978 libxc: check blob size before
proceeding in xc\_dom\_check\_gzip
6eca85d5c144ee8c899ee3cf8791f9087b15f2e8 libxc: range checks in
xc\_dom\_p2m\_host
and \_guest
a2986a7959919bc748784bb75970bfbd42697d3b libxc: check return values from
malloc
117a538dbef62f8d39159dea652e633e01b50a9a libxc: check failure of
xc\_dom\_\*\_to\_ptr, xc\_map\_foreign\_range
40b76f1fb04af421c1415f7bcb168dfaa6960d0d libxc: Add range checking to
xc\_dom\_binloader
4a3a60d8caee49af6951a672c55b08436a8d1f86 libelf: abolish obsolete
macros
968c0399159c65e24bb8b9969259e18791e1f4d8 libelf: check loops for running
away
282188ea84b9e0f9c4865f0609e7740f2f28e7b0 libxc: Introduce xc\_bitops.h
86e39ce58e91fe55d4fdbc914cb1955c45acc20e libelf: use only unsigned
integers
bd3dba9f435fa59f305407f7d9b34e1e164ddd98 libelf: use C99 bool for
booleans
44c74b1ed31c75ed9026abf62ab7427a46d8027a libelf: Make all callers call
elf\_check\_broken
9962d7ffcce97ec2d69a15ef861996b1ead33694 libelf: Check pointer
references in
elf\_is\_elfbinary
39923542bb43e67776c4e8292d4a5a1adef2bd3b libelf: check all pointer
accesses
8ce60b35beaac91a97b79c004ca6bf5d58e7390b libelf: check nul-terminated
strings
properly
4e46085972d2367dff2345a73361c1c17b47ce73 tools/xcutils/readnotes:
adjust
print\_l1\_mfn\_valid\_note
de49d6e83c3a8c753646b007972140ddbb746ba8 libelf: introduce macros for
memory
access and pointer handling
4d3339de1fe3cbf7b05487fdb6cadd7267950948
libelf/xc\_dom\_load\_elf\_symtab: Do not
use “syms” uninitialised
e719b136b750e5eee87c4647d1846e4e1e70eac0 libelf: abolish elf\_sval and
elf\_access\_signed
f7fb94409c562beec06094141ef262dc85f28dac libxc: Fix range checking in
xc\_dom\_pfn\_to\_ptr etc.
bbf40e6b6d47809f4289a866d7d167c25104ecc0 libxc: introduce
xc\_dom\_seg\_to\_ptr\_pages
64a0206c451920b72a9c5721a6f2427baf99e3dd libelf: abolish
libelf-relocate.c
——<s>BEGIN PGP SIGNATURE——</s>
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJRwticAAoJEIP+FMlX6CvZFbEIAMjbI64TpgYSm3cRSFmdHol/
FC2d4mo/aeb8e24RCTnJvxP3oE+o1Oar5FGJi+AATDynzbqcuv7yK7iDQ9ZfwGm5
xZR+knkFKymWLsutb8uhDRT8eYCgmK8aQEXorvcjr69sxrxJascPGv4aHesNihxO
t4tRqRbqGhAzkm9Gm32LaVz3UYCW2ZRs4lxDBjtW5HmsugaOarCYNTqSpftAiAkn
XE8UChNUVO95PAJKRtmihLQ+TGJ9cyujBACrl6RsxdD8JZU6EP4rq7fccdzyqD6D
+c5pw859mtukyy56fwfP5Ji6G9O2VrrZyf4kq13V74SPZ/LV3VKDalfaVVItLGQ=
=RVh5
——<s>END PGP SIGNATURE——</s>
*(from redmine: issue id 2111, created on 2013-06-21, closed on 2013-07-03)*
* Relations:
* parent #2108
* Changesets:
* Revision 386d947eaf640de1a5515087a2b65d5960e5624b by Natanael Copa on 2013-06-26T13:59:41Z:
```
main/xen: fix xsa55 and xsa57 (CVE-2013-2194,CVE-2013-2195,CVE-2013-2196,CVE-2013-2211)
ref #2108
ref #2117
fixes #2111
fixes #2120
```Alpine 2.4.12Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2112[v2.3] Xen Security Advisory 55 (CVE-2013-2194, CVE-2013-2195, CVE-2013-2196)...2019-07-23T14:20:37ZPeter Kotcauer[v2.3] Xen Security Advisory 55 (CVE-2013-2194, CVE-2013-2195, CVE-2013-2196) - Multiple vulnerabilities in libelf PV kernel handling——<s>BEGIN PGP SIGNED MESSAGE——</s>
Hash: SHA1
Xen Security Advisory CVE-2013-2194,CVE-2013-2195,CVE-2013-2196 /
XSA-55
version 5
Multiple vulnerabilities in libelf PV kernel handling
UPDATES IN VERSION 5
CVE numbers have been ...——<s>BEGIN PGP SIGNED MESSAGE——</s>
Hash: SHA1
Xen Security Advisory CVE-2013-2194,CVE-2013-2195,CVE-2013-2196 /
XSA-55
version 5
Multiple vulnerabilities in libelf PV kernel handling
UPDATES IN VERSION 5
CVE numbers have been assigned.
ISSUE DESCRIPTION
=
The ELF parser used by the Xen tools to read domains’ kernels and
construct domains has multiple integer overflows, pointer dereferences
based on calculations from unchecked input values, and other problems.
This corresponds to the following CVEs:
CVE-2013-2194 XEN XSA-55 integer overflows
CVE-2013-2195 XEN XSA-55 pointer dereferences
CVE-2013-2196 XEN XSA-55 other problems
IMPACT
==
A malicious PV domain administrator who can specify their own kernel
can escalate their privilege to that of the domain construction tools
(i.e., normally, to control of the host).
Additionally a malicious HVM domain administrator who is able to
supply their own firmware (“hvmloader”) can do likewise; however we
think this would be very unusual and it is unlikely that such
configurations exist in production systems.
VULNERABLE SYSTEMS
==
All Xen versions are affected.
Installations which only allow the use of trustworthy kernels for PV
domains are not affected.
MITIGATION
==
Ensuring that PV guests use only trustworthy kernels will avoid this
problem.
RESOLUTION
==
Applying the appropriate patch series will resolve this issue.
These were attached to v3 of the advisory which can be found here:
http://lists.xen.org/archives/html/xen-devel/2013-06/msg01626.html
These are available in xen.git
http://xenbits.xen.org/gitweb/?p=xen.git
git://xenbits.xen.org/xen.git
http://xenbits.xen.org/git-http/xen.git
in the git changesets listed below.
xen-unstable:
82cb4113b6ace16de192021de20f6cbd991e478f libxc: Better range check in
xc\_dom\_alloc\_segment
966070058d02cce9684e30073b61d6465e4b351c libxc: check blob size before
proceeding in xc\_dom\_check\_gzip
de7911eaef98b6643d80e4612fe4dcd4528d15b9 libxc: range checks in
xc\_dom\_p2m\_host
and \_guest
3d5a1d4733e55e33521cd5004cab1313e5c5d5ff libxc: check return values from
malloc
aaebaba5ae225f591e0602e071037a935bb281b6 libxc: check failure of
xc\_dom\_\*\_to\_ptr, xc\_map\_foreign\_range
2bcee4b3c316379f4b52cb308947eb6db3faf1a0 libxc: Add range checking to
xc\_dom\_binloader
66fe2726fe8492676f9970b9c2c511bce6186ece libelf: abolish obsolete
macros
39bf7b9d0ae534491745e54df5232127c0bddaf1 libelf: check loops for running
away
a004800f8fc607b96527815c8e3beabcb455d8e0 libelf: use only unsigned
integers
7a549a6aa04dba807f8dd4c1577ab6a7592c4c76 libelf: use C99 bool for
booleans
c84481fbc7de7d15ff7476b3b9cd2713f81feaa3 libelf: Make all callers call
elf\_check\_broken
943de71cf07d9d04ccb215bd46153b04930e9f25 libelf: Check pointer
references in
elf\_is\_elfbinary
65808a8ed41cc7c044f588bd6cab5af0fdc0e029 libelf: check all pointer
accesses
04877847ade4ac9216e9f408fd544ade8f90cf9a libelf: check nul-terminated
strings
properly
50421bd56bf164f490d7d0bf5741e58936de41e8 tools/xcutils/readnotes:
adjust
print\_l1\_mfn\_valid\_note
85256359995587df00001dca22e9a76ba6ea8258 libelf: introduce macros for
memory
access and pointer handling
95dd49bed681af93f71a401b0a35bf2f917c6e68
libelf/xc\_dom\_load\_elf\_symtab: Do not
use “syms” uninitialised
f7aa72ec00aec71eed055dac5e8a151966d75c9c libelf: move include of
<asm/guest\_access.h>to top of file
13e2c808f7ea721c8f200062e2b9b977ee924471 libelf: abolish elf\_sval and
elf\_access\_signed
009ddca51504ce80889937e485d44ac0f9290d63 libelf: add \`struct
elf\_binary\*’
parameter to elf\_load\_image
b5a869209998fedadfe205d37addbd50a802998b libxc: Fix range checking in
xc\_dom\_pfn\_to\_ptr etc.
53bfcf585b09eb4ac2240f89d1ade77421cd2451 libxc: introduce
xc\_dom\_seg\_to\_ptr\_pages
14573b974850d82de7aebad17e6471d27d847f2c libelf: abolish
libelf-relocate.c
Xen 4.2.x:
d21d36e84354c04638b60a739a5f7c3d9f8adaf8 libxc: Better range check in
xc\_dom\_alloc\_segment
2a548e22915535ac13694eb38222903bca7245e3 libxc: check blob size before
proceeding in xc\_dom\_check\_gzip
052a689aa526ca51fd70528d4b0f83dfb2de99c1 libxc: range checks in
xc\_dom\_p2m\_host
and \_guest
8dc90d163650ce8aa36ae0b46debab83cc61edb6 libxc: check return values from
malloc
77c0829fa751f052f7b8ec08287aef6e7ba97bc5 libxc: check failure of
xc\_dom\_\*\_to\_ptr, xc\_map\_foreign\_range
b06e277b1fc08c7da3befeb3ac3950e1d941585d libxc: Add range checking to
xc\_dom\_binloader
3baaa4ffcd3e7dd6227f9bdf817f90e5b75aeda2 libelf: abolish obsolete
macros
52d8cc2dd3bb3e0f6d51e00280da934e8d91653a libelf: check loops for running
away
e673ca50127b6c1263727aa31de0b8bb966ca7a2 libelf: use only unsigned
integers
3fb6ccf2faccaf5e22e33a3155ccc72d732896d8 libelf: use C99 bool for
booleans
a965b8f80388603d439ae2b8ee7b9b018a079f90 libelf: Make all callers call
elf\_check\_broken
d0790bdad7496e720416b2d4a04563c4c27e7b95 libelf: Check pointer
references in
elf\_is\_elfbinary
cc8761371aac432318530c2ddfe2c8234bc0621f libelf: check all pointer
accesses
db14d5bd9b6508adfcd2b910f454fae12fa4ba00 libelf: check nul-terminated
strings
properly
59f66d58180832af6b99a9e4489031b5c2f627ab tools/xcutils/readnotes:
adjust
print\_l1\_mfn\_valid\_note
40020ab55a1e9a1674ddecdb70299fab4fe8579d libelf: introduce macros for
memory
access and pointer handling
de9089b449d2508b1ba05590905c7ebaee00c8c4
libelf/xc\_dom\_load\_elf\_symtab: Do not
use “syms” uninitialised
682a04488e7b3bd6c3448ab60599566eb7c6177a libelf: move include of
<asm/guest\_access.h>to top of file
83ec905922b496e1a5756e3a88405eb6c2c6ba88 libelf: abolish elf\_sval and
elf\_access\_signed
035634047d10c678cbb8801c4263747bdaf4e5b1 libelf: add \`struct
elf\_binary\*’
parameter to elf\_load\_image
8c738fa5c1f3cfcd935b6191b3526f7ac8b2a5bd libxc: Fix range checking in
xc\_dom\_pfn\_to\_ptr etc.
a672da4b2d58ef12be9d7407160e9fb43cac75d9 libxc: introduce
xc\_dom\_seg\_to\_ptr\_pages
9737484becab4a25159f1e985700eaee89690d34 libelf: abolish
libelf-relocate.c
Xen 4.1.x:
ac63ddd70a5ccf5ebf790f06ea4cd4ed794c3978 libxc: check blob size before
proceeding in xc\_dom\_check\_gzip
6eca85d5c144ee8c899ee3cf8791f9087b15f2e8 libxc: range checks in
xc\_dom\_p2m\_host
and \_guest
a2986a7959919bc748784bb75970bfbd42697d3b libxc: check return values from
malloc
117a538dbef62f8d39159dea652e633e01b50a9a libxc: check failure of
xc\_dom\_\*\_to\_ptr, xc\_map\_foreign\_range
40b76f1fb04af421c1415f7bcb168dfaa6960d0d libxc: Add range checking to
xc\_dom\_binloader
4a3a60d8caee49af6951a672c55b08436a8d1f86 libelf: abolish obsolete
macros
968c0399159c65e24bb8b9969259e18791e1f4d8 libelf: check loops for running
away
282188ea84b9e0f9c4865f0609e7740f2f28e7b0 libxc: Introduce xc\_bitops.h
86e39ce58e91fe55d4fdbc914cb1955c45acc20e libelf: use only unsigned
integers
bd3dba9f435fa59f305407f7d9b34e1e164ddd98 libelf: use C99 bool for
booleans
44c74b1ed31c75ed9026abf62ab7427a46d8027a libelf: Make all callers call
elf\_check\_broken
9962d7ffcce97ec2d69a15ef861996b1ead33694 libelf: Check pointer
references in
elf\_is\_elfbinary
39923542bb43e67776c4e8292d4a5a1adef2bd3b libelf: check all pointer
accesses
8ce60b35beaac91a97b79c004ca6bf5d58e7390b libelf: check nul-terminated
strings
properly
4e46085972d2367dff2345a73361c1c17b47ce73 tools/xcutils/readnotes:
adjust
print\_l1\_mfn\_valid\_note
de49d6e83c3a8c753646b007972140ddbb746ba8 libelf: introduce macros for
memory
access and pointer handling
4d3339de1fe3cbf7b05487fdb6cadd7267950948
libelf/xc\_dom\_load\_elf\_symtab: Do not
use “syms” uninitialised
e719b136b750e5eee87c4647d1846e4e1e70eac0 libelf: abolish elf\_sval and
elf\_access\_signed
f7fb94409c562beec06094141ef262dc85f28dac libxc: Fix range checking in
xc\_dom\_pfn\_to\_ptr etc.
bbf40e6b6d47809f4289a866d7d167c25104ecc0 libxc: introduce
xc\_dom\_seg\_to\_ptr\_pages
64a0206c451920b72a9c5721a6f2427baf99e3dd libelf: abolish
libelf-relocate.c
——<s>BEGIN PGP SIGNATURE——</s>
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJRwticAAoJEIP+FMlX6CvZFbEIAMjbI64TpgYSm3cRSFmdHol/
FC2d4mo/aeb8e24RCTnJvxP3oE+o1Oar5FGJi+AATDynzbqcuv7yK7iDQ9ZfwGm5
xZR+knkFKymWLsutb8uhDRT8eYCgmK8aQEXorvcjr69sxrxJascPGv4aHesNihxO
t4tRqRbqGhAzkm9Gm32LaVz3UYCW2ZRs4lxDBjtW5HmsugaOarCYNTqSpftAiAkn
XE8UChNUVO95PAJKRtmihLQ+TGJ9cyujBACrl6RsxdD8JZU6EP4rq7fccdzyqD6D
+c5pw859mtukyy56fwfP5Ji6G9O2VrrZyf4kq13V74SPZ/LV3VKDalfaVVItLGQ=
=RVh5
——<s>END PGP SIGNATURE——</s>
*(from redmine: issue id 2112, created on 2013-06-21, closed on 2013-07-03)*
* Relations:
* parent #2108
* Changesets:
* Revision dac4485dfa4d8ae59e99caf4b911c196dc2b717f by Natanael Copa on 2013-06-26T14:10:30Z:
```
main/xen: fix xsa55 and xsa57 (CVE-2013-2194,CVE-2013-2195,CVE-2013-2196,CV
E-2013-2211)
ref #2108
ref #2117
fixes #2112
fixes #2121
```Alpine 2.3.7Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2114[v2.7] CVE-2013-2175 : haproxy may crash when using header occurrences relati...2019-07-23T14:20:36ZNatanael Copa[v2.7] CVE-2013-2175 : haproxy may crash when using header occurrences relative to the tailDavid Torgerson reported an haproxy crash with enough traces to
diagnose
the cause as being related to the use of a negative occurrence number
in
a header extraction, which is used to extract an entry starting from
the
last occurre...David Torgerson reported an haproxy crash with enough traces to
diagnose
the cause as being related to the use of a negative occurrence number
in
a header extraction, which is used to extract an entry starting from
the
last occurrence.
—- summary —-
Configurations at risk are those which make use of “hdr\_ip(name,–1)”
(in
1.4) or any hdr\_\* variant with a negative occurrence count in 1.5,
or
the “usesrc hdr\_ip(name)” statement in both 1.4 and 1.5. These
configurations may be crashed when run with haproxy 1.4.4 to 1.4.23 or
development versions up to and including 1.5-dev18. Versions 1.4.24
and
1.5-dev19 are safe.
—- quick workaround —-
A workaround consists in rejecting dangerous requests early using
hdr\_cnt(<name>), which is available both in 1.4 and 1.5 :
block if { hdr\_cnt(<name>) ge 10 }
—- details —-
When a config makes use of hdr\_ip(x-forwarded-for,–1) or any such
thing
involving a negative occurrence count, the header is still parsed in
the
order it appears, and an array of up to MAX\_HDR\_HISTORY entries is
created.
When more entries are used, the entries simply wrap and continue this
way.
A problem happens when the incoming header field count exactly divides
MAX\_HDR\_HISTORY, because the computation removes the number of
requested
occurrences from the count, but does not care about the risk of
wrapping
with a negative number. Thus we can dereference the array with a
negative
number and randomly crash the process.
The bug is located in http\_get\_hdr() in haproxy 1.5, and
get\_ip\_from\_hdr2()
in haproxy 1.4. It affects configurations making use of one of the
following
functions with a negative <value> occurence number :
\- hdr\_ip(<name>, <value>) (in 1.4)
- hdr\_\*(<name>, <value>) (in 1.5)
It also affects “source” statements involving “hdr\_ip(<name>)” since
that
statement implicitly uses –1 for <value> :
\- source 0.0.0.0 usesrc hdr\_ip(<name>)
This bug has been present since the introduction of the negative
offset
count in 1.4.4 via commit bce70882.
CVE-2013-2175 was assigned to this bug.
Special thanks to David Torgerson who provided a significant number of
traces, and to Ryan O’Hara from Red Hat for providing a CVE id.
—- links —-
1.4-stable patch for version <= 1.4.23 :
http://git.1wt.eu/web?p=haproxy-1.4.git;a=commitdiff;h=f534af74ed
1.4.24 source code:
http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.24.tar.gz
1.5-dev patch for versions <= 1.5-dev18 :
http://git.1wt.eu/web?p=haproxy.git;a=commitdiff;h=67dad2715b
1.5-dev19 source code:
http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev19.tar.gz
*(from redmine: issue id 2114, created on 2013-06-21, closed on 2013-07-03)*
* Relations:
* parent #2098
* Changesets:
* Revision d2207b3c4708cac6038cfbb0b7c58722e49c5c4e by Natanael Copa on 2013-06-21T13:37:42Z:
```
main/haproxy: security upgrade to 1.4.24 (CVE-2013-2175)
fixes #2114
```Alpine 2.7.0Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2115[v2.7] Xen Security Advisory 55 (CVE-2013-2194, CVE-2013-2195, CVE-2013-2196)...2019-07-23T14:20:35ZNatanael Copa[v2.7] Xen Security Advisory 55 (CVE-2013-2194, CVE-2013-2195, CVE-2013-2196) - Multiple vulnerabilities in libelf PV kernel handling——<s>BEGIN PGP SIGNED MESSAGE——</s>
Hash: SHA1
Xen Security Advisory CVE-2013-2194,CVE-2013-2195,CVE-2013-2196 /
XSA-55
version 5
Multiple vulnerabilities in libelf PV kernel handling
UPDATES IN VERSION 5
CVE numbers have been ...——<s>BEGIN PGP SIGNED MESSAGE——</s>
Hash: SHA1
Xen Security Advisory CVE-2013-2194,CVE-2013-2195,CVE-2013-2196 /
XSA-55
version 5
Multiple vulnerabilities in libelf PV kernel handling
UPDATES IN VERSION 5
CVE numbers have been assigned.
ISSUE DESCRIPTION
=
The ELF parser used by the Xen tools to read domains’ kernels and
construct domains has multiple integer overflows, pointer dereferences
based on calculations from unchecked input values, and other problems.
This corresponds to the following CVEs:
CVE-2013-2194 XEN XSA-55 integer overflows
CVE-2013-2195 XEN XSA-55 pointer dereferences
CVE-2013-2196 XEN XSA-55 other problems
IMPACT
==
A malicious PV domain administrator who can specify their own kernel
can escalate their privilege to that of the domain construction tools
(i.e., normally, to control of the host).
Additionally a malicious HVM domain administrator who is able to
supply their own firmware (“hvmloader”) can do likewise; however we
think this would be very unusual and it is unlikely that such
configurations exist in production systems.
VULNERABLE SYSTEMS
==
All Xen versions are affected.
Installations which only allow the use of trustworthy kernels for PV
domains are not affected.
MITIGATION
==
Ensuring that PV guests use only trustworthy kernels will avoid this
problem.
RESOLUTION
==
Applying the appropriate patch series will resolve this issue.
These were attached to v3 of the advisory which can be found here:
http://lists.xen.org/archives/html/xen-devel/2013-06/msg01626.html
These are available in xen.git
http://xenbits.xen.org/gitweb/?p=xen.git
git://xenbits.xen.org/xen.git
http://xenbits.xen.org/git-http/xen.git
in the git changesets listed below.
xen-unstable:
82cb4113b6ace16de192021de20f6cbd991e478f libxc: Better range check in
xc\_dom\_alloc\_segment
966070058d02cce9684e30073b61d6465e4b351c libxc: check blob size before
proceeding in xc\_dom\_check\_gzip
de7911eaef98b6643d80e4612fe4dcd4528d15b9 libxc: range checks in
xc\_dom\_p2m\_host
and \_guest
3d5a1d4733e55e33521cd5004cab1313e5c5d5ff libxc: check return values from
malloc
aaebaba5ae225f591e0602e071037a935bb281b6 libxc: check failure of
xc\_dom\_\*\_to\_ptr, xc\_map\_foreign\_range
2bcee4b3c316379f4b52cb308947eb6db3faf1a0 libxc: Add range checking to
xc\_dom\_binloader
66fe2726fe8492676f9970b9c2c511bce6186ece libelf: abolish obsolete
macros
39bf7b9d0ae534491745e54df5232127c0bddaf1 libelf: check loops for running
away
a004800f8fc607b96527815c8e3beabcb455d8e0 libelf: use only unsigned
integers
7a549a6aa04dba807f8dd4c1577ab6a7592c4c76 libelf: use C99 bool for
booleans
c84481fbc7de7d15ff7476b3b9cd2713f81feaa3 libelf: Make all callers call
elf\_check\_broken
943de71cf07d9d04ccb215bd46153b04930e9f25 libelf: Check pointer
references in
elf\_is\_elfbinary
65808a8ed41cc7c044f588bd6cab5af0fdc0e029 libelf: check all pointer
accesses
04877847ade4ac9216e9f408fd544ade8f90cf9a libelf: check nul-terminated
strings
properly
50421bd56bf164f490d7d0bf5741e58936de41e8 tools/xcutils/readnotes:
adjust
print\_l1\_mfn\_valid\_note
85256359995587df00001dca22e9a76ba6ea8258 libelf: introduce macros for
memory
access and pointer handling
95dd49bed681af93f71a401b0a35bf2f917c6e68
libelf/xc\_dom\_load\_elf\_symtab: Do not
use “syms” uninitialised
f7aa72ec00aec71eed055dac5e8a151966d75c9c libelf: move include of
<asm/guest\_access.h>to top of file
13e2c808f7ea721c8f200062e2b9b977ee924471 libelf: abolish elf\_sval and
elf\_access\_signed
009ddca51504ce80889937e485d44ac0f9290d63 libelf: add \`struct
elf\_binary\*’
parameter to elf\_load\_image
b5a869209998fedadfe205d37addbd50a802998b libxc: Fix range checking in
xc\_dom\_pfn\_to\_ptr etc.
53bfcf585b09eb4ac2240f89d1ade77421cd2451 libxc: introduce
xc\_dom\_seg\_to\_ptr\_pages
14573b974850d82de7aebad17e6471d27d847f2c libelf: abolish
libelf-relocate.c
Xen 4.2.x:
d21d36e84354c04638b60a739a5f7c3d9f8adaf8 libxc: Better range check in
xc\_dom\_alloc\_segment
2a548e22915535ac13694eb38222903bca7245e3 libxc: check blob size before
proceeding in xc\_dom\_check\_gzip
052a689aa526ca51fd70528d4b0f83dfb2de99c1 libxc: range checks in
xc\_dom\_p2m\_host
and \_guest
8dc90d163650ce8aa36ae0b46debab83cc61edb6 libxc: check return values from
malloc
77c0829fa751f052f7b8ec08287aef6e7ba97bc5 libxc: check failure of
xc\_dom\_\*\_to\_ptr, xc\_map\_foreign\_range
b06e277b1fc08c7da3befeb3ac3950e1d941585d libxc: Add range checking to
xc\_dom\_binloader
3baaa4ffcd3e7dd6227f9bdf817f90e5b75aeda2 libelf: abolish obsolete
macros
52d8cc2dd3bb3e0f6d51e00280da934e8d91653a libelf: check loops for running
away
e673ca50127b6c1263727aa31de0b8bb966ca7a2 libelf: use only unsigned
integers
3fb6ccf2faccaf5e22e33a3155ccc72d732896d8 libelf: use C99 bool for
booleans
a965b8f80388603d439ae2b8ee7b9b018a079f90 libelf: Make all callers call
elf\_check\_broken
d0790bdad7496e720416b2d4a04563c4c27e7b95 libelf: Check pointer
references in
elf\_is\_elfbinary
cc8761371aac432318530c2ddfe2c8234bc0621f libelf: check all pointer
accesses
db14d5bd9b6508adfcd2b910f454fae12fa4ba00 libelf: check nul-terminated
strings
properly
59f66d58180832af6b99a9e4489031b5c2f627ab tools/xcutils/readnotes:
adjust
print\_l1\_mfn\_valid\_note
40020ab55a1e9a1674ddecdb70299fab4fe8579d libelf: introduce macros for
memory
access and pointer handling
de9089b449d2508b1ba05590905c7ebaee00c8c4
libelf/xc\_dom\_load\_elf\_symtab: Do not
use “syms” uninitialised
682a04488e7b3bd6c3448ab60599566eb7c6177a libelf: move include of
<asm/guest\_access.h>to top of file
83ec905922b496e1a5756e3a88405eb6c2c6ba88 libelf: abolish elf\_sval and
elf\_access\_signed
035634047d10c678cbb8801c4263747bdaf4e5b1 libelf: add \`struct
elf\_binary\*’
parameter to elf\_load\_image
8c738fa5c1f3cfcd935b6191b3526f7ac8b2a5bd libxc: Fix range checking in
xc\_dom\_pfn\_to\_ptr etc.
a672da4b2d58ef12be9d7407160e9fb43cac75d9 libxc: introduce
xc\_dom\_seg\_to\_ptr\_pages
9737484becab4a25159f1e985700eaee89690d34 libelf: abolish
libelf-relocate.c
Xen 4.1.x:
ac63ddd70a5ccf5ebf790f06ea4cd4ed794c3978 libxc: check blob size before
proceeding in xc\_dom\_check\_gzip
6eca85d5c144ee8c899ee3cf8791f9087b15f2e8 libxc: range checks in
xc\_dom\_p2m\_host
and \_guest
a2986a7959919bc748784bb75970bfbd42697d3b libxc: check return values from
malloc
117a538dbef62f8d39159dea652e633e01b50a9a libxc: check failure of
xc\_dom\_\*\_to\_ptr, xc\_map\_foreign\_range
40b76f1fb04af421c1415f7bcb168dfaa6960d0d libxc: Add range checking to
xc\_dom\_binloader
4a3a60d8caee49af6951a672c55b08436a8d1f86 libelf: abolish obsolete
macros
968c0399159c65e24bb8b9969259e18791e1f4d8 libelf: check loops for running
away
282188ea84b9e0f9c4865f0609e7740f2f28e7b0 libxc: Introduce xc\_bitops.h
86e39ce58e91fe55d4fdbc914cb1955c45acc20e libelf: use only unsigned
integers
bd3dba9f435fa59f305407f7d9b34e1e164ddd98 libelf: use C99 bool for
booleans
44c74b1ed31c75ed9026abf62ab7427a46d8027a libelf: Make all callers call
elf\_check\_broken
9962d7ffcce97ec2d69a15ef861996b1ead33694 libelf: Check pointer
references in
elf\_is\_elfbinary
39923542bb43e67776c4e8292d4a5a1adef2bd3b libelf: check all pointer
accesses
8ce60b35beaac91a97b79c004ca6bf5d58e7390b libelf: check nul-terminated
strings
properly
4e46085972d2367dff2345a73361c1c17b47ce73 tools/xcutils/readnotes:
adjust
print\_l1\_mfn\_valid\_note
de49d6e83c3a8c753646b007972140ddbb746ba8 libelf: introduce macros for
memory
access and pointer handling
4d3339de1fe3cbf7b05487fdb6cadd7267950948
libelf/xc\_dom\_load\_elf\_symtab: Do not
use “syms” uninitialised
e719b136b750e5eee87c4647d1846e4e1e70eac0 libelf: abolish elf\_sval and
elf\_access\_signed
f7fb94409c562beec06094141ef262dc85f28dac libxc: Fix range checking in
xc\_dom\_pfn\_to\_ptr etc.
bbf40e6b6d47809f4289a866d7d167c25104ecc0 libxc: introduce
xc\_dom\_seg\_to\_ptr\_pages
64a0206c451920b72a9c5721a6f2427baf99e3dd libelf: abolish
libelf-relocate.c
——<s>BEGIN PGP SIGNATURE——</s>
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJRwticAAoJEIP+FMlX6CvZFbEIAMjbI64TpgYSm3cRSFmdHol/
FC2d4mo/aeb8e24RCTnJvxP3oE+o1Oar5FGJi+AATDynzbqcuv7yK7iDQ9ZfwGm5
xZR+knkFKymWLsutb8uhDRT8eYCgmK8aQEXorvcjr69sxrxJascPGv4aHesNihxO
t4tRqRbqGhAzkm9Gm32LaVz3UYCW2ZRs4lxDBjtW5HmsugaOarCYNTqSpftAiAkn
XE8UChNUVO95PAJKRtmihLQ+TGJ9cyujBACrl6RsxdD8JZU6EP4rq7fccdzyqD6D
+c5pw859mtukyy56fwfP5Ji6G9O2VrrZyf4kq13V74SPZ/LV3VKDalfaVVItLGQ=
=RVh5
——<s>END PGP SIGNATURE——</s>
*(from redmine: issue id 2115, created on 2013-06-21, closed on 2013-07-03)*
* Relations:
* parent #2108
* Changesets:
* Revision f78e9dea47b7c130cb417d9826c984d8664f01ec by Natanael Copa on 2013-06-21T15:32:40Z:
```
main/xen: security fix (CVE-2013-2194,CVE-2013-2195,CVE-2013-2196)
fixes #2115
```Alpine 2.7.0Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2116Fw: [alpine-devel] Tmux dependencies2019-07-23T14:20:34ZNatanael CopaFw: [alpine-devel] Tmux dependenciesBegin forwarded message:
Date: Sat, 22 Jun 2013 02:19:08 +0200
From: Oliver Loch
To: “alpine-devel@lists.alpinelinux.org Development”
Subject: \[alpine-devel\] Tmux
dependencies
Hi,
the maintainer of the tmux package should ad...Begin forwarded message:
Date: Sat, 22 Jun 2013 02:19:08 +0200
From: Oliver Loch
To: “alpine-devel@lists.alpinelinux.org Development”
Subject: \[alpine-devel\] Tmux
dependencies
Hi,
the maintainer of the tmux package should add ncurses-terminfo to its
dependencies, else it fails if you logon via ssh from a machine
running
X:
ldt3:~\# tmux
open terminal failed: missing or unsuitable terminal: xterm-256color
KR,
Oliver
—
-nc
*(from redmine: issue id 2116, created on 2013-06-23, closed on 2013-07-02)*
* Changesets:
* Revision db9fb3315f2265f80149324cea527ec3efc8e93e by Natanael Copa on 2013-06-26T10:01:09Z:
```
main/tmux: add ncurses-terminfo as a dependency
ref #2116
```
* Revision 052803fcf280e0ade32c0ca64438c37476c84525 by Natanael Copa on 2013-06-26T10:04:34Z:
```
main/tmux: add ncurses-terminfo as a dependency
fixes #2116
(cherry picked from commit db9fb3315f2265f80149324cea527ec3efc8e93e)
```Alpine 2.6.2https://gitlab.alpinelinux.org/alpine/aports/-/issues/2117Xen Security Advisory 57 - libxl allows guest write access to sensitive conso...2019-07-23T14:20:32ZPeter KotcauerXen Security Advisory 57 - libxl allows guest write access to sensitive console related xenstore keys (CVE-2013-2211 )ISSUE DESCRIPTION
=
The libxenlight (libxl) toolstack library does not correctly set
permissions on xenstore keys relating to paravirtualised and emulated
serial console devices. This could allow a malicious guest
administrator ...ISSUE DESCRIPTION
=
The libxenlight (libxl) toolstack library does not correctly set
permissions on xenstore keys relating to paravirtualised and emulated
serial console devices. This could allow a malicious guest
administrator to change values in xenstore which the host later relies
on being implicitly trusted.
IMPACT
==
A malicious guest administrator can read and write any files in the
host filesystem which are accessible to the user id running the
xenconsole client binary. This may be the user id of a host
administrator who connects to the guest’s console or the user id of
any self service mechanism provided to guest administrators by the
host provider.
As well as reading and writing files an attacker with access to an HVM
guest can cause any PV or serial consoles to be connected to a variety
of network resources (sockets, udp connections) or other end points
(fifo, pipes) in the host file filesystem according to the privileges
granted to the qemu device model for that guest.
A malicious guest administrator can also redirect the VNC console
port of the guest to another port on the host. This may expose the VNC
port of other guests or of other firewalled services to an attack.
VULNERABLE SYSTEMS
==
All systems which use libxl as part of the toolstack are vulnerable.
libxl is present in Xen versions 4.0 onwards.
The major consumer of libxl functionality is the xl toolstack which
became the default in Xen 4.2.
In addition to this libvirt can optionally make use of libxl. This can
be queried with
\# virsh version
Which will report “xenlight” if libxl is in use. libvirt currently
prefers the xend backend if xend is running.
The xend and xapi toolstacks do not currently use libxl.
MITIGATION
==
Host administrators can start a domain paused and manually correct the
xenstore permissions of the relevant nodes.
A domain can be started in the paused state with xl by using
\# xl create -p <cfg>
A domain’s domid can then be determined with:
\# xl domid <name>
If using libvirt then virsh can be used instead:
\# virsh start —paused <name>
\# virsh domid <name>
For a domain $DOMID the following command will recursively correct the
permissions for the primary PV console:
\# xenstore-chmod -r /local/domain/$DOMID/console n0 r$DOMID
If the domain uses a device model stubdomain then it will also be
necessary to fix the permissions for the stubdomain. The stubdomain is
named “<name>-dm”. Assuming its domain ID is $DMDOM:
\# xenstore-chmod -r /local/domain/$DMDOM/console n0 r$DMDOM
In addition a stub domain has three secondary PV consoles which must
be
fixed, however in this case the “state” and “protocol” nodes along
with the device node itself should not be restricted. For each device
$D in \[1,2,3\]:
\# xenstore-chmod -r /local/domain/$DMDOM/device/console/$N n0 r$DMDOM
\# xenstore-chmod /local/domain/$DMDOM/device/console/$N/state n$DMDOM
r0
\# xenstore-chmod /local/domain/$DMDOM/device/console/$N/protocol
n$DMDOM r0
\# xenstore-chmod /local/domain/$DMDOM/device/console/$N n$DMDOM r0
The current permissions can be listed with
\# xenstore-ls -fp <PATH>
Once the permissions are fixed you may unpause the domain with
\# xl unpause <domain>
or with virsh:
\# virsh resume <domain>
The permissions can also be corrected on a live system if they are
then manually validated to be non-malicious.
See http://wiki.xen.org/wiki/XenBus\#Permissions for information on
the
permissions syntax.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa57-4.2.patch Xen 4.2.x
xsa57-4.1.patch Xen 4.1.x
xsa57-unstable.patch xen-unstable
$ sha256sum xsa57-\*.patch
428a1d42f4314404cde339a78a59422bf4f0590c4d16ea8adc83425fe5eede3d
xsa57-4.1.patch
b6a5106848541972519cc529859d9ff3083c79367276c7031560fa4ce6f9f770
xsa57-4.2.patch
d329f56c30f7a4f91906658ea661234d2ca31b74ee68257bf009072999b3d3ef
xsa57-unstable.patch
*(from redmine: issue id 2117, created on 2013-06-26, closed on 2013-07-03)*
* Relations:
* child #2118
* child #2119
* child #2120
* child #2121
* child #2122
* Changesets:
* Revision 932f289cf129abc7a42e3160b4e30b2e720d0633 by Natanael Copa on 2013-06-26T11:48:01Z:
```
main/xen: fix xsa57 (CVE-2013-2211)
ref #2117
fixes #2122
```
* Revision 638e4f7ceb5b5a8b9f9c7c3206fcd9e7c39d2bee by Natanael Copa on 2013-06-26T11:48:55Z:
```
main/xen: fix xsa57 (CVE-2013-2211)
ref #2117
fixes #2118
```
* Revision c78cd179455d0b332fcc2d9cbe05cf71876ec239 by Natanael Copa on 2013-06-26T11:53:15Z:
```
main/xen: fix xsa57 (CVE-2013-2211)
ref #2117
fixes #2119
(cherry picked from commit 932f289cf129abc7a42e3160b4e30b2e720d0633)
Conflicts:
main/xen/APKBUILD
```
* Revision 386d947eaf640de1a5515087a2b65d5960e5624b by Natanael Copa on 2013-06-26T13:59:41Z:
```
main/xen: fix xsa55 and xsa57 (CVE-2013-2194,CVE-2013-2195,CVE-2013-2196,CVE-2013-2211)
ref #2108
ref #2117
fixes #2111
fixes #2120
```
* Revision dac4485dfa4d8ae59e99caf4b911c196dc2b717f by Natanael Copa on 2013-06-26T14:10:30Z:
```
main/xen: fix xsa55 and xsa57 (CVE-2013-2194,CVE-2013-2195,CVE-2013-2196,CV
E-2013-2211)
ref #2108
ref #2117
fixes #2112
fixes #2121
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/2118[v2.6] Xen Security Advisory 57 - libxl allows guest write access to sensitiv...2019-07-23T14:20:31ZPeter Kotcauer[v2.6] Xen Security Advisory 57 - libxl allows guest write access to sensitive console related xenstore keys (CVE-2013-2211 )ISSUE DESCRIPTION
=
The libxenlight (libxl) toolstack library does not correctly set
permissions on xenstore keys relating to paravirtualised and emulated
serial console devices. This could allow a malicious guest
administrator ...ISSUE DESCRIPTION
=
The libxenlight (libxl) toolstack library does not correctly set
permissions on xenstore keys relating to paravirtualised and emulated
serial console devices. This could allow a malicious guest
administrator to change values in xenstore which the host later relies
on being implicitly trusted.
IMPACT
==
A malicious guest administrator can read and write any files in the
host filesystem which are accessible to the user id running the
xenconsole client binary. This may be the user id of a host
administrator who connects to the guest’s console or the user id of
any self service mechanism provided to guest administrators by the
host provider.
As well as reading and writing files an attacker with access to an HVM
guest can cause any PV or serial consoles to be connected to a variety
of network resources (sockets, udp connections) or other end points
(fifo, pipes) in the host file filesystem according to the privileges
granted to the qemu device model for that guest.
A malicious guest administrator can also redirect the VNC console
port of the guest to another port on the host. This may expose the VNC
port of other guests or of other firewalled services to an attack.
VULNERABLE SYSTEMS
==
All systems which use libxl as part of the toolstack are vulnerable.
libxl is present in Xen versions 4.0 onwards.
The major consumer of libxl functionality is the xl toolstack which
became the default in Xen 4.2.
In addition to this libvirt can optionally make use of libxl. This can
be queried with
\# virsh version
Which will report “xenlight” if libxl is in use. libvirt currently
prefers the xend backend if xend is running.
The xend and xapi toolstacks do not currently use libxl.
MITIGATION
==
Host administrators can start a domain paused and manually correct the
xenstore permissions of the relevant nodes.
A domain can be started in the paused state with xl by using
\# xl create -p <cfg>
A domain’s domid can then be determined with:
\# xl domid <name>
If using libvirt then virsh can be used instead:
\# virsh start —paused <name>
\# virsh domid <name>
For a domain $DOMID the following command will recursively correct the
permissions for the primary PV console:
\# xenstore-chmod -r /local/domain/$DOMID/console n0 r$DOMID
If the domain uses a device model stubdomain then it will also be
necessary to fix the permissions for the stubdomain. The stubdomain is
named “<name>-dm”. Assuming its domain ID is $DMDOM:
\# xenstore-chmod -r /local/domain/$DMDOM/console n0 r$DMDOM
In addition a stub domain has three secondary PV consoles which must
be
fixed, however in this case the “state” and “protocol” nodes along
with the device node itself should not be restricted. For each device
$D in \[1,2,3\]:
\# xenstore-chmod -r /local/domain/$DMDOM/device/console/$N n0 r$DMDOM
\# xenstore-chmod /local/domain/$DMDOM/device/console/$N/state n$DMDOM
r0
\# xenstore-chmod /local/domain/$DMDOM/device/console/$N/protocol
n$DMDOM r0
\# xenstore-chmod /local/domain/$DMDOM/device/console/$N n$DMDOM r0
The current permissions can be listed with
\# xenstore-ls -fp <PATH>
Once the permissions are fixed you may unpause the domain with
\# xl unpause <domain>
or with virsh:
\# virsh resume <domain>
The permissions can also be corrected on a live system if they are
then manually validated to be non-malicious.
See http://wiki.xen.org/wiki/XenBus\#Permissions for information on
the
permissions syntax.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa57-4.2.patch Xen 4.2.x
xsa57-4.1.patch Xen 4.1.x
xsa57-unstable.patch xen-unstable
$ sha256sum xsa57-\*.patch
428a1d42f4314404cde339a78a59422bf4f0590c4d16ea8adc83425fe5eede3d
xsa57-4.1.patch
b6a5106848541972519cc529859d9ff3083c79367276c7031560fa4ce6f9f770
xsa57-4.2.patch
d329f56c30f7a4f91906658ea661234d2ca31b74ee68257bf009072999b3d3ef
xsa57-unstable.patch
*(from redmine: issue id 2118, created on 2013-06-26, closed on 2013-07-02)*
* Relations:
* parent #2117
* Changesets:
* Revision 638e4f7ceb5b5a8b9f9c7c3206fcd9e7c39d2bee by Natanael Copa on 2013-06-26T11:48:55Z:
```
main/xen: fix xsa57 (CVE-2013-2211)
ref #2117
fixes #2118
```Alpine 2.6.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2119[v2.5] Xen Security Advisory 57 - libxl allows guest write access to sensitiv...2019-07-23T14:20:30ZPeter Kotcauer[v2.5] Xen Security Advisory 57 - libxl allows guest write access to sensitive console related xenstore keys (CVE-2013-2211 )ISSUE DESCRIPTION
=
The libxenlight (libxl) toolstack library does not correctly set
permissions on xenstore keys relating to paravirtualised and emulated
serial console devices. This could allow a malicious guest
administrator ...ISSUE DESCRIPTION
=
The libxenlight (libxl) toolstack library does not correctly set
permissions on xenstore keys relating to paravirtualised and emulated
serial console devices. This could allow a malicious guest
administrator to change values in xenstore which the host later relies
on being implicitly trusted.
IMPACT
==
A malicious guest administrator can read and write any files in the
host filesystem which are accessible to the user id running the
xenconsole client binary. This may be the user id of a host
administrator who connects to the guest’s console or the user id of
any self service mechanism provided to guest administrators by the
host provider.
As well as reading and writing files an attacker with access to an HVM
guest can cause any PV or serial consoles to be connected to a variety
of network resources (sockets, udp connections) or other end points
(fifo, pipes) in the host file filesystem according to the privileges
granted to the qemu device model for that guest.
A malicious guest administrator can also redirect the VNC console
port of the guest to another port on the host. This may expose the VNC
port of other guests or of other firewalled services to an attack.
VULNERABLE SYSTEMS
==
All systems which use libxl as part of the toolstack are vulnerable.
libxl is present in Xen versions 4.0 onwards.
The major consumer of libxl functionality is the xl toolstack which
became the default in Xen 4.2.
In addition to this libvirt can optionally make use of libxl. This can
be queried with
\# virsh version
Which will report “xenlight” if libxl is in use. libvirt currently
prefers the xend backend if xend is running.
The xend and xapi toolstacks do not currently use libxl.
MITIGATION
==
Host administrators can start a domain paused and manually correct the
xenstore permissions of the relevant nodes.
A domain can be started in the paused state with xl by using
\# xl create -p <cfg>
A domain’s domid can then be determined with:
\# xl domid <name>
If using libvirt then virsh can be used instead:
\# virsh start —paused <name>
\# virsh domid <name>
For a domain $DOMID the following command will recursively correct the
permissions for the primary PV console:
\# xenstore-chmod -r /local/domain/$DOMID/console n0 r$DOMID
If the domain uses a device model stubdomain then it will also be
necessary to fix the permissions for the stubdomain. The stubdomain is
named “<name>-dm”. Assuming its domain ID is $DMDOM:
\# xenstore-chmod -r /local/domain/$DMDOM/console n0 r$DMDOM
In addition a stub domain has three secondary PV consoles which must
be
fixed, however in this case the “state” and “protocol” nodes along
with the device node itself should not be restricted. For each device
$D in \[1,2,3\]:
\# xenstore-chmod -r /local/domain/$DMDOM/device/console/$N n0 r$DMDOM
\# xenstore-chmod /local/domain/$DMDOM/device/console/$N/state n$DMDOM
r0
\# xenstore-chmod /local/domain/$DMDOM/device/console/$N/protocol
n$DMDOM r0
\# xenstore-chmod /local/domain/$DMDOM/device/console/$N n$DMDOM r0
The current permissions can be listed with
\# xenstore-ls -fp <PATH>
Once the permissions are fixed you may unpause the domain with
\# xl unpause <domain>
or with virsh:
\# virsh resume <domain>
The permissions can also be corrected on a live system if they are
then manually validated to be non-malicious.
See http://wiki.xen.org/wiki/XenBus\#Permissions for information on
the
permissions syntax.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa57-4.2.patch Xen 4.2.x
xsa57-4.1.patch Xen 4.1.x
xsa57-unstable.patch xen-unstable
$ sha256sum xsa57-\*.patch
428a1d42f4314404cde339a78a59422bf4f0590c4d16ea8adc83425fe5eede3d
xsa57-4.1.patch
b6a5106848541972519cc529859d9ff3083c79367276c7031560fa4ce6f9f770
xsa57-4.2.patch
d329f56c30f7a4f91906658ea661234d2ca31b74ee68257bf009072999b3d3ef
xsa57-unstable.patch
*(from redmine: issue id 2119, created on 2013-06-26, closed on 2013-07-03)*
* Relations:
* parent #2117
* Changesets:
* Revision c78cd179455d0b332fcc2d9cbe05cf71876ec239 by Natanael Copa on 2013-06-26T11:53:15Z:
```
main/xen: fix xsa57 (CVE-2013-2211)
ref #2117
fixes #2119
(cherry picked from commit 932f289cf129abc7a42e3160b4e30b2e720d0633)
Conflicts:
main/xen/APKBUILD
```Alpine 2.5.5Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2120[v2.4] Xen Security Advisory 57 - libxl allows guest write access to sensitiv...2019-07-23T14:20:29ZPeter Kotcauer[v2.4] Xen Security Advisory 57 - libxl allows guest write access to sensitive console related xenstore keys (CVE-2013-2211 )ISSUE DESCRIPTION
=
The libxenlight (libxl) toolstack library does not correctly set
permissions on xenstore keys relating to paravirtualised and emulated
serial console devices. This could allow a malicious guest
administrator ...ISSUE DESCRIPTION
=
The libxenlight (libxl) toolstack library does not correctly set
permissions on xenstore keys relating to paravirtualised and emulated
serial console devices. This could allow a malicious guest
administrator to change values in xenstore which the host later relies
on being implicitly trusted.
IMPACT
==
A malicious guest administrator can read and write any files in the
host filesystem which are accessible to the user id running the
xenconsole client binary. This may be the user id of a host
administrator who connects to the guest’s console or the user id of
any self service mechanism provided to guest administrators by the
host provider.
As well as reading and writing files an attacker with access to an HVM
guest can cause any PV or serial consoles to be connected to a variety
of network resources (sockets, udp connections) or other end points
(fifo, pipes) in the host file filesystem according to the privileges
granted to the qemu device model for that guest.
A malicious guest administrator can also redirect the VNC console
port of the guest to another port on the host. This may expose the VNC
port of other guests or of other firewalled services to an attack.
VULNERABLE SYSTEMS
==
All systems which use libxl as part of the toolstack are vulnerable.
libxl is present in Xen versions 4.0 onwards.
The major consumer of libxl functionality is the xl toolstack which
became the default in Xen 4.2.
In addition to this libvirt can optionally make use of libxl. This can
be queried with
\# virsh version
Which will report “xenlight” if libxl is in use. libvirt currently
prefers the xend backend if xend is running.
The xend and xapi toolstacks do not currently use libxl.
MITIGATION
==
Host administrators can start a domain paused and manually correct the
xenstore permissions of the relevant nodes.
A domain can be started in the paused state with xl by using
\# xl create -p <cfg>
A domain’s domid can then be determined with:
\# xl domid <name>
If using libvirt then virsh can be used instead:
\# virsh start —paused <name>
\# virsh domid <name>
For a domain $DOMID the following command will recursively correct the
permissions for the primary PV console:
\# xenstore-chmod -r /local/domain/$DOMID/console n0 r$DOMID
If the domain uses a device model stubdomain then it will also be
necessary to fix the permissions for the stubdomain. The stubdomain is
named “<name>-dm”. Assuming its domain ID is $DMDOM:
\# xenstore-chmod -r /local/domain/$DMDOM/console n0 r$DMDOM
In addition a stub domain has three secondary PV consoles which must
be
fixed, however in this case the “state” and “protocol” nodes along
with the device node itself should not be restricted. For each device
$D in \[1,2,3\]:
\# xenstore-chmod -r /local/domain/$DMDOM/device/console/$N n0 r$DMDOM
\# xenstore-chmod /local/domain/$DMDOM/device/console/$N/state n$DMDOM
r0
\# xenstore-chmod /local/domain/$DMDOM/device/console/$N/protocol
n$DMDOM r0
\# xenstore-chmod /local/domain/$DMDOM/device/console/$N n$DMDOM r0
The current permissions can be listed with
\# xenstore-ls -fp <PATH>
Once the permissions are fixed you may unpause the domain with
\# xl unpause <domain>
or with virsh:
\# virsh resume <domain>
The permissions can also be corrected on a live system if they are
then manually validated to be non-malicious.
See http://wiki.xen.org/wiki/XenBus\#Permissions for information on
the
permissions syntax.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa57-4.2.patch Xen 4.2.x
xsa57-4.1.patch Xen 4.1.x
xsa57-unstable.patch xen-unstable
$ sha256sum xsa57-\*.patch
428a1d42f4314404cde339a78a59422bf4f0590c4d16ea8adc83425fe5eede3d
xsa57-4.1.patch
b6a5106848541972519cc529859d9ff3083c79367276c7031560fa4ce6f9f770
xsa57-4.2.patch
d329f56c30f7a4f91906658ea661234d2ca31b74ee68257bf009072999b3d3ef
xsa57-unstable.patch
*(from redmine: issue id 2120, created on 2013-06-26, closed on 2013-07-03)*
* Relations:
* parent #2117
* Changesets:
* Revision 386d947eaf640de1a5515087a2b65d5960e5624b by Natanael Copa on 2013-06-26T13:59:41Z:
```
main/xen: fix xsa55 and xsa57 (CVE-2013-2194,CVE-2013-2195,CVE-2013-2196,CVE-2013-2211)
ref #2108
ref #2117
fixes #2111
fixes #2120
```Alpine 2.4.12Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2121[v2.3] Xen Security Advisory 57 - libxl allows guest write access to sensitiv...2019-07-23T14:20:28ZPeter Kotcauer[v2.3] Xen Security Advisory 57 - libxl allows guest write access to sensitive console related xenstore keys (CVE-2013-2211 )ISSUE DESCRIPTION
=
The libxenlight (libxl) toolstack library does not correctly set
permissions on xenstore keys relating to paravirtualised and emulated
serial console devices. This could allow a malicious guest
administrator ...ISSUE DESCRIPTION
=
The libxenlight (libxl) toolstack library does not correctly set
permissions on xenstore keys relating to paravirtualised and emulated
serial console devices. This could allow a malicious guest
administrator to change values in xenstore which the host later relies
on being implicitly trusted.
IMPACT
==
A malicious guest administrator can read and write any files in the
host filesystem which are accessible to the user id running the
xenconsole client binary. This may be the user id of a host
administrator who connects to the guest’s console or the user id of
any self service mechanism provided to guest administrators by the
host provider.
As well as reading and writing files an attacker with access to an HVM
guest can cause any PV or serial consoles to be connected to a variety
of network resources (sockets, udp connections) or other end points
(fifo, pipes) in the host file filesystem according to the privileges
granted to the qemu device model for that guest.
A malicious guest administrator can also redirect the VNC console
port of the guest to another port on the host. This may expose the VNC
port of other guests or of other firewalled services to an attack.
VULNERABLE SYSTEMS
==
All systems which use libxl as part of the toolstack are vulnerable.
libxl is present in Xen versions 4.0 onwards.
The major consumer of libxl functionality is the xl toolstack which
became the default in Xen 4.2.
In addition to this libvirt can optionally make use of libxl. This can
be queried with
\# virsh version
Which will report “xenlight” if libxl is in use. libvirt currently
prefers the xend backend if xend is running.
The xend and xapi toolstacks do not currently use libxl.
MITIGATION
==
Host administrators can start a domain paused and manually correct the
xenstore permissions of the relevant nodes.
A domain can be started in the paused state with xl by using
\# xl create -p <cfg>
A domain’s domid can then be determined with:
\# xl domid <name>
If using libvirt then virsh can be used instead:
\# virsh start —paused <name>
\# virsh domid <name>
For a domain $DOMID the following command will recursively correct the
permissions for the primary PV console:
\# xenstore-chmod -r /local/domain/$DOMID/console n0 r$DOMID
If the domain uses a device model stubdomain then it will also be
necessary to fix the permissions for the stubdomain. The stubdomain is
named “<name>-dm”. Assuming its domain ID is $DMDOM:
\# xenstore-chmod -r /local/domain/$DMDOM/console n0 r$DMDOM
In addition a stub domain has three secondary PV consoles which must
be
fixed, however in this case the “state” and “protocol” nodes along
with the device node itself should not be restricted. For each device
$D in \[1,2,3\]:
\# xenstore-chmod -r /local/domain/$DMDOM/device/console/$N n0 r$DMDOM
\# xenstore-chmod /local/domain/$DMDOM/device/console/$N/state n$DMDOM
r0
\# xenstore-chmod /local/domain/$DMDOM/device/console/$N/protocol
n$DMDOM r0
\# xenstore-chmod /local/domain/$DMDOM/device/console/$N n$DMDOM r0
The current permissions can be listed with
\# xenstore-ls -fp <PATH>
Once the permissions are fixed you may unpause the domain with
\# xl unpause <domain>
or with virsh:
\# virsh resume <domain>
The permissions can also be corrected on a live system if they are
then manually validated to be non-malicious.
See http://wiki.xen.org/wiki/XenBus\#Permissions for information on
the
permissions syntax.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa57-4.2.patch Xen 4.2.x
xsa57-4.1.patch Xen 4.1.x
xsa57-unstable.patch xen-unstable
$ sha256sum xsa57-\*.patch
428a1d42f4314404cde339a78a59422bf4f0590c4d16ea8adc83425fe5eede3d
xsa57-4.1.patch
b6a5106848541972519cc529859d9ff3083c79367276c7031560fa4ce6f9f770
xsa57-4.2.patch
d329f56c30f7a4f91906658ea661234d2ca31b74ee68257bf009072999b3d3ef
xsa57-unstable.patch
*(from redmine: issue id 2121, created on 2013-06-26, closed on 2013-07-03)*
* Relations:
* parent #2117
* Changesets:
* Revision dac4485dfa4d8ae59e99caf4b911c196dc2b717f by Natanael Copa on 2013-06-26T14:10:30Z:
```
main/xen: fix xsa55 and xsa57 (CVE-2013-2194,CVE-2013-2195,CVE-2013-2196,CV
E-2013-2211)
ref #2108
ref #2117
fixes #2112
fixes #2121
```Alpine 2.3.7Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2122[v2.7] Xen Security Advisory 57 - libxl allows guest write access to sensitiv...2019-07-23T14:20:26ZNatanael Copa[v2.7] Xen Security Advisory 57 - libxl allows guest write access to sensitive console related xenstore keys (CVE-2013-2211 )ISSUE DESCRIPTION
=
The libxenlight (libxl) toolstack library does not correctly set
permissions on xenstore keys relating to paravirtualised and emulated
serial console devices. This could allow a malicious guest
administrator ...ISSUE DESCRIPTION
=
The libxenlight (libxl) toolstack library does not correctly set
permissions on xenstore keys relating to paravirtualised and emulated
serial console devices. This could allow a malicious guest
administrator to change values in xenstore which the host later relies
on being implicitly trusted.
IMPACT
==
A malicious guest administrator can read and write any files in the
host filesystem which are accessible to the user id running the
xenconsole client binary. This may be the user id of a host
administrator who connects to the guest’s console or the user id of
any self service mechanism provided to guest administrators by the
host provider.
As well as reading and writing files an attacker with access to an HVM
guest can cause any PV or serial consoles to be connected to a variety
of network resources (sockets, udp connections) or other end points
(fifo, pipes) in the host file filesystem according to the privileges
granted to the qemu device model for that guest.
A malicious guest administrator can also redirect the VNC console
port of the guest to another port on the host. This may expose the VNC
port of other guests or of other firewalled services to an attack.
VULNERABLE SYSTEMS
==
All systems which use libxl as part of the toolstack are vulnerable.
libxl is present in Xen versions 4.0 onwards.
The major consumer of libxl functionality is the xl toolstack which
became the default in Xen 4.2.
In addition to this libvirt can optionally make use of libxl. This can
be queried with
\# virsh version
Which will report “xenlight” if libxl is in use. libvirt currently
prefers the xend backend if xend is running.
The xend and xapi toolstacks do not currently use libxl.
MITIGATION
==
Host administrators can start a domain paused and manually correct the
xenstore permissions of the relevant nodes.
A domain can be started in the paused state with xl by using
\# xl create -p <cfg>
A domain’s domid can then be determined with:
\# xl domid <name>
If using libvirt then virsh can be used instead:
\# virsh start —paused <name>
\# virsh domid <name>
For a domain $DOMID the following command will recursively correct the
permissions for the primary PV console:
\# xenstore-chmod -r /local/domain/$DOMID/console n0 r$DOMID
If the domain uses a device model stubdomain then it will also be
necessary to fix the permissions for the stubdomain. The stubdomain is
named “<name>-dm”. Assuming its domain ID is $DMDOM:
\# xenstore-chmod -r /local/domain/$DMDOM/console n0 r$DMDOM
In addition a stub domain has three secondary PV consoles which must
be
fixed, however in this case the “state” and “protocol” nodes along
with the device node itself should not be restricted. For each device
$D in \[1,2,3\]:
\# xenstore-chmod -r /local/domain/$DMDOM/device/console/$N n0 r$DMDOM
\# xenstore-chmod /local/domain/$DMDOM/device/console/$N/state n$DMDOM
r0
\# xenstore-chmod /local/domain/$DMDOM/device/console/$N/protocol
n$DMDOM r0
\# xenstore-chmod /local/domain/$DMDOM/device/console/$N n$DMDOM r0
The current permissions can be listed with
\# xenstore-ls -fp <PATH>
Once the permissions are fixed you may unpause the domain with
\# xl unpause <domain>
or with virsh:
\# virsh resume <domain>
The permissions can also be corrected on a live system if they are
then manually validated to be non-malicious.
See http://wiki.xen.org/wiki/XenBus\#Permissions for information on
the
permissions syntax.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa57-4.2.patch Xen 4.2.x
xsa57-4.1.patch Xen 4.1.x
xsa57-unstable.patch xen-unstable
$ sha256sum xsa57-\*.patch
428a1d42f4314404cde339a78a59422bf4f0590c4d16ea8adc83425fe5eede3d
xsa57-4.1.patch
b6a5106848541972519cc529859d9ff3083c79367276c7031560fa4ce6f9f770
xsa57-4.2.patch
d329f56c30f7a4f91906658ea661234d2ca31b74ee68257bf009072999b3d3ef
xsa57-unstable.patch
*(from redmine: issue id 2122, created on 2013-06-26, closed on 2013-07-03)*
* Relations:
* parent #2117
* Changesets:
* Revision 932f289cf129abc7a42e3160b4e30b2e720d0633 by Natanael Copa on 2013-06-26T11:48:01Z:
```
main/xen: fix xsa57 (CVE-2013-2211)
ref #2117
fixes #2122
```Alpine 2.7.0Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2123Xen Security Advisory 58 (CVE-2013-1432) - Page reference counting error due ...2019-07-23T14:20:25ZPeter KotcauerXen Security Advisory 58 (CVE-2013-1432) - Page reference counting error due to XSA-45/CVE-2013-1918 fixesreferences:
http://lists.xen.org/archives/html/xen-announce/2013-06/msg00012.html
ISSUE DESCRIPTION
=
The XSA-45/CVE-2013-1918 patch making error handling paths preemptible
broke
page reference counting by not retaining a referen...references:
http://lists.xen.org/archives/html/xen-announce/2013-06/msg00012.html
ISSUE DESCRIPTION
=
The XSA-45/CVE-2013-1918 patch making error handling paths preemptible
broke
page reference counting by not retaining a reference on pages stored
for
deferred cleanup. This would lead to the hypervisor prematurely
attempting to
free the page, generally crashing upon finding the page still in use.
CREDITS
===
Thanks to Andrew Cooper and the Citrix XenServer team for discovering
and reporting this vulnerability, and helping investigate it.
IMPACT
==
Malicious or buggy PV guest kernels can mount a denial of service
attack
affecting the whole system. It can’t be excluded that this could also
be
exploited to mount a privilege escalation attack.
VULNERABLE SYSTEMS
==
All Xen versions having the XSA-45/CVE-2013-1918 fixes applied are
vulnerable.
The vulnerability is only exposed by PV guests.
MITIGATION
==
Running only HVM guests, or PV guests with trusted kernels, will avoid
this
vulnerability.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa58-4.1.patch Xen 4.1.x
xsa58-4.2.patch Xen 4.2.x
xsa58-unstable.patch xen-unstable
$ sha256sum xsa58\*.patch
3623ec87e5a2830f0d41de19a8e448d618954973c3264727a1f3a095f15a8641
xsa58-4.1.patch
194d6610fc38b767d643e5d58a1268f45921fb35e309b47aca6a388b861311c2
xsa58-4.2.patch
2c94b099d7144d03c0f7f44e892a521537fc040d11bc46f84a2438eece46a0f5
xsa58-unstable.patch
*(from redmine: issue id 2123, created on 2013-06-26, closed on 2013-07-03)*
* Relations:
* child #2124
* child #2125
* child #2126
* child #2127
* Changesets:
* Revision 448e4822bbf8a2b4aa8b8f8d8153a2a0b4e0efda by Natanael Copa on 2013-07-01T16:38:45Z:
```
main/xen: fix xsa45 and xsa58 (CVE-2013-1918,CVE-2013-1432)
ref #2123
```
* Revision ccdb8c3a1257db6b1ceb3af663b239003a047fd3 by Natanael Copa on 2013-07-01T16:44:49Z:
```
main/xen: fix xsa45 and xsa58 (CVE-2013-1918,CVE-2013-1432)
ref #2123
fixes #2124
(cherry picked from commit 448e4822bbf8a2b4aa8b8f8d8153a2a0b4e0efda)
Conflicts:
main/xen/APKBUILD
```
* Revision 02b9902f054427e1abb33ff073d866be0c332d70 by Natanael Copa on 2013-07-01T16:49:55Z:
```
main/xen: fix xsa45 and xsa58 (CVE-2013-1918,CVE-2013-1432)
ref #2123
fixes #2125
(cherry picked from commit 448e4822bbf8a2b4aa8b8f8d8153a2a0b4e0efda)
Conflicts:
main/xen/APKBUILD
```
* Revision f87a9718398452ab5e15eccd2eb427d16098c072 by Natanael Copa on 2013-07-01T17:02:29Z:
```
main/xen: main/xen: fix xsa45 and xsa58 (CVE-2013-1918,CVE-2013-1432)
ref #2123
fixes #2126
```
* Revision 14e8058dddb5be40c29deb267ffbc23171991c7a by Natanael Copa on 2013-07-02T11:54:33Z:
```
main/xen: main/xen: fix xsa45 and xsa58 (CVE-2013-1918,CVE-2013-1432)
ref #2123
fixes #2127
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/2124[v2.6] Xen Security Advisory 58 (CVE-2013-1432) - Page reference counting err...2019-07-23T14:20:24ZPeter Kotcauer[v2.6] Xen Security Advisory 58 (CVE-2013-1432) - Page reference counting error due to XSA-45/CVE-2013-1918 fixesreferences:
http://lists.xen.org/archives/html/xen-announce/2013-06/msg00012.html
ISSUE DESCRIPTION
=
The XSA-45/CVE-2013-1918 patch making error handling paths preemptible
broke
page reference counting by not retaining a referen...references:
http://lists.xen.org/archives/html/xen-announce/2013-06/msg00012.html
ISSUE DESCRIPTION
=
The XSA-45/CVE-2013-1918 patch making error handling paths preemptible
broke
page reference counting by not retaining a reference on pages stored
for
deferred cleanup. This would lead to the hypervisor prematurely
attempting to
free the page, generally crashing upon finding the page still in use.
CREDITS
===
Thanks to Andrew Cooper and the Citrix XenServer team for discovering
and reporting this vulnerability, and helping investigate it.
IMPACT
==
Malicious or buggy PV guest kernels can mount a denial of service
attack
affecting the whole system. It can’t be excluded that this could also
be
exploited to mount a privilege escalation attack.
VULNERABLE SYSTEMS
==
All Xen versions having the XSA-45/CVE-2013-1918 fixes applied are
vulnerable.
The vulnerability is only exposed by PV guests.
MITIGATION
==
Running only HVM guests, or PV guests with trusted kernels, will avoid
this
vulnerability.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa58-4.1.patch Xen 4.1.x
xsa58-4.2.patch Xen 4.2.x
xsa58-unstable.patch xen-unstable
$ sha256sum xsa58\*.patch
3623ec87e5a2830f0d41de19a8e448d618954973c3264727a1f3a095f15a8641
xsa58-4.1.patch
194d6610fc38b767d643e5d58a1268f45921fb35e309b47aca6a388b861311c2
xsa58-4.2.patch
2c94b099d7144d03c0f7f44e892a521537fc040d11bc46f84a2438eece46a0f5
xsa58-unstable.patch
*(from redmine: issue id 2124, created on 2013-06-26, closed on 2013-07-02)*
* Relations:
* parent #2123
* Changesets:
* Revision ccdb8c3a1257db6b1ceb3af663b239003a047fd3 by Natanael Copa on 2013-07-01T16:44:49Z:
```
main/xen: fix xsa45 and xsa58 (CVE-2013-1918,CVE-2013-1432)
ref #2123
fixes #2124
(cherry picked from commit 448e4822bbf8a2b4aa8b8f8d8153a2a0b4e0efda)
Conflicts:
main/xen/APKBUILD
```Alpine 2.6.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2125[v2.5] Xen Security Advisory 58 (CVE-2013-1432) - Page reference counting err...2019-07-23T14:20:23ZPeter Kotcauer[v2.5] Xen Security Advisory 58 (CVE-2013-1432) - Page reference counting error due to XSA-45/CVE-2013-1918 fixesreferences:
http://lists.xen.org/archives/html/xen-announce/2013-06/msg00012.html
ISSUE DESCRIPTION
=
The XSA-45/CVE-2013-1918 patch making error handling paths preemptible
broke
page reference counting by not retaining a referen...references:
http://lists.xen.org/archives/html/xen-announce/2013-06/msg00012.html
ISSUE DESCRIPTION
=
The XSA-45/CVE-2013-1918 patch making error handling paths preemptible
broke
page reference counting by not retaining a reference on pages stored
for
deferred cleanup. This would lead to the hypervisor prematurely
attempting to
free the page, generally crashing upon finding the page still in use.
CREDITS
===
Thanks to Andrew Cooper and the Citrix XenServer team for discovering
and reporting this vulnerability, and helping investigate it.
IMPACT
==
Malicious or buggy PV guest kernels can mount a denial of service
attack
affecting the whole system. It can’t be excluded that this could also
be
exploited to mount a privilege escalation attack.
VULNERABLE SYSTEMS
==
All Xen versions having the XSA-45/CVE-2013-1918 fixes applied are
vulnerable.
The vulnerability is only exposed by PV guests.
MITIGATION
==
Running only HVM guests, or PV guests with trusted kernels, will avoid
this
vulnerability.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa58-4.1.patch Xen 4.1.x
xsa58-4.2.patch Xen 4.2.x
xsa58-unstable.patch xen-unstable
$ sha256sum xsa58\*.patch
3623ec87e5a2830f0d41de19a8e448d618954973c3264727a1f3a095f15a8641
xsa58-4.1.patch
194d6610fc38b767d643e5d58a1268f45921fb35e309b47aca6a388b861311c2
xsa58-4.2.patch
2c94b099d7144d03c0f7f44e892a521537fc040d11bc46f84a2438eece46a0f5
xsa58-unstable.patch
*(from redmine: issue id 2125, created on 2013-06-26, closed on 2013-07-03)*
* Relations:
* parent #2123
* Changesets:
* Revision 02b9902f054427e1abb33ff073d866be0c332d70 by Natanael Copa on 2013-07-01T16:49:55Z:
```
main/xen: fix xsa45 and xsa58 (CVE-2013-1918,CVE-2013-1432)
ref #2123
fixes #2125
(cherry picked from commit 448e4822bbf8a2b4aa8b8f8d8153a2a0b4e0efda)
Conflicts:
main/xen/APKBUILD
```Alpine 2.5.5Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2126[v2.4] Xen Security Advisory 58 (CVE-2013-1432) - Page reference counting err...2019-07-23T14:20:22ZPeter Kotcauer[v2.4] Xen Security Advisory 58 (CVE-2013-1432) - Page reference counting error due to XSA-45/CVE-2013-1918 fixesreferences:
http://lists.xen.org/archives/html/xen-announce/2013-06/msg00012.html
ISSUE DESCRIPTION
=
The XSA-45/CVE-2013-1918 patch making error handling paths preemptible
broke
page reference counting by not retaining a referen...references:
http://lists.xen.org/archives/html/xen-announce/2013-06/msg00012.html
ISSUE DESCRIPTION
=
The XSA-45/CVE-2013-1918 patch making error handling paths preemptible
broke
page reference counting by not retaining a reference on pages stored
for
deferred cleanup. This would lead to the hypervisor prematurely
attempting to
free the page, generally crashing upon finding the page still in use.
CREDITS
===
Thanks to Andrew Cooper and the Citrix XenServer team for discovering
and reporting this vulnerability, and helping investigate it.
IMPACT
==
Malicious or buggy PV guest kernels can mount a denial of service
attack
affecting the whole system. It can’t be excluded that this could also
be
exploited to mount a privilege escalation attack.
VULNERABLE SYSTEMS
==
All Xen versions having the XSA-45/CVE-2013-1918 fixes applied are
vulnerable.
The vulnerability is only exposed by PV guests.
MITIGATION
==
Running only HVM guests, or PV guests with trusted kernels, will avoid
this
vulnerability.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa58-4.1.patch Xen 4.1.x
xsa58-4.2.patch Xen 4.2.x
xsa58-unstable.patch xen-unstable
$ sha256sum xsa58\*.patch
3623ec87e5a2830f0d41de19a8e448d618954973c3264727a1f3a095f15a8641
xsa58-4.1.patch
194d6610fc38b767d643e5d58a1268f45921fb35e309b47aca6a388b861311c2
xsa58-4.2.patch
2c94b099d7144d03c0f7f44e892a521537fc040d11bc46f84a2438eece46a0f5
xsa58-unstable.patch
*(from redmine: issue id 2126, created on 2013-06-26, closed on 2013-07-03)*
* Relations:
* parent #2123
* Changesets:
* Revision f87a9718398452ab5e15eccd2eb427d16098c072 by Natanael Copa on 2013-07-01T17:02:29Z:
```
main/xen: main/xen: fix xsa45 and xsa58 (CVE-2013-1918,CVE-2013-1432)
ref #2123
fixes #2126
```Alpine 2.4.12Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2127[v2.3] Xen Security Advisory 58 (CVE-2013-1432) - Page reference counting err...2019-07-23T14:20:21ZPeter Kotcauer[v2.3] Xen Security Advisory 58 (CVE-2013-1432) - Page reference counting error due to XSA-45/CVE-2013-1918 fixesreferences:
http://lists.xen.org/archives/html/xen-announce/2013-06/msg00012.html
ISSUE DESCRIPTION
=
The XSA-45/CVE-2013-1918 patch making error handling paths preemptible
broke
page reference counting by not retaining a referen...references:
http://lists.xen.org/archives/html/xen-announce/2013-06/msg00012.html
ISSUE DESCRIPTION
=
The XSA-45/CVE-2013-1918 patch making error handling paths preemptible
broke
page reference counting by not retaining a reference on pages stored
for
deferred cleanup. This would lead to the hypervisor prematurely
attempting to
free the page, generally crashing upon finding the page still in use.
CREDITS
===
Thanks to Andrew Cooper and the Citrix XenServer team for discovering
and reporting this vulnerability, and helping investigate it.
IMPACT
==
Malicious or buggy PV guest kernels can mount a denial of service
attack
affecting the whole system. It can’t be excluded that this could also
be
exploited to mount a privilege escalation attack.
VULNERABLE SYSTEMS
==
All Xen versions having the XSA-45/CVE-2013-1918 fixes applied are
vulnerable.
The vulnerability is only exposed by PV guests.
MITIGATION
==
Running only HVM guests, or PV guests with trusted kernels, will avoid
this
vulnerability.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa58-4.1.patch Xen 4.1.x
xsa58-4.2.patch Xen 4.2.x
xsa58-unstable.patch xen-unstable
$ sha256sum xsa58\*.patch
3623ec87e5a2830f0d41de19a8e448d618954973c3264727a1f3a095f15a8641
xsa58-4.1.patch
194d6610fc38b767d643e5d58a1268f45921fb35e309b47aca6a388b861311c2
xsa58-4.2.patch
2c94b099d7144d03c0f7f44e892a521537fc040d11bc46f84a2438eece46a0f5
xsa58-unstable.patch
*(from redmine: issue id 2127, created on 2013-06-26, closed on 2013-07-03)*
* Relations:
* parent #2123
* Changesets:
* Revision 14e8058dddb5be40c29deb267ffbc23171991c7a by Natanael Copa on 2013-07-02T11:54:33Z:
```
main/xen: main/xen: fix xsa45 and xsa58 (CVE-2013-1918,CVE-2013-1432)
ref #2123
fixes #2127
```Alpine 2.3.7Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2128openldap fails to start at boot time2019-07-23T14:20:19ZJan-Hendrik Dörneropenldap fails to start at boot timethe directory /var/run/openldap is missing, therefore the slapd does not
start on boot.
Easy-fix:
Adjust the /etc/init.d/slapd file.
sed -i ‘s|depend|if \[ ! -d /var/run/openldap \] then\\n mkdir -p
/var/run/openldap\\n fi\\n&|’ /etc...the directory /var/run/openldap is missing, therefore the slapd does not
start on boot.
Easy-fix:
Adjust the /etc/init.d/slapd file.
sed -i ‘s|depend|if \[ ! -d /var/run/openldap \] then\\n mkdir -p
/var/run/openldap\\n fi\\n&|’ /etc/init.d/slapd
(or something similar)
*(from redmine: issue id 2128, created on 2013-06-27, closed on 2013-07-02)*
* Changesets:
* Revision f10bce070b3bea6cfad50c28c94561df9d7c271a by Natanael Copa on 2013-07-02T11:50:56Z:
```
main/openldap: create pid dir before checking config
ref #2128
```
* Revision 64443cb214d1cb772c75b77d531182db404da27a by Natanael Copa on 2013-07-02T11:51:31Z:
```
main/openldap: create pid dir before checking config
fixes #2128
```Alpine 2.6.2https://gitlab.alpinelinux.org/alpine/aports/-/issues/2129gcc specs files should be installed in gcc dir2019-07-23T14:20:19ZNatanael Copagcc specs files should be installed in gcc dirthe gcc specs files are installed in wrong directory:
dev32-edge:~/test$ export GCC_SPECS="vanilla.specs"
dev32-edge:~/test$ gcc hello.c
gcc: error: vanilla.specs: No such file or directory
To workaround:
dev32-edge:~...the gcc specs files are installed in wrong directory:
dev32-edge:~/test$ export GCC_SPECS="vanilla.specs"
dev32-edge:~/test$ gcc hello.c
gcc: error: vanilla.specs: No such file or directory
To workaround:
dev32-edge:~/test$ sudo cp /usr/share/gcc/* /usr/lib/gcc/i486-alpine-linux-uclibc/4.7.3/
dev32-edge:~/test$ export GCC_SPECS="vanilla.specs"
dev32-edge:~/test$ gcc hello.c
The gcc package should have installed the specs files there.
*(from redmine: issue id 2129, created on 2013-07-02, closed on 2013-07-10)*
* Changesets:
* Revision fd641092f593d069b998a466b54b882d9c8d7910 by Natanael Copa on 2013-07-03T09:30:15Z:
```
main/gcc: install gcc specs in proper location
and unify gcclibdir and gcclibexec variables
the specs fix should make the vanilla.specs work again.
fixes #2129
```Alpine 2.7.0Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2132Request for package: gsm/mobile app2019-07-23T14:20:16ZV KrishnRequest for package: gsm/mobile appHow to send sms easily via alpinelinux?
Found some apps, other than gnokii,
please evaluate to see which alternative would be best for
alpinelinux.
1. ofono.org - seems new/robust
2. gammu - find it simple/easy
3. gsmlib
4. s...How to send sms easily via alpinelinux?
Found some apps, other than gnokii,
please evaluate to see which alternative would be best for
alpinelinux.
1. ofono.org - seems new/robust
2. gammu - find it simple/easy
3. gsmlib
4. smslib
5. kannel
6. smppsim
*(from redmine: issue id 2132, created on 2013-07-15, closed on 2014-10-15)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/2159CVE-2013-4130 spice: unsafe clients ring access abort2019-07-23T14:20:07ZPeter KotcauerCVE-2013-4130 spice: unsafe clients ring access abortreference:
https://bugzilla.redhat.com/show\_bug.cgi?id=984769
*(from redmine: issue id 2159, created on 2013-07-18, closed on 2013-07-23)*
* Relations:
* child #2160
* child #2161
* child #2162
* child #2163
* child #2167...reference:
https://bugzilla.redhat.com/show\_bug.cgi?id=984769
*(from redmine: issue id 2159, created on 2013-07-18, closed on 2013-07-23)*
* Relations:
* child #2160
* child #2161
* child #2162
* child #2163
* child #2167
* Changesets:
* Revision 5b9d90d339f52b93cbfcead950e13453080f954c by Natanael Copa on 2013-07-19T15:00:24Z:
```
main/spice: security upgrade to 0.12.4 (CVE-2013-4130)
ref #2159
fixes #2167
```
* Revision db7164f78513d312fe6acb5c1a76887a54b09f4e by Natanael Copa on 2013-07-19T15:08:23Z:
```
main/spice: security upgrade to 0.12.4 (CVE-2013-4130)
ref #2159
fixes #2160
```
* Revision 0840b37ba1b61fc6068907d72ce76359dface9e4 by Natanael Copa on 2013-07-19T15:26:20Z:
```
main/spice: fix CVE-2013-4130
ref #2159
fixes #2162
```
* Revision 984968f59d6f1c6a919880ce8765c45e94d8a1c4 by Natanael Copa on 2013-07-23T09:38:34Z:
```
main/spice: fix CVE-2013-4130
ref #2159
fixes #2161
```Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2160[v2.6] CVE-2013-4130 spice: unsafe clients ring access abort2019-07-23T14:20:06ZPeter Kotcauer[v2.6] CVE-2013-4130 spice: unsafe clients ring access abortreference:
https://bugzilla.redhat.com/show\_bug.cgi?id=984769
*(from redmine: issue id 2160, created on 2013-07-18, closed on 2013-07-23)*
* Relations:
* parent #2159
* Changesets:
* Revision db7164f78513d312fe6acb5c1a76887a54b...reference:
https://bugzilla.redhat.com/show\_bug.cgi?id=984769
*(from redmine: issue id 2160, created on 2013-07-18, closed on 2013-07-23)*
* Relations:
* parent #2159
* Changesets:
* Revision db7164f78513d312fe6acb5c1a76887a54b09f4e by Natanael Copa on 2013-07-19T15:08:23Z:
```
main/spice: security upgrade to 0.12.4 (CVE-2013-4130)
ref #2159
fixes #2160
```Alpine 2.6.3Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2161[v2.5] CVE-2013-4130 spice: unsafe clients ring access abort2019-07-23T14:20:05ZPeter Kotcauer[v2.5] CVE-2013-4130 spice: unsafe clients ring access abortreference:
https://bugzilla.redhat.com/show\_bug.cgi?id=984769
*(from redmine: issue id 2161, created on 2013-07-18, closed on 2013-07-23)*
* Relations:
* parent #2159
* Changesets:
* Revision 984968f59d6f1c6a919880ce8765c45e94d...reference:
https://bugzilla.redhat.com/show\_bug.cgi?id=984769
*(from redmine: issue id 2161, created on 2013-07-18, closed on 2013-07-23)*
* Relations:
* parent #2159
* Changesets:
* Revision 984968f59d6f1c6a919880ce8765c45e94d8a1c4 by Natanael Copa on 2013-07-23T09:38:34Z:
```
main/spice: fix CVE-2013-4130
ref #2159
fixes #2161
```Alpine 2.5.5Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2162[v2.4] CVE-2013-4130 spice: unsafe clients ring access abort2019-07-23T14:20:03ZPeter Kotcauer[v2.4] CVE-2013-4130 spice: unsafe clients ring access abortreference:
https://bugzilla.redhat.com/show\_bug.cgi?id=984769
*(from redmine: issue id 2162, created on 2013-07-18, closed on 2013-07-23)*
* Relations:
* parent #2159
* Changesets:
* Revision 0840b37ba1b61fc6068907d72ce76359dfa...reference:
https://bugzilla.redhat.com/show\_bug.cgi?id=984769
*(from redmine: issue id 2162, created on 2013-07-18, closed on 2013-07-23)*
* Relations:
* parent #2159
* Changesets:
* Revision 0840b37ba1b61fc6068907d72ce76359dface9e4 by Natanael Copa on 2013-07-19T15:26:20Z:
```
main/spice: fix CVE-2013-4130
ref #2159
fixes #2162
```Alpine 2.4.12Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2163[v2.3] CVE-2013-4130 spice: unsafe clients ring access abort2019-07-12T14:40:30ZPeter Kotcauer[v2.3] CVE-2013-4130 spice: unsafe clients ring access abortreference:
https://bugzilla.redhat.com/show\_bug.cgi?id=984769
*(from redmine: issue id 2163, created on 2013-07-18, closed on 2013-07-19)*
* Relations:
* parent #2159reference:
https://bugzilla.redhat.com/show\_bug.cgi?id=984769
*(from redmine: issue id 2163, created on 2013-07-18, closed on 2013-07-19)*
* Relations:
* parent #2159Alpine 2.3.7Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2164CVE-2013-4073 ruby: hostname check bypassing vulnerability in SSL client2019-07-23T14:15:40ZPeter KotcauerCVE-2013-4073 ruby: hostname check bypassing vulnerability in SSL clientreferences:
http://www.ruby-lang.org/en/news/2013/06/27/hostname-check-bypassing-vulnerability-in-openssl-client-cve-2013-4073/
https://bugzilla.redhat.com/show\_bug.cgi?id=979251
*(from redmine: issue id 2164, created on 2013-07-1...references:
http://www.ruby-lang.org/en/news/2013/06/27/hostname-check-bypassing-vulnerability-in-openssl-client-cve-2013-4073/
https://bugzilla.redhat.com/show\_bug.cgi?id=979251
*(from redmine: issue id 2164, created on 2013-07-18, closed on 2013-07-29)*
* Relations:
* relates #2478
* child #2165
* child #2166
* Changesets:
* Revision bb618853bacfeddcd43b60c6e71571e2d3981e9b by Natanael Copa on 2013-07-24T09:19:14Z:
```
main/ruby: security upgrade to 1.8.7_p374 (CVE-2013-4073)
ref #2164
fixes #2166
```
* Revision c763478c8941f0bbcd4bfc70c3c5a7a2b19e120c by Natanael Copa on 2013-07-24T09:20:04Z:
```
main/ruby: security upgrade to 1.8.7_p374 (CVE-2013-4073)
ref #2164
fixes #2167
```Carlo LandmeterCarlo Landmeterhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2165[v2.3] CVE-2013-4073 ruby: hostname check bypassing vulnerability in SSL client2019-07-23T14:20:02ZPeter Kotcauer[v2.3] CVE-2013-4073 ruby: hostname check bypassing vulnerability in SSL clientreferences:
http://www.ruby-lang.org/en/news/2013/06/27/hostname-check-bypassing-vulnerability-in-openssl-client-cve-2013-4073/
https://bugzilla.redhat.com/show\_bug.cgi?id=979251
*(from redmine: issue id 2165, created on 2013-07-1...references:
http://www.ruby-lang.org/en/news/2013/06/27/hostname-check-bypassing-vulnerability-in-openssl-client-cve-2013-4073/
https://bugzilla.redhat.com/show\_bug.cgi?id=979251
*(from redmine: issue id 2165, created on 2013-07-18, closed on 2013-07-29)*
* Relations:
* parent #2164Alpine 2.3.7Carlo LandmeterCarlo Landmeterhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2166[v2.4] CVE-2013-4073 ruby: hostname check bypassing vulnerability in SSL client2019-07-23T14:20:01ZPeter Kotcauer[v2.4] CVE-2013-4073 ruby: hostname check bypassing vulnerability in SSL clientreferences:
http://www.ruby-lang.org/en/news/2013/06/27/hostname-check-bypassing-vulnerability-in-openssl-client-cve-2013-4073/
https://bugzilla.redhat.com/show\_bug.cgi?id=979251
*(from redmine: issue id 2166, created on 2013-07-1...references:
http://www.ruby-lang.org/en/news/2013/06/27/hostname-check-bypassing-vulnerability-in-openssl-client-cve-2013-4073/
https://bugzilla.redhat.com/show\_bug.cgi?id=979251
*(from redmine: issue id 2166, created on 2013-07-18, closed on 2013-07-29)*
* Relations:
* parent #2164
* Changesets:
* Revision bb618853bacfeddcd43b60c6e71571e2d3981e9b by Natanael Copa on 2013-07-24T09:19:14Z:
```
main/ruby: security upgrade to 1.8.7_p374 (CVE-2013-4073)
ref #2164
fixes #2166
```Alpine 2.4.12Carlo LandmeterCarlo Landmeterhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2167[v2.7] CVE-2013-4130 spice: unsafe clients ring access abort2019-07-23T14:20:00ZNatanael Copa[v2.7] CVE-2013-4130 spice: unsafe clients ring access abortreference:
https://bugzilla.redhat.com/show\_bug.cgi?id=984769
*(from redmine: issue id 2167, created on 2013-07-19, closed on 2013-07-23)*
* Relations:
* parent #2159
* Changesets:
* Revision 5b9d90d339f52b93cbfcead950e13453080...reference:
https://bugzilla.redhat.com/show\_bug.cgi?id=984769
*(from redmine: issue id 2167, created on 2013-07-19, closed on 2013-07-23)*
* Relations:
* parent #2159
* Changesets:
* Revision 5b9d90d339f52b93cbfcead950e13453080f954c by Natanael Copa on 2013-07-19T15:00:24Z:
```
main/spice: security upgrade to 0.12.4 (CVE-2013-4130)
ref #2159
fixes #2167
```
* Revision c763478c8941f0bbcd4bfc70c3c5a7a2b19e120c by Natanael Copa on 2013-07-24T09:20:04Z:
```
main/ruby: security upgrade to 1.8.7_p374 (CVE-2013-4073)
ref #2164
fixes #2167
```Alpine 2.7.0Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/2168alpine-mirrors2019-07-23T14:19:59ZNatanael Copaalpine-mirrorsshould collect the mirrors in a yaml file with contact info and geo
location or similar. then we can distribute a .json file.
*(from redmine: issue id 2168, created on 2013-07-19, closed on 2013-12-09)*
* Changesets:
* Revision f35a...should collect the mirrors in a yaml file with contact info and geo
location or similar. then we can distribute a .json file.
*(from redmine: issue id 2168, created on 2013-07-19, closed on 2013-12-09)*
* Changesets:
* Revision f35a00c1f707409f5f2509a679bb05ec92988b7f by Natanael Copa on 2013-11-29T16:34:14Z:
```
main/alpine-mirrors: switch to yaml format
fixes #2168
```
* Revision 319a41d726099d23bd3af45b8ea08b10eba79f45 by Natanael Copa on 2014-03-06T13:39:25Z:
```
main/alpine-mirrors: switch to yaml format
fixes #2168
```3.0.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/2169gcc won't compile, looking for crt1.02019-07-23T14:19:58Zshaari saribangcc won't compile, looking for crt1.0when compiling source on alpine linux, it complaint configure: error: C
compiler cannot create executables.
Trying to compile the main.c, I got the following errors.
$ cat main.c
int main()
{
return 0;
}
$ gcc main.c
/usr/li...when compiling source on alpine linux, it complaint configure: error: C
compiler cannot create executables.
Trying to compile the main.c, I got the following errors.
$ cat main.c
int main()
{
return 0;
}
$ gcc main.c
/usr/lib/gcc/x86\_64-alpine-linux-uclibc/4.7.3/../../../../x86\_64-alpine-linux-uclibc/bin/ld:
cannot find crt1.o: No such file or directory
/usr/lib/gcc/x86\_64-alpine-linux-uclibc/4.7.3/../../../../x86\_64-alpine-linux-uclibc/bin/ld:
cannot find crti.o: No such file or directory
/usr/lib/gcc/x86\_64-alpine-linux-uclibc/4.7.3/../../../../x86\_64-alpine-linux-uclibc/bin/ld:
cannot find -lc
/usr/lib/gcc/x86\_64-alpine-linux-uclibc/4.7.3/../../../../x86\_64-alpine-linux-uclibc/bin/ld:
cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status
$ clang main.c
/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
/usr/bin/ld: cannot find -lc
/usr/bin/ld: cannot find crtn.o: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
*(from redmine: issue id 2169, created on 2013-07-21, closed on 2013-08-01)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/2170New Package Request - SquidAnalyzer (squidanalyzer.darold.net/)2019-07-23T14:19:57ZRay PatingNew Package Request - SquidAnalyzer (squidanalyzer.darold.net/)Project page: squidanalyzer.darold.net
Requesting this package for Alpine configurations where squid is
installed as either a web proxy, content filter or content cache, for
metrics and measurement.
*(from redmine: issue id 2170, crea...Project page: squidanalyzer.darold.net
Requesting this package for Alpine configurations where squid is
installed as either a web proxy, content filter or content cache, for
metrics and measurement.
*(from redmine: issue id 2170, created on 2013-07-26, closed on 2014-10-15)*
* Changesets:
* Revision 244667c408c035ba504efcedc10ffac325d673d4 by Natanael Copa on 2013-10-23T09:42:31Z:
```
testing/squidanalyzer: new aport
Squid proxy log analyzer and report generator
http://squidanalyzer.darold.net/
ref #2170
```3.1.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/2171/var/run/apache2 deleted each reboot, apache2 failed to start2019-07-23T14:19:56Zshaari sariban/var/run/apache2 deleted each reboot, apache2 failed to startfolder /var/run/apache2 deleted at reboot. This cause the following
error and apache failed to start.
\[Sat Jul 27 14:36:09.503626 2013\] \[suexec:notice\] \[pid 1733\]
AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
\[S...folder /var/run/apache2 deleted at reboot. This cause the following
error and apache failed to start.
\[Sat Jul 27 14:36:09.503626 2013\] \[suexec:notice\] \[pid 1733\]
AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
\[Sat Jul 27 14:36:09.551444 2013\] \[auth\_digest:notice\] \[pid 1734\]
AH01757: generating secret for digest authentication …
\[Sat Jul 27 14:36:09.551486 2013\] \[auth\_digest:error\] \[pid 1734\]
(2)No such file or directory: AH01762: Failed to create shared memory
segment on file /var/run/apache2/authdigest\_shm.1734
\[Sat Jul 27 14:36:09.551495 2013\] \[auth\_digest:error\] \[pid 1734\]
(2)No such file or directory: AH01760: failed to initialize shm - all
nonce-count checking, one-time nonces, and MD5-sess algorithm disabled
\[Sat Jul 27 14:36:09.551501 2013\] \[:emerg\] \[pid 1734\] AH00020:
Configuration Failed, exiting
zen86:~\# httpd -v
Server version: Apache/2.4.4 (Unix)
Server built: Jun 24 2013 07:50:35
The workaround for this to add mkdir /var/run/apache2 in the init file
*(from redmine: issue id 2171, created on 2013-07-27, closed on 2013-08-06)*
* Changesets:
* Revision fdf39794195592b4da31471a1485250fc132f143 by Natanael Copa on 2013-08-06T08:21:05Z:
```
main/apache2: create pid dir at startup. ignore missing conf.d/*.conf
ref #2171
```
* Revision de3901a821e4e6567c13cb005a2ed74b1b34bde1 by Natanael Copa on 2013-08-06T08:25:03Z:
```
main/apache2: create pid dir at startup. ignore missing conf.d/*.conf
fixes #2171
```Alpine 2.6.3https://gitlab.alpinelinux.org/alpine/aports/-/issues/2172ttyUSB0 not assigned to group dialout when attached2019-07-23T14:19:55Zshaari saribanttyUSB0 not assigned to group dialout when attachedpl2030 device when connected to the box does not assigned to group
dialout. I’ve added pl2030 in the /etc/modules and the gsm modem loaded
as ttyUSB0. However, the group for the device is root instead of
dialout.
zen86:~\# ll /dev/ttyUS...pl2030 device when connected to the box does not assigned to group
dialout. I’ve added pl2030 in the /etc/modules and the gsm modem loaded
as ttyUSB0. However, the group for the device is root instead of
dialout.
zen86:~\# ll /dev/ttyUSB0
crw-rw—— 1 root root 188, 0 Jul 27 12:34 /dev/ttyUSB0
I tried to resolve this issue with udev, but I got the following bug
message:
BUG: soft lockup CPU\#0 stuck for 21s! \[udevadm:1659\]
Process udevadm…
any help appreciated.
*(from redmine: issue id 2172, created on 2013-07-27, closed on 2013-08-06)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/2173bind: CVE-2013-4854: A specially crafted query can cause BIND to terminate ab...2019-07-23T14:19:54ZNatanael Copabind: CVE-2013-4854: A specially crafted query can cause BIND to terminate abnormallyCVE: CVE-2013-4854
Document Version: 2.0
Posting date: 26 July 2013
Program Impacted: BIND
Versions affected: 9.7.0<s><span style="text-align:right;">9.7.7,
9.8.0</span></s>&gt;9.8.5-P1, 9.9.0-&gt;9.9.3-P1, 9.8.6b1 and 9.9.4b1;
S...CVE: CVE-2013-4854
Document Version: 2.0
Posting date: 26 July 2013
Program Impacted: BIND
Versions affected: 9.7.0<s><span style="text-align:right;">9.7.7,
9.8.0</span></s>>9.8.5-P1, 9.9.0->9.9.3-P1, 9.8.6b1 and 9.9.4b1;
Subscription: 9.9.3-S1 and 9.9.4-S1b1
Severity: Critical
Exploitable: Remotely
### Description
A specially crafted query that includes malformed rdata can cause named
to terminate with an assertion failure while rejecting the malformed
query.
BIND 9.6 and BIND 9.6-ESV are unaffected by this problem. Earlier
branches of BIND 9 are believed to be unaffected but have not been
tested. BIND 10 is also unaffected by this issue.
Please Note: All versions of BIND 9.7 are known to be affected, but
these branches are beyond their “end of life” (EOL) and no longer
receive testing or security fixes from ISC. For current information on
which versions are actively supported, please see
http://www.isc.org/downloads/software-support-policy/bind-software-status/.
### Impact
Authoritative and recursive servers are equally vulnerable. Intentional
exploitation of this condition can cause a denial of service in all
nameservers running affected versions of BIND 9. Access Control Lists do
not provide any protection from malicious clients.
In addition to the named server, applications built using libraries from
the affected source distributions may crash with assertion failures
triggered in the same fashion.
CVSS Score: 7.8
CVSS Equation: (AV:N/AC:L/Au:N/C:N/I:N/A:C)
For more information on the Common Vulnerability Scoring System and to
obtain your specific environmental score please visit:
http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2&vector=(AV:N/AC:L/Au:N/C:N/I:N/A:C)
### Workarounds
No known workarounds at this time.
### Active exploits
Crashes have been reported by multiple ISC customers. First observed in
the wild on 26 July 2013.
*(from redmine: issue id 2173, created on 2013-07-29, closed on 2013-07-30)*
* Relations:
* child #2174
* child #2175
* child #2176
* child #2177
* child #2178https://gitlab.alpinelinux.org/alpine/aports/-/issues/2174[v2.7] bind: CVE-2013-4854: A specially crafted query can cause BIND to termi...2019-07-23T14:19:53ZNatanael Copa[v2.7] bind: CVE-2013-4854: A specially crafted query can cause BIND to terminate abnormallyCVE: CVE-2013-4854
Document Version: 2.0
Posting date: 26 July 2013
Program Impacted: BIND
Versions affected: 9.7.0<s><span style="text-align:right;">9.7.7,
9.8.0</span></s>&gt;9.8.5-P1, 9.9.0-&gt;9.9.3-P1, 9.8.6b1 and 9.9.4b1;
S...CVE: CVE-2013-4854
Document Version: 2.0
Posting date: 26 July 2013
Program Impacted: BIND
Versions affected: 9.7.0<s><span style="text-align:right;">9.7.7,
9.8.0</span></s>>9.8.5-P1, 9.9.0->9.9.3-P1, 9.8.6b1 and 9.9.4b1;
Subscription: 9.9.3-S1 and 9.9.4-S1b1
Severity: Critical
Exploitable: Remotely
### Description
A specially crafted query that includes malformed rdata can cause named
to terminate with an assertion failure while rejecting the malformed
query.
BIND 9.6 and BIND 9.6-ESV are unaffected by this problem. Earlier
branches of BIND 9 are believed to be unaffected but have not been
tested. BIND 10 is also unaffected by this issue.
Please Note: All versions of BIND 9.7 are known to be affected, but
these branches are beyond their “end of life” (EOL) and no longer
receive testing or security fixes from ISC. For current information on
which versions are actively supported, please see
http://www.isc.org/downloads/software-support-policy/bind-software-status/.
### Impact
Authoritative and recursive servers are equally vulnerable. Intentional
exploitation of this condition can cause a denial of service in all
nameservers running affected versions of BIND 9. Access Control Lists do
not provide any protection from malicious clients.
In addition to the named server, applications built using libraries from
the affected source distributions may crash with assertion failures
triggered in the same fashion.
CVSS Score: 7.8
CVSS Equation: (AV:N/AC:L/Au:N/C:N/I:N/A:C)
For more information on the Common Vulnerability Scoring System and to
obtain your specific environmental score please visit:
http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2&vector=(AV:N/AC:L/Au:N/C:N/I:N/A:C)
### Workarounds
No known workarounds at this time.
### Active exploits
Crashes have been reported by multiple ISC customers. First observed in
the wild on 26 July 2013.
*(from redmine: issue id 2174, created on 2013-07-29, closed on 2013-07-30)*
* Relations:
* parent #2173
* Changesets:
* Revision 6f4a5f3bb411ea0521660bd0352684ec216fa575 by Natanael Copa on 2013-07-29T08:20:58Z:
```
main/bind: security upgrade to 9.9.3_p2 (CVE-2013-4854)
fixes #2174
```Alpine 2.7.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/2175[v2.6] bind: CVE-2013-4854: A specially crafted query can cause BIND to termi...2019-07-23T14:19:52ZNatanael Copa[v2.6] bind: CVE-2013-4854: A specially crafted query can cause BIND to terminate abnormallyCVE: CVE-2013-4854
Document Version: 2.0
Posting date: 26 July 2013
Program Impacted: BIND
Versions affected: 9.7.0<s><span style="text-align:right;">9.7.7,
9.8.0</span></s>&gt;9.8.5-P1, 9.9.0-&gt;9.9.3-P1, 9.8.6b1 and 9.9.4b1;
S...CVE: CVE-2013-4854
Document Version: 2.0
Posting date: 26 July 2013
Program Impacted: BIND
Versions affected: 9.7.0<s><span style="text-align:right;">9.7.7,
9.8.0</span></s>>9.8.5-P1, 9.9.0->9.9.3-P1, 9.8.6b1 and 9.9.4b1;
Subscription: 9.9.3-S1 and 9.9.4-S1b1
Severity: Critical
Exploitable: Remotely
### Description
A specially crafted query that includes malformed rdata can cause named
to terminate with an assertion failure while rejecting the malformed
query.
BIND 9.6 and BIND 9.6-ESV are unaffected by this problem. Earlier
branches of BIND 9 are believed to be unaffected but have not been
tested. BIND 10 is also unaffected by this issue.
Please Note: All versions of BIND 9.7 are known to be affected, but
these branches are beyond their “end of life” (EOL) and no longer
receive testing or security fixes from ISC. For current information on
which versions are actively supported, please see
http://www.isc.org/downloads/software-support-policy/bind-software-status/.
### Impact
Authoritative and recursive servers are equally vulnerable. Intentional
exploitation of this condition can cause a denial of service in all
nameservers running affected versions of BIND 9. Access Control Lists do
not provide any protection from malicious clients.
In addition to the named server, applications built using libraries from
the affected source distributions may crash with assertion failures
triggered in the same fashion.
CVSS Score: 7.8
CVSS Equation: (AV:N/AC:L/Au:N/C:N/I:N/A:C)
For more information on the Common Vulnerability Scoring System and to
obtain your specific environmental score please visit:
http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2&vector=(AV:N/AC:L/Au:N/C:N/I:N/A:C)
### Workarounds
No known workarounds at this time.
### Active exploits
Crashes have been reported by multiple ISC customers. First observed in
the wild on 26 July 2013.
*(from redmine: issue id 2175, created on 2013-07-29, closed on 2013-07-30)*
* Relations:
* parent #2173
* Changesets:
* Revision 4dbda03593fc0526f059db6d8397cf323105436f by Natanael Copa on 2013-07-29T08:23:18Z:
```
main/bind: security upgrade to 9.9.3_p2 (CVE-2013-4854)
fixes #2175
```Alpine 2.6.3