Re: Golang packages
Ola Lundqvist writes: > In this case I think we should issue one DLA and tell all the packages that > have been updated at the same time. This require some rephrasing compared > to a standard DLA but I do not think we should have a lot of them. > > This considering that we have fixed all the packages that require re-build. > > I think it will be difficult to syncronize the fix of several > vulnerabilities. This could be done in some specific cases, but generally I > think we should accept that we have multiple uploads. I think the problem here, like you say, generally the fix to the library needs to be done first and uploaded first, before the dependency packages. During which time, people might complain that there was a package uploaded without a DLA. Which is fair enough. The big problem with trying to upload multiple packages at the same time is that the autobuilders could pick up the old library on some architectures (i.e. the library hasn't been built on that platform yet). Really need to make sure that the library has been uploaded and built on all platforms before you upload the dependencies. -- Brian May
Re: Golang packages
Ola Lundqvist writes: > I can also see a note in dla-needed for Thorsten working on automating go > updates. I did a bit of work trying to automate go updates on my system: * Identifying what packages need to be updated. * Downloading said packages. * Rebuilding. * Uploading. But there is still a lot of manual steps: * Confirm that it is OK at add dependencies to dla-needed.txt * Adding list of dependencies to dla-needed.txt, ensuring no conflicts. * Reserve DLA for each package uploaded. * Create DLA email for each package uploaded. * Add DLA to website. * Ping ftp-master when the upload fails. * etc And then what could happen (at least in theory) is that now I have resolved this vulnerability, I start investigating another security vulnerability that has a similar set of dependencies that require rebuilding. Uploading these again is not a good outcome. It would be better to fix all the root packages at once, and then upload the all the dependencies. Maybe we need a way of identifying all the dependencies at triage time, and somehow(?) manage them better at triage time. Although my gut feeling is we might be coming to the limits of what we can manage with a simple text based dla-needed.txt file. I am also a bit uneasy with the requirement for a separate DLA for each and every package that needs to be uploaded. Could create a lot of noise. Not sure I see any solutions though. I think in the future (if we are not already there) we could easily have a similar situation with rust - which I also believe likes to embed code also. -- Brian May
Support for insecure applications
Hello, I notice that the quality of our packages can vary significantly. Some get frequent security updates, while with others the author appears to be confused just what an SQL injection attack is and how to prevent it. Not going to name names here, because they have done a wonderful job in developing the software, publishing it as open source, and getting it into Debian. And they most likely are not-paid and doing this on their own time. I think that possibly there are a number of packages and different (possibly seriously time constrained) authors here. Plus Debian doesn't seem to have any requirement that packages should be vaguely secure before a new package in accepted (maybe this needs to change?). However, I was wondering if we should even try to support such software that obviously has not been written to have any level of security? As even if we patch one CVE - chances are there are many more security waiting to be found. We are providing a disservice to our users by pretending that all software is secure, when obviously it is not. Yes, this could also result in a flame war with the author too. Which I would rather avoid. Maybe though people who are keen enough, and have time, to enter a flame war, are also keep enough to help fix the problems. But I am not sure that treating all software as equal, when it obviously isn't, is a good thing for our users. Yes, users can look up our security trackers, not sure how much this helps though. A lot of these open security issues aren't necessarily serious issues that warrant concern. Any ideas, comments? Regards -- Brian May https://linuxpenguins.xyz/brian/
[SECURITY] [DLA 2550-1] openjpeg2 security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - - Debian LTS Advisory DLA-2550-1debian-...@lists.debian.org https://www.debian.org/lts/security/Brian May February 09, 2021 https://wiki.debian.org/LTS - - Package: openjpeg2 Version: 2.1.2-1.1+deb9u6 CVE ID : CVE-2020-27814 CVE-2020-27823 CVE-2020-27824 CVE-2020-27841 CVE-2020-27844 CVE-2020-27845 Various overflow errors were identified and fixed. CVE-2020-27814 A heap-buffer overflow was found in the way openjpeg2 handled certain PNG format files. CVE-2020-27823 Wrong computation of x1,y1 if -d option is used, resulting in heap buffer overflow. CVE-2020-27824 Global buffer overflow on irreversible conversion when too many decomposition levels are specified. CVE-2020-27841 Crafted input to be processed by the openjpeg encoder could cause an out-of-bounds read. CVE-2020-27844 Crafted input to be processed by the openjpeg encoder could cause an out-of-bounds write. CVE-2020-27845 Crafted input can cause out-of-bounds-read. For Debian 9 stretch, these problems have been fixed in version 2.1.2-1.1+deb9u6. We recommend that you upgrade your openjpeg2 packages. For the detailed security status of openjpeg2 please refer to its security tracker page at: https://security-tracker.debian.org/tracker/openjpeg2 Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKpwfR8DOwu5vyB4TKpJZkldkSvoFAmAhtQcACgkQKpJZkldk SvrZcw/8DbSP6wWmlild41IgRroquPaY0DAorg59xGhZZLWJ19HYEJ0O1XNc8edV rgolb9B8o96//kzzUJ/UABEOPNVTbacfDnUDNiAtry/4fPjmfa9Qg4iaarLFNFpb QfMnDFTFPYP1HToIAWVkJT6S4U5A2V35Mhqo2GrHz3cwoz2uLYrZx14iLuZWFO3h OpNJmAv3IyH3qOUTccgaUiWfFkDZOA2wI+BgvI7nDmLeuqfCFdJ9XMBGEz3FRMH9 uOJRGbIXrY7yyDNLwG+qYsa6btaxDwfPyXZHYiC73N2T24yaboDFQt3l0mzKNheu gUi1X6K7ICjKp4/8+o0XsM1VVQsiyg9KckxM5thhLtgmTdJ+wc/NFRy3JOtj8r04 VUoQDi3rs5NOW9MV6YswD3DeRd8EkYay5sJ6r13TGAViNDZPtj1EJt7bfnRwcD1G 5N756jZWjHcc0k/u/egeG/1u9S0uXTr+Dhy+vFR/8gojb/a5vtI/iMWLccRlB0Qc UNl/Xtcwy283trleBfUpIcnc3g4kjLnWtHjEOX+G1o986/bL6DVO32fQou/hi/Nn w6hIH9wr1aSFbyb4NznpKLW8PZEPsseli9eD4/zL4LCRLdGCBnRNq1+xj+RS5NCz c50ROdoWPW3nz5Y+NhAspQjzH24Jg5cvrX0pX7G3a2g8WYP/Ei8= =LFai -END PGP SIGNATURE-
openjpeg2
Attached is security patches for openjpeg2 from stretch. In particular:
CVE-2019-6988 - skipped, no upstream fix.
CVE-2020-27814 - applied, both patches. 2nd patch applied by hand.
CVE-2020-27823 - applied, by hand.
CVE-2020-27824 - applied, by hand. Patch applies cleanly, but nop
without patching the opj_dwt_getnorm_real also (existing function does
the same thing), which I did.
CVE-2020-27841 - applied, by hand. As far as I can tell most of the
upstream patch is simply passing around the manager object, which is
required for better error messages. I only applied the bits that look
like they have a security impact, without the error messages.
CVE-2020-27842 - skipped, no upstream fix.
CVE-2020-27843 - skipped, no upstream fix.
CVE-2020-27844 - skipped. Upstream patch replaces assert with if. Not
sure how this helps. Unless maybe assert is a nop. In any case, can't
find the code. Suspect we are not vulnerable.
CVE-2020-27845 - applied, by hand, error messages removed.
I note that this package doesn't seem to run tests on build. Which makes
me a bit nervous. It does come with tests, but so far my attempts to run
these tests have not been successful.
--
Brian May
diff -Nru openjpeg2-2.1.2/debian/changelog openjpeg2-2.1.2/debian/changelog
--- openjpeg2-2.1.2/debian/changelog 2020-07-11 01:34:00.0 +1000
+++ openjpeg2-2.1.2/debian/changelog 2021-02-04 08:18:38.0 +1100
@@ -1,3 +1,18 @@
+openjpeg2 (2.1.2-1.1+deb9u6) stretch-security; urgency=medium
+
+ * Non-maintainer upload by the LTS Security Team.
+ * Fix CVE-2020-27814: A heap-buffer overflow in the way openjpeg2
+handled certain PNG format files.
+ * Fix CVE-2020-27823: Wrong computation of x1,y1 if -d option is used,
+resulting in heap buffer overflow.
+ * Fix CVE-2020-27824: avoid global buffer overflow on irreversible conversion when
+too many decomposition levels are specified.
+ * Fix CVE-2020-27841: crafted input to be processed by the openjpeg encoder
+could cause an out-of-bounds read.
+ * Fix CVE-2020-27845: crafted input can cause out-of-bounds-read.
+
+ -- Brian May Thu, 04 Feb 2021 08:18:38 +1100
+
openjpeg2 (2.1.2-1.1+deb9u5) stretch-security; urgency=high
* Non-maintainer upload by the LTS team.
diff -Nru openjpeg2-2.1.2/debian/patches/CVE-2020-27814.patch openjpeg2-2.1.2/debian/patches/CVE-2020-27814.patch
--- openjpeg2-2.1.2/debian/patches/CVE-2020-27814.patch 1970-01-01 10:00:00.0 +1000
+++ openjpeg2-2.1.2/debian/patches/CVE-2020-27814.patch 2021-02-04 08:18:20.0 +1100
@@ -0,0 +1,28 @@
+From 15cf3d95814dc931ca0ecb132f81cb152e051bae Mon Sep 17 00:00:00 2001
+From: Even Rouault
+Date: Mon, 23 Nov 2020 18:14:02 +0100
+Subject: [PATCH] Encoder: grow again buffer size in
+ opj_tcd_code_block_enc_allocate_data() (fixes #1283)
+
+---
+ src/lib/openjp2/tcd.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+Index: openjpeg2-2.1.2/src/lib/openjp2/tcd.c
+===
+--- openjpeg2-2.1.2.orig/src/lib/openjp2/tcd.c
openjpeg2-2.1.2/src/lib/openjp2/tcd.c
+@@ -1107,9 +1107,12 @@ static OPJ_BOOL opj_tcd_code_block_enc_a
+
+ /* +1 is needed for https://github.com/uclouvain/openjpeg/issues/835 */
+ /* and actually +2 required for https://github.com/uclouvain/openjpeg/issues/982 */
++/* and +7 for https://github.com/uclouvain/openjpeg/issues/1283 (-M 3) */
++/* and +26 for https://github.com/uclouvain/openjpeg/issues/1283 (-M 7) */
++/* and +28 for https://github.com/uclouvain/openjpeg/issues/1283 (-M 44) */
+ /* TODO: is there a theoretical upper-bound for the compressed code */
+ /* block size ? */
+-l_data_size = 2 + (OPJ_UINT32)((p_code_block->x1 - p_code_block->x0) *
++l_data_size = 28 + (OPJ_UINT32)((p_code_block->x1 - p_code_block->x0) *
+(p_code_block->y1 - p_code_block->y0) * (OPJ_INT32)sizeof(OPJ_UINT32));
+
+ if (l_data_size > p_code_block->data_size) {
diff -Nru openjpeg2-2.1.2/debian/patches/CVE-2020-27823.patch openjpeg2-2.1.2/debian/patches/CVE-2020-27823.patch
--- openjpeg2-2.1.2/debian/patches/CVE-2020-27823.patch 1970-01-01 10:00:00.0 +1000
+++ openjpeg2-2.1.2/debian/patches/CVE-2020-27823.patch 2021-02-04 08:18:38.0 +1100
@@ -0,0 +1,25 @@
+From b2072402b7e14d22bba6fb8cde2a1e9996e9a919 Mon Sep 17 00:00:00 2001
+From: Even Rouault
+Date: Mon, 30 Nov 2020 22:31:51 +0100
+Subject: [PATCH] pngtoimage(): fix wrong computation of x1,y1 if -d option is
+ used, that would result in a heap buffer overflow (fixes #1284)
+
+---
+ src/bin/jp2/convertpng.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+Index: openjpeg2-2.1.2/src/bin/jp2/convertpng.c
+===
+--- openjpeg2-2.1.2.orig/src/bin/jp2/convertpng.c
openjpeg2-2.1.2/src/bin/jp2/convertpng.c
+@@ -216,8 +216,8 @@ opj_image_t *pngtoimage(const char *read
+ if
[SECURITY] [DLA 2527-1] snapd security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - - Debian LTS Advisory DLA-2527-1debian-...@lists.debian.org https://www.debian.org/lts/security/Brian May January 18, 2021 https://wiki.debian.org/LTS - - Package: snapd Version: 2.21-2+deb9u1 CVE ID : CVE-2019-11840 golang-go.crypto was recently updated with a fix for CVE-2019-11840. This in turn requires all packages that use the affected code to be recompiled in order to pick up the security fix. CVE-2019-11840 An issue was discovered in supplementary Go cryptography libraries, aka golang-googlecode-go-crypto. If more than 256 GiB of keystream is generated, or if the counter otherwise grows greater than 32 bits, the amd64 implementation will first generate incorrect output, and then cycle back to previously generated keystream. Repeated keystream bytes can lead to loss of confidentiality in encryption applications, or to predictability in CSPRNG applications. For Debian 9 stretch, this problem has been fixed in version 2.21-2+deb9u1. We recommend that you upgrade your snapd packages. For the detailed security status of snapd please refer to its security tracker page at: https://security-tracker.debian.org/tracker/snapd Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKpwfR8DOwu5vyB4TKpJZkldkSvoFAmAEqecACgkQKpJZkldk SvoQLg//c/lgWl8t2By4anfuAS3NbIO0pHvEpvZ9bw1CuffMFUG+DAIdjUYR9LHT T/dfrZccoJh+CKo7dU/vCKJDZaBdIdDzX420oQQQ+4MxUEpkq1iFlyy3UblV4mL6 79wpQY6QCEr/ytycl82NJSXUNo38EBH97lf3W9XeBm4cPscYbBBjbIpXD6748jNo e80KHNrVhQEbEUjEWbekgEgwSWGBnjIoImBQaZWvT3xiR6HkuTAnoF7FS6LbGUqe /IQa4FlyLzXU6JSWDkKgzgXVTdfrlVwH3cdElqIK2Rv/IA0Lm9gokzFQ+AZ4j7VH TDX2Sn+q6ls8MTohDDxi+byTVwBP0P9SnKyRKxSkcf9n5SzUyt16AtJdGcwn+bj4 0l+2nRZOjqMzXPCPQTFSfrdRONXyACeDftnScv+a1eFknQKvurskkLfeoqFG8mvN pgDQ00RQrT9YzD0L00OKMpL7c02f/cAH+3kiIlhXqpGk8m9xusZeFE/et7zihOCp aO7sS+hrl6Sve9JVVLWwjlttNTFgyK3S7w7yf+AJ7lhAzRYKTsNyDojYk3Oafuve 2YM8+6PxFN7QUQh6nDTe5Yc59bjifPXOJs0X8xEyPIDJs6i7KtvnsH+et82vHP1e Bvg/7eEKavqLKjp7UxSKTW2Kl7EqnpYma4bmLu9fe4g8ZQoY3Rs= =Dw9o -END PGP SIGNATURE-
ruby-actionpack-page-caching / CVE-2020-8159
After reading the notes for this project:
ruby-actionpack-page-caching (Brian May)
NOTE: 20200819: Upstream's patch on does not apply due to subsequent
NOTE: 20200819: refactoring. However, a quick look at the private
NOTE: 20200819: page_cache_file method suggests that the issue exists, as it
NOTE: 20200819: uses the path without normalising any "../" etc., simply
NOTE: 20200819: URI.parser.unescap-ing it. Requires more investigation.
(lamby)
It seems like the best thing is to run the test case first.
But had lots of problems getting "get" to call the custom URL that is
defined in the test.
The code in stretch uses:
with_routing do |set|
But apparently this is not sufficient for the "get" function to work.
https://stackoverflow.com/questions/27068995/with-routing-test-helper-doesnt-work-for-integration-tests
So I ended up copying the test file from the sid/bullseye file and using
it. And ignoring the other tests failing (I imagine these might be easy
to fix). For the test in question, I still ended up with the get command
unable to find the route.
In desperation, I changed the line:
get :ok, params: { id: "#{get_to_root}../pwnd" }
To:
get :ok, id: "#{get_to_root}../pwnd"
Now I get the test failure:
5) Failure:
PageCachingTest#test_cache_does_not_escape
[/tmp/brian/tmpzof0zyk7/build/amd64/source/test/caching_test.rb:198]:
Expected ["/tmp/brian/tmpzof0zyk7/build/amd64/source/test/pwnd.html",
"/tmp/brian/tmpzof0zyk7/build/amd64/source/test/pwnd.html.gz"] to be
empty?.
Which seems to indicate that the code is vulnerable, and that my id
passing is working correctly.
I added also added the following line, just before the assert that fails:
Find.find(File.join(project_root, "test")) { |e| puts e }
Which lists the files as:
/tmp/brian/tmpx4w5mn7g/build/amd64/source/test
/tmp/brian/tmpx4w5mn7g/build/amd64/source/test/abstract_unit.rb
/tmp/brian/tmpx4w5mn7g/build/amd64/source/test/caching_test.rb
/tmp/brian/tmpx4w5mn7g/build/amd64/source/test/log_subscriber_test.rb
/tmp/brian/tmpx4w5mn7g/build/amd64/source/test/pwnd.html
/tmp/brian/tmpx4w5mn7g/build/amd64/source/test/pwnd.html.gz
/tmp/brian/tmpx4w5mn7g/build/amd64/source/test/tmp
/tmp/brian/tmpx4w5mn7g/build/amd64/source/test/tmp/test_cache
/tmp/brian/tmpx4w5mn7g/build/amd64/source/test/tmp/test_cache/page_caching_test
/tmp/brian/tmpx4w5mn7g/build/amd64/source/test/tmp/test_cache/page_caching_test/ok
Which I think is a definite fail.
But sometimes the test passes and these files don't exist. So I can't
help but wonder if there is some weird race condition here. For example
on one test run I got these files instead:
/tmp/brian/tmptvp61kg5/build/amd64/source/test
/tmp/brian/tmptvp61kg5/build/amd64/source/test/abstract_unit.rb
/tmp/brian/tmptvp61kg5/build/amd64/source/test/caching_test.rb
/tmp/brian/tmptvp61kg5/build/amd64/source/test/log_subscriber_test.rb
/tmp/brian/tmptvp61kg5/build/amd64/source/test/tmp
/tmp/brian/tmptvp61kg5/build/amd64/source/test/tmp/test_cache
Which is fine. Will continue investigating at a later date when I am
more awake.
--
Brian May
[SECURITY] [DLA 2520-1] golang-websocket security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - - Debian LTS Advisory DLA-2520-1debian-...@lists.debian.org https://www.debian.org/lts/security/Brian May January 07, 2021 https://wiki.debian.org/LTS - - Package: golang-websocket Version: 1.1.0-1+deb9u1 CVE ID : CVE-2020-27813 There was an integer overflow vulnerability concerning the length of websocket frames received via a websocket connection. An attacker could use this flaw to cause a denial of service attack on an HTTP Server allowing websocket connections. For Debian 9 stretch, this problem has been fixed in version 1.1.0-1+deb9u1. We recommend that you upgrade your golang-websocket packages. For the detailed security status of golang-websocket please refer to its security tracker page at: https://security-tracker.debian.org/tracker/golang-websocket Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKpwfR8DOwu5vyB4TKpJZkldkSvoFAl/2QmAACgkQKpJZkldk Svplpw//aYeDtBjMPN0MMgGH5SFoa192kt3wzphSJ5gmwwAbyPI8KZ0BGnJKF9z0 rvafFP52chK0BHWKKp+qHyxzBeaPjPoOG0vqlLAu1mOWtSd0jMF1vlvxFJaOJuZC sCXbZnZ0NmzOtJ4Oi+BXJkPACSXlY8Af9LIR0GnbpSyNeG9S/5Kic7rhrjSLpng+ jH9y+KRlyL06gMdUDQ89tUMPqODSpGf5WOtULGh6EJQr7eMZMiyXKQ0NxNGXSsmI Htf3bm5wyK8ImnjY4xMIPXJek+UGBRE1CAR1MSp9YXbxiojh/UPW8w/JNb+uTeXN YUBrPcoIZaCoC0h27VfOmQyLNy/pIDe5wFZCBFe03dD6Fe99gZZOoKduRqWMLiU9 ZobVbp00EEnsAIJkpkcxZ5Hlyh/oQ3GSAf1fvdH5siow9aht+aTlZJKTbZJ0xphW f7zcg+6Fr3U935g4TMJOIyhTImfV7OMGLpkywPYybStvMjAV6dKjIDkmLCpxdD2X 12ha3I+aDuJZXg3HBpLiIvEr96qwlHRtNJ+RU1IyJ4E81AZPC6H3zX910sNHf0ob 87ItGAsBt/c4fBC1X4pzYmA34WrnqDSlML0+g8Ktr8V36NfM30LWZIMb8NQ0p88b l5kw7KXodt8dBeu2KreFQDdOdQKTmcxXkUlXMDCuXTt3bdSlfTo= =yZbT -END PGP SIGNATURE-
[SECURITY] [DLA 2485-1] golang-golang-x-net-dev security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - - Debian LTS Advisory DLA-2485-1debian-...@lists.debian.org https://www.debian.org/lts/security/Brian May December 09, 2020 https://wiki.debian.org/LTS - - Package: golang-golang-x-net-dev Version: 1:0.0+git20161013.8b4af36+dfsg-3+deb9u1 CVE ID : CVE-2019-9512 CVE-2019-9514 The http2 server support in this package was vulnerable to certain types of DOS attacks. CVE-2019-9512 This code was vulnerable to ping floods, potentially leading to a denial of service. The attacker sends continual pings to an HTTP/2 peer, causing the peer to build an internal queue of responses. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both. CVE-2019-9514 This code was vulnerable to a reset flood, potentially leading to a denial of service. The attacker opens a number of streams and sends an invalid request over each stream that should solicit a stream of RST_STREAM frames from the peer. Depending on how the peer queues the RST_STREAM frames, this can consume excess memory, CPU, or both. For Debian 9 stretch, these problems have been fixed in version 1:0.0+git20161013.8b4af36+dfsg-3+deb9u1. We recommend that you upgrade your golang-golang-x-net-dev packages. For the detailed security status of golang-golang-x-net-dev please refer to its security tracker page at: https://security-tracker.debian.org/tracker/golang-golang-x-net-dev Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKpwfR8DOwu5vyB4TKpJZkldkSvoFAl/P+dIACgkQKpJZkldk Svo42A//XLrZMFKa9pv2kQh+QphGCIVATSxuzlWNzQwjYk9UztXxXbMqbmdvx0Ha +AFFn1X3ZQYboyUmdLWESq4XTgiK+8/EUBqbm39ltG2rZAeAjn74KF7fJ2YPO0Of /sHg6iPmwC8JZ/FXgCnsc2YcXp28qHRYcy3CCEaVnzhtmm7Yi68a+Jy2UlAEjBgT gfdLvVQLkbPU7Z4EE1ZtiOQnvQRO0d6+v668cbX+ZP0L709DstVBAKYGQkyJyQJx 8YbwvxnLXN/s1uU5R3vQTOP1z0pEl9L9M40+7zVAYKHPJ709ubIWPdTKYBYsHwQo 0ir4nE0OgeDadxJaReyhcT+446bqB+U5x1p7hQcDxFc/PSS2lsK26qlP0JP5pgM6 S6QCpob1vRduyWWDHTcqwbnmTWJO75m3sEnrrX214LXSmfukBKYPCLgpR/o5P/UQ 4EdJfuULEDvc1jSM0uKOup4zvANnEGKK9IIRrSbplw2RO9gaThus5uRV6Bm0TBm+ NaAnKXeyJ8iUghXYUCVN5VPpW8Vyrzdn1vCFwR3l9EEiKiwXh1jSlhBS9EJAwiKl g22y4JzXD4Zsmr3+ew+v5IyyBs4Z6OnPOL+wAmYJMj+ZGq98V1g/smb1WZDbzoB/ UJDMWV7Nvl6HhhNMIt8hh27yyNqHcFpM2fWrAv5LOU3ieYhztDc= =7Bfr -END PGP SIGNATURE-
Re: golang-1.7 / CVE-2019-9514 / CVE-2019-9512
Brian May writes: > I have a patch to fix this. As attached. I believe that there are exactly two additional packages that would need to be rebuilt in stretch (i.e. that include the http2 server code): - dnss - gobgpd Not 100% sure if these support creating a http2 server, but might be worth rebuilding just in case. Is it OK for me to add these to dla-needed.txt? -- Brian May
Re: golang-1.7 / CVE-2019-9514 / CVE-2019-9512
I have a patch to fix this. As attached.
I had to apply this patch manually be hand, but I didn't notice any
issues.
I also noticed that tests failed when I built this in a Docker container
without IPv6 support. So I added a tiny change to disable this IPv6 test
if IPv6 is not supported on host (same as with the other IPv6 tests).
All tests pass now, with and without IPv6 support.
What is Debian LTS policy concerning Debian salsa git repos? Should I
push these changes to the git repo in new a debian/stretch branch? Ask
the maintainer for permission? Or what? I don't want to accidentally
tread on any toes here, by asking when I shouldn't or not asking when I
should.
--
Brian May
diff -Nru golang-golang-x-net-dev-0.0+git20161013.8b4af36+dfsg/debian/changelog golang-golang-x-net-dev-0.0+git20161013.8b4af36+dfsg/debian/changelog
--- golang-golang-x-net-dev-0.0+git20161013.8b4af36+dfsg/debian/changelog 2016-10-15 21:31:25.0 +1100
+++ golang-golang-x-net-dev-0.0+git20161013.8b4af36+dfsg/debian/changelog 2020-12-04 09:10:25.0 +1100
@@ -1,3 +1,12 @@
+golang-golang-x-net-dev (1:0.0+git20161013.8b4af36+dfsg-3+deb9u1) stretch-security; urgency=medium
+
+ * Non-maintainer upload by the LTS Security Team.
+ * Fix CVE-2019-9512 and CVE-2019-9514: Prevent DOS attack by limiting unread
+control frames.
+ * Fix test error when building on host without IPv6 support.
+
+ -- Brian May Fri, 04 Dec 2020 09:10:25 +1100
+
golang-golang-x-net-dev (1:0.0+git20161013.8b4af36+dfsg-3) unstable; urgency=medium
[ Paul Tagliamonte ]
diff -Nru golang-golang-x-net-dev-0.0+git20161013.8b4af36+dfsg/debian/patches/0001-http2-limit-number-of-control-frames-in-server-send-.patch golang-golang-x-net-dev-0.0+git20161013.8b4af36+dfsg/debian/patches/0001-http2-limit-number-of-control-frames-in-server-send-.patch
--- golang-golang-x-net-dev-0.0+git20161013.8b4af36+dfsg/debian/patches/0001-http2-limit-number-of-control-frames-in-server-send-.patch 1970-01-01 10:00:00.0 +1000
+++ golang-golang-x-net-dev-0.0+git20161013.8b4af36+dfsg/debian/patches/0001-http2-limit-number-of-control-frames-in-server-send-.patch 2020-12-04 09:10:25.0 +1100
@@ -0,0 +1,163 @@
+From: Brian May
+Date: Fri, 4 Dec 2020 09:03:10 +1100
+Subject: http2: limit number of control frames in server send queue
+
+An attacker could cause servers to queue an unlimited number of PING
+ACKs or RST_STREAM frames by soliciting them and not reading them, until
+the program runs out of memory.
+
+Limit control frames in the queue to a few thousands (matching the limit
+imposed by other vendors) by counting as they enter and exit the scheduler,
+so the protection will work with any WriteScheduler.
+
+Once the limit is exceeded, close the connection, as we have no way to
+communicate with the peer.
+
+This addresses CVE-2019-9512 and CVE-2019-9514.
+
+Fixes golang/go#33606
+---
+ http2/server.go | 32
+ http2/server_test.go | 26 ++
+ http2/writesched.go | 6 ++
+ 3 files changed, 64 insertions(+)
+
+diff --git a/http2/server.go b/http2/server.go
+index c986bc1..2f61ef6 100644
+--- a/http2/server.go
b/http2/server.go
+@@ -64,6 +64,7 @@ const (
+ firstSettingsTimeout = 2 * time.Second // should be in-flight with preface anyway
+ handlerChunkWriteSize = 4 << 10
+ defaultMaxStreams = 250 // TODO: make this 100 as the GFE seems to?
++ maxQueuedControlFrames = 1;
+ )
+
+ var (
+@@ -130,6 +131,15 @@ func (s *Server) maxConcurrentStreams() uint32 {
+ return defaultMaxStreams
+ }
+
++// maxQueuedControlFrames is the maximum number of control frames like
++// SETTINGS, PING and RST_STREAM that will be queued for writing before
++// the connection is closed to prevent memory exhaustion attacks.
++func (s *Server) maxQueuedControlFrames() int {
++ // TODO: if anybody asks, add a Server field, and remember to define the
++ // behavior of negative values.
++ return maxQueuedControlFrames
++}
++
+ // ConfigureServer adds HTTP/2 support to a net/http Server.
+ //
+ // The configuration conf may be nil.
+@@ -373,6 +383,7 @@ type serverConn struct {
+ sawFirstSettings bool // got the initial SETTINGS frame after the preface
+ needToSendSettingsAck bool
+ unackedSettings int// how many SETTINGS have we sent without ACKs?
++ queuedControlFrames int// control frames in the writeSched queue
+ clientMaxStreams uint32 // SETTINGS_MAX_CONCURRENT_STREAMS from client (our PUSH_PROMISE limit)
+ advMaxStreams uint32 // our SETTINGS_MAX_CONCURRENT_STREAMS advertised the client
+ curOpenStreamsuint32 // client's number of open streams
+@@ -713,6 +724,14 @@ func (sc *serverConn) serve() {
+ case fn := <-sc.testHookCh:
+ fn(loopNum)
+ }
++
++ // If the peer is causing us to generate a lot of control frames,
++ // but not reading them from us, assume they are trying to make us
++ // run out of memory.
++ if sc.queuedCont
Re: golang-1.7 / CVE-2019-9514 / CVE-2019-9512
Brian May writes: > But golang-golang-x-net-dev is not a source package. In fact Disregard my rumblings. I was obviously getting confused between 2 packages with similar names: golang-golang-x-net-dev which is a source package and: golang-golang-x-crypto-dev which isn't a source package; golang-go.crypto is. The information in the security tracker is good. -- Brian May
Re: reverse build depends on stretch
Bob Proulx writes: > That should at least make the files text again. Which means I think > following this should work. But note that I had to test with the > non-lz4 version on my system. > > lz4cat /var/lib/apt/lists/*Sources.lz4 | grep-dctrl -s Package -F > Build-Depends,Build-Depends-Indep quilt > > Maybe? OK, thanks for the suggestion. This appears to work on stretch: apt install liblz4-tool lz4cat /var/lib/apt/lists/*Sources.lz4 | grep-dctrl -s Package -F Build-Depends,Build-Depends-Indep quilt -- Brian May
Re: golang-1.7 / CVE-2019-9514 / CVE-2019-9512
Brian May writes: > Anyway, as this was marked as minor for golang-1.7 in Stretch, probably > also should be marked as minor for golang-golang-x-net-dev also... According to https://security-tracker.debian.org/tracker/CVE-2019-9512, golang-golang-x-net-dev is a source package that is vulnerable. But golang-golang-x-net-dev is not a source package. In fact https://packages.debian.org/search?searchon=sourcenames=golang-golang-x-crypto-dev returns 0 results. golang-golang-x-net-dev is a binary package. The source package is called golang-go.crypto. This had really confusing me for a while. -- Brian May
reverse build depends on stretch
How do I do this? I am getting defeated at every step: root@740eafbd9794:/build# grep-dctrl -s Package -F Build-Depends,Build-Depends-Indep quilt /var/lib/apt/lists/*Sources grep-dctrl: /var/lib/apt/lists/*Sources: No such file or directory root@740eafbd9794:/build# ls -l /var/lib/apt/lists/ total 83120 -rw-r- 1 root root0 Dec 2 21:40 lock drwx-- 2 _apt root 4096 Dec 2 21:45 partial -rw-r--r-- 1 root root 15040156 Jul 18 10:40 proxy.pri:_debian_dists_stretch_main_binary-amd64_Packages.lz4 -rw-r--r-- 1 root root 54488073 Jul 18 10:42 proxy.pri:_debian_dists_stretch_main_Contents-amd64.lz4 -rw-r--r-- 1 root root 14139930 Jul 18 10:40 proxy.pri:_debian_dists_stretch_main_source_Sources.lz4 -rw-r--r-- 1 root root 117947 Jul 18 10:52 proxy.pri:_debian_dists_stretch_Release -rw-r--r-- 1 root root 2410 Jul 18 11:00 proxy.pri:_debian_dists_stretch_Release.gpg -rw-r--r-- 1 root root53018 Dec 2 10:51 proxy.pri:_security_dists_stretch_updates_InRelease -rw-r--r-- 1 root root 1260511 Dec 2 10:51 proxy.pri:_security_dists_stretch_updates_main_binary-amd64_Packages.lz4 root@740eafbd9794:/build# file /var/lib/apt/lists/*Sources.lz4 /var/lib/apt/lists/proxy.pri:_debian_dists_stretch_main_source_Sources.lz4: LZ4 compressed data (v1.4+) root@740eafbd9794:/build# lzcat /var/lib/apt/lists/*Sources.lz4 lzcat: /var/lib/apt/lists/proxy.pri:_debian_dists_stretch_main_source_Sources.lz4: File format not recognized root@740eafbd9794:/build# grep-dctrl -s Package -F Build-Depends,Build-Depends-Indep quilt /var/lib/apt/lists/*Sources.lz4 grep-dctrl: /var/lib/apt/lists/proxy.pri:_debian_dists_stretch_main_source_Sources.lz4:7: expected a colon. root@740eafbd9794:/build# grep-aptavail -s Package -F Build-Depends,Build-Depends-Indep quilt [ no results ] -- Brian May https://linuxpenguins.xyz/brian/
Re: golang-github-dgrijalva-jwt-go / CVE-2020-26160
Salvatore Bonaccorso writes: > Your above tracking of the commits seems correct, which would mean > that the issue was firstly introduced actually in v3.0.0 and given the > code is not found in the buster and stretch version this would not > affect hose versions indeed. Yes, you are right. I misread the github webpage, which shows v4.0.0-preview1 in bold, but has v3.0.0 next to it. Good to know the git command to get this information, thanks for that. > So to me updating the CVE entry to not-affected for buster and stretch > (as the respective vulnerable code was introduced later) seems correct > to me. I will do so. -- Brian May
Re: golang-github-dgrijalva-jwt-go / CVE-2020-26160
Salvatore Bonaccorso writes:
> Hi Brian,
>
> On Tue, Dec 01, 2020 at 09:01:37AM +1100, Brian May wrote:
>> I note this package - golang-github-dgrijalva-jwt-go - has been marked
>> as vulnerable to CVE-2020-26160 in both Debian stretch and buster.
>>
>> https://security-tracker.debian.org/tracker/CVE-2020-26160
>>
>> But I can't find any code in these versions that even mentions the
>> aud/audience fields.
>>
>> So I plan to mark these versions as not vulnerable.
>
> Were you able to track down in which version the vulnerability was
> introduced?
If I am reading this correctly, the broken code was introduced here:
https://github.com/dgrijalva/jwt-go/commit/44718f8a89b030a85860eef946090aac75faffac
=== cut ===
func (m MapClaim) VerifyAudience(cmp string) bool {
val, exists := m["aud"]
if !exists {
return true // Don't fail validation if claim doesn't exist
}
if aud, ok := val.(string); ok {
return verifyAud(aud, cmp)
}
return false
}
=== cut ===
But this code, while it is faulty, I don't think it is insecure. If a
list of strings is passed, it will fail the assertion and return false.
Which is a safe value to return.
That issue is introduced here in the following change, which ignores if
the type assertion succeeded or not.
https://github.com/dgrijalva/jwt-go/commit/ec042acef733f1a3fdc10291d159e8e7a0b85ce6
=== cut ===
-func (m MapClaim) VerifyAudience(cmp string) bool {
- val, exists := m["aud"]
- if !exists {
- return true // Don't fail validation if claim doesn't exist
- }
-
- if aud, ok := val.(string); ok {
- return verifyAud(aud, cmp)
- }
- return false
+// Compares the aud claim against cmp.
+// If required is false, this method will return true if the value matches or
is unset
+func (m MapClaim) VerifyAudience(cmp string, req bool) bool {
+ aud, _ := m["aud"].(string)
+ return verifyAud(aud, cmp, req)
}
[...]
-func verifyAud(aud string, cmp string) bool {
- return aud == cmp
+func verifyAud(aud string, cmp string, required bool) bool {
+ if aud == "" {
+ return !required
+ }
+ if subtle.ConstantTimeCompare([]byte(aud), []byte(cmp)) != 0 {
+ return true
+ } else {
+ return false
+ }
=== cut ===
The problem is if the type assertion fails, we get an empty string, and
latter treat it as if the parameter wasn't even supplied.
If I am reading this git stuff correctly, both changes were introduced -
in time - between v2.3.0 and v2.4.0, but weren't actually released until
version 4.0.0-preview1. Which matches what is in the CVE.
The last commit also references a PR, unfortunately it doesn't say which
one. I think it might be #73:
https://github.com/dgrijalva/jwt-go/pull/73
Here is a great quote:
https://github.com/dgrijalva/jwt-go/pull/73#discussion_r34926597
"Seems like this will lead to security issues. Also, this behavior is
different from StandardClaims which just compare directly regardless of
presence."
Oh joy. They knew about the risk here, but looks like they went ahead
anyway with an insecure solution without properly testing it :-(
--
Brian May
golang-github-dgrijalva-jwt-go / CVE-2020-26160
I note this package - golang-github-dgrijalva-jwt-go - has been marked as vulnerable to CVE-2020-26160 in both Debian stretch and buster. https://security-tracker.debian.org/tracker/CVE-2020-26160 But I can't find any code in these versions that even mentions the aud/audience fields. So I plan to mark these versions as not vulnerable. -- Brian May
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
Abhijith PA writes: > Also my issue is cleared and jupyter-notebook *accepted* . I hope > golang-github-ncw-rclone-dev cleared too. Yes, the two packages of mine that were waiting now got in. -- Brian May
[SECURITY] [DLA 2455-1] packer security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - - Debian LTS Advisory DLA-2455-1debian-...@lists.debian.org https://www.debian.org/lts/security/Brian May November 19, 2020 https://wiki.debian.org/LTS - - Package: packer Version: 0.10.2+dfsg-6+deb9u1 CVE ID : CVE-2020-9283 golang-go.crypto was recently updated with a fix for CVE-2020-9283. This in turn requires all packages that use the affected code to be recompiled in order to pick up the security fix. CVE-2020-9283 SSH signature verification could cause Panic when given invalid Public key. For Debian 9 stretch, this problem has been fixed in version 0.10.2+dfsg-6+deb9u1. We recommend that you upgrade your packer packages. For the detailed security status of packer please refer to its security tracker page at: https://security-tracker.debian.org/tracker/packer Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKpwfR8DOwu5vyB4TKpJZkldkSvoFAl+1i6kACgkQKpJZkldk Svoj+Q/+MCj8B1I+bFcG+bv05XwnCk5sgQgdD5fNdWpJ3W8hVc/l2IYdEk0SiyDE SMJfBy5Q3Ttq0i0oo0zs5BrHY3+3fsuBZSKzSHxfL0AURheIk6xuKQ33mG5x5elO eABqUE6sXasaqTy1QR/MT9JAiRpkMPHyQCuWyP95fJQJwdf77fhS6RpeyqsVeVI6 MsS6Fn8VYe0e0GiB3udXRwiMFxfMLXbBFL1XVYK1L60TqhgljoCgXhbgnlPacFXm 5eheDHJfBx0sqtOyej2n+JqLIZJYfVkxFezt04hyG4L5861BfeEby/Q1avEI7Gjp ZeUxQKUgODnpmZhc4pK2xxGBdT35PSF7YDLqkWXyLynOW4v83u7WjRbxSXcF+8EE bl5zfP75Z02cX1xOAZo1KnByLkBcBoIUeBd0KNjRMFcmRA4EgSrshKlA084Oa3ui qoUOuoo/Bxl2ZCjaLAo2aZB8zGGIiJPRNV0L1CXjAA2QrTY/IszglNQpn5J7h2Ga 9zRRh4z29tHj7aT/DYKgVpxtsdSHEkpYEZriQb89AQs57ga4Y36zL9hlG0YmwYPp 0tMY/1993hpC65dPRHRKndKq9p9b+xsuNVGVKLpr2vCoZUQtJh+OEP+8HT1GqEY5 Nv9SZ3Q5e/SbhYLHKCXT2XDklszgEjrJfe1UIV7hKP5mZjDenC0= =+L0M -END PGP SIGNATURE-
[SECURITY] [DLA 2454-1] rclone security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - - Debian LTS Advisory DLA-2454-1debian-...@lists.debian.org https://www.debian.org/lts/security/Brian May November 19, 2020 https://wiki.debian.org/LTS - - Package: rclone Version: 1.35-1+deb8u1 CVE ID : CVE-2019-11840 golang-go.crypto was recently updated with a fix for CVE-2019-11840. This in turn requires all packages that use the affected code to be recompiled in order to pick up the security fix. CVE-2019-11840 An issue was discovered in supplementary Go cryptography libraries, aka golang-googlecode-go-crypto. If more than 256 GiB of keystream is generated, or if the counter otherwise grows greater than 32 bits, the amd64 implementation will first generate incorrect output, and then cycle back to previously generated keystream. Repeated keystream bytes can lead to loss of confidentiality in encryption applications, or to predictability in CSPRNG applications. For Debian 9 stretch, this problem has been fixed in version 1.35-1+deb8u1. We recommend that you upgrade your rclone packages. For the detailed security status of rclone please refer to its security tracker page at: https://security-tracker.debian.org/tracker/rclone Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKpwfR8DOwu5vyB4TKpJZkldkSvoFAl+1i6cACgkQKpJZkldk SvqAvg/+NB3ihnYZBbnAuY1Lhq2sDGMaoigj+nhhN+ih0bPtFgj6YR4mc8E2Kaab FX5/N8POIYdhzX3OMSJr3u6vHz2MI8vJ+gII3eeHR4RZAThY6IphYWsqU9idCgqe iRYZUJxpLK1yFEqzDf9wKMXxearCXdcnWeK6G4Ly4a30hpHe7qCvxxLpXH1vv2ma CbvSyEyWBIrolk9ef6qXxagmgnbOWjRi96doy7ycelEu5z0ydNOYnsTZi/pw+2eU 7P6lYUSoYBUiAESZeglyTAMdgDlIehfY1PjXttmGNqTPOaV5sgxtFskf7mDjl2+r IhYvdsccxGRTn/E/tEiEPUrvjUHXbOWKZ8IEGJBvBgMJMIfw8v9qdnVB3x9BLifN /en2dy7xIK5IR30izphF09YW5mnu2nEpzbpZoQAqFh3kWBlzqokx3GNrBWGbVm+9 6WwQ0MEiRAfZK5c6qQ40abTUZeLnh60OIunhsb0YqCPheJtuRYJMczWzxSIXaA9g Px1DHKjclzvhfCKwZy4976IVRCz0paYatAwCcWFvnjUdNm7vjKANM9DKpaH4eKR1 NHh8LRp6Prk7lFpNdBSIJKOZFkhPOuc6ywmVHD7B4PUaMKp5LYSV1MKYq0C2C3Yk pv41JHCg6f0WvfJ8wi0P3nigP29r80SG7GiTUJ0po6sbKXaOi8g= =i4w2 -END PGP SIGNATURE-
[SECURITY] [DLA 2453-1] restic security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - - Debian LTS Advisory DLA-2453-1debian-...@lists.debian.org https://www.debian.org/lts/security/Brian May November 17, 2020 https://wiki.debian.org/LTS - - Package: restic Version: 0.3.3-1+deb9u1 CVE ID : CVE-2020-9283 golang-go.crypto was recently updated with a fix for CVE-2020-9283. This in turn requires all packages that use the affected code to be recompiled in order to pick up the security fix. CVE-2020-9283 SSH signature verification could cause Panic when given invalid Public key. For Debian 9 stretch, this problem has been fixed in version 0.3.3-1+deb9u1. We recommend that you upgrade your restic packages. For the detailed security status of restic please refer to its security tracker page at: https://security-tracker.debian.org/tracker/restic Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKpwfR8DOwu5vyB4TKpJZkldkSvoFAl+y89sACgkQKpJZkldk Svo/mQ//byuAryq/R2DPP8Jps6jsNp61xH7gDU4+5MUofps/OgoD0POzOlHyVtOr 4DyNx2ihe7dWqQt4zoZoBFx3BJP37oKjA73uP3zlucvwxMvWduI2b2PuR0rbiFrY WDAe/2g13qBzKCxrBIKTerfeIdiqVk3rfiDxCeQ4oBmeNi3AFYJZoBb8CCJDqIez 3Nl7ETqJzby5me+M4jD5pY/7bYHpqGFF+AmOyJt4jonHfNxi20k5WumdOlyUq8BN SOGu4qg+h5gruKhyYISDQnS3FjTJwWEBaJwWEgwPkdmnqTdc6gyf6M1Zsr6vLeu9 5Sq3JstomgnN6fNwZhAzJR34vvEEbanwbn92lQJMkuP5+LOaSD3qVvoVcXIEYPeo NjQzzgbvfcMwPqamgAENbftu9ovxyMO3FxqXY9uchASHhj8aoZZaP2ztK9u9WE7f A6pRfOreu8hTSW8A3Ypwf0RBij8NDrNE645ZSES54TrIAu/bliHZrHO7vTMYqLR2 oVcdAJn3UFYBxG4xJkd8Sl40sS5eALGoa4hQKisYepVV3WC6hptV5lTBoUvVHLHx D7fh1cyDvgdd7sLnT17SvfKZriReqb6rQdOHmbVTIELoAF3KS16RySIxs7HjNmT1 a5Uf5oaRlyNzLZZbVnEvnRpKUazmCIMeH01cNdgiZ1RM+XOFbX8= =NL89 -END PGP SIGNATURE-
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
Abhijith PA writes: > I generated DLA for jupyter-notebook just before upload. But upload was > rejected due to `Built-Using refers to non-existing source package`. I have > pinged ftp masters couple of times to manually move needed packages to > security-master. If any ftp masters here, please help. I have a similar issue. I opened up a bug report: https://bugs.debian.org/974877 I suggest you do they same. At least with the bug report there is a formal public record of the pending request. -- Brian May
Re: golang-go.crypto / CVE-2019-11841
Brian May writes: > I have contacted ftp-master concerning rclone. Waiting a response. Still no response. I submitted a bug report: https://bugs.debian.org/974877 -- Brian May
Re: golang-go.crypto / CVE-2019-11841
Paul Wise writes: > It documents which source package versions need to be shipped to > ensure license compliance. > > https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using > > Please note that golang folks were/are using it in a more general way > than the use it was intended for. Interesting. It looks like obfs4proxy does not have this header, so it uploaded fine. But snapd does have this header, so I imagine it will have the same problem. I have contacted ftp-master concerning rclone. Waiting a response. -- Brian May
Re: golang-go.crypto / CVE-2019-11841
Brian May writes: > What is the process for rebuilding these in stretch LTS? Do I need to > add entries to dla-needed.txt and claim these entries? I might need help here: === cut === Debian FTP Masters (28 mins. ago) () Subject: rclone_1.35-1+deb8u1_amd64.changes REJECTED To: d...@security.debian.org, b...@debian.org Date: Mon, 09 Nov 2020 21:50:14 + golang-github-ncw-rclone-dev_1.35-1+deb8u1_all.deb: Built-Using refers to non-existing source package go-md2man (= 1.0.6+ds-1) === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. === cut === go-md2man is in stretch, not stretch-security. But I don't see any reference to the package in the source: === cut === $ grep -r go-md2man Godeps/Godeps.json: "ImportPath": "github.com/cpuguy83/go-md2man/md2man", === cut === If I look at the binary package however, I have this "Built-Using" header: === cut === root@a852fb6a8d37:/tmp/brian/tmphbdhga9l/build/amd64# dpkg -I golang-github-ncw-rclone-dev_1.35-1+deb8u1_all.deb new debian package, version 2.0. size 177936 bytes: control archive=6263 bytes. 2753 bytes,16 lines control 17449 bytes, 177 lines md5sums Package: golang-github-ncw-rclone-dev Source: rclone Version: 1.35-1+deb8u1 Architecture: all Maintainer: Debian Go Packaging Team Installed-Size: 1059 Depends: golang-bazil-fuse-dev, golang-github-aws-aws-sdk-go-dev, golang-github-mreiferson-go-httpclient-dev, golang-github-ncw-go-acd-dev, golang-github-ncw-swift-dev, golang-github-pkg-errors-dev, golang-github-rfjakob-eme-dev, golang-github-skratchdot-open-golang-dev, golang-github-spf13-cobra-dev, golang-github-spf13-pflag-dev, golang-github-stacktic-dropbox-dev, golang-github-stretchr-testify-dev, golang-github-tsenart-tb-dev, golang-github-unknwon-goconfig-dev, golang-github-vividcortex-ewma-dev, golang-golang-x-crypto-dev, golang-golang-x-net-dev, golang-golang-x-oauth2-google-dev, golang-golang-x-sys-dev, golang-golang-x-text-dev, golang-google-api-dev Built-Using: go-md2man (= 1.0.6+ds-1), golang-1.7 (= 1.7.4-2+deb9u1), golang-bazil-fuse (= 0.0~git20160811.0.371fbbd-2), golang-blackfriday (= 1.4+git20161003.40.5f33e7b-1), golang-github-aws-aws-sdk-go (= 1.1.14+dfsg-2), golang-github-davecgh-go-spew (= 1.1.0-1), golang-github-go-ini-ini (= 1.8.6-2), golang-github-google-go-querystring (= 0.0~git20151028.0.2a60fc2-1), golang-github-jmespath-go-jmespath (= 0.2.2-2), golang-github-ncw-go-acd (= 0.0~git20161119.0.7954f1f-1), golang-github-ncw-swift (= 0.0~git20160617.0.b964f2c-2), golang-github-pkg-errors (= 0.8.0-1), golang-github-pmezard-go-difflib (= 1.0.0-1), golang-github-rfjakob-eme (= 1.0-2), golang-github-shurcool-sanitized-anchor-name (= 0.0~git20160918.0.1dba4b3-1), golang-github-skratchdot-open-golang (= 0.0~git20160302.0.75fb7ed-2), golang-github-spf13-cobra (= 0.0~git20161229.0.1dd5ff2-1), golang-github-spf13-pflag (= 0.0~git20161024.0.5ccb023-1), golang-github-stacktic-dropbox (= 0.0~git20160424.0.58f839b-2), golang-github-tsenart-tb (= 0.0~git20151208.0.19f4c3d-2), golang-github-unknwon-goconfig (= 0.0~git20160828.0.5aa4f8c-3), golang-github-vividcortex-ewma (= 0.0~git20160822.20.c595cd8-3), golang-go.crypto (= 1:0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782-1+deb8u1), golang-golang-x-net-dev (= 1:0.0+git20161013.8b4af36+dfsg-3), golang-golang-x-oauth2 (= 0.0~git20161103.0.36bc617-4), golang-golang-x-sys (= 0.0~git20161122.0.30237cf-1), golang-google-api (= 0.0~git20161128.3cc2e59-2), golang-google-cloud (= 0.5.0-2), golang-testify (= 1.1.4+ds-1), golang-x-text (= 0.0~git20161013.0.c745997-2) Section: devel Priority: extra Homepage: https://github.com/ncw/rclone Description: go source code of rclone Rclone is a program to sync files and directories between the local file system and a variety of commercial cloud storage providers. . This package contains rclone's source code. === cut === What is this "Built-Using" header? Where does it come from? Do I have to upload everything in "Built-Using" to stretch-security first? Why? How do I resolve this in a sane and sensible manner? -- Brian May
[SECURITY] [DLA 2442-1] obfs4proxy security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - - Debian LTS Advisory DLA-2442-1debian-...@lists.debian.org https://www.debian.org/lts/security/Brian May November 10, 2020 https://wiki.debian.org/LTS - - Package: obfs4proxy Version: 0.0.7-1+deb8u1 CVE ID : CVE-2019-11840 golang-go.crypto was recently updated with a fix for CVE-2019-11840. This in turn requires all packages that use the affected code to be recompiled in order to pick up the security fix. CVE-2019-11840 An issue was discovered in supplementary Go cryptography libraries, aka golang-googlecode-go-crypto. If more than 256 GiB of keystream is generated, or if the counter otherwise grows greater than 32 bits, the amd64 implementation will first generate incorrect output, and then cycle back to previously generated keystream. Repeated keystream bytes can lead to loss of confidentiality in encryption applications, or to predictability in CSPRNG applications. For Debian 9 stretch, this problem has been fixed in version3 0.0.7-1+deb8u1. We recommend that you upgrade your obfs4proxy packages. For the detailed security status of obfs4proxy please refer to its security tracker page at: https://security-tracker.debian.org/tracker/obfs4proxy Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKpwfR8DOwu5vyB4TKpJZkldkSvoFAl+ptp0ACgkQKpJZkldk Svpa5g//cho1IzLR64FY3OrZEFHIPiOFZaw3QCZZJ1EiiBiTe+UFJ/Bcdy6sWF8o mBMsmiTxIpEww5CyENgVkmNN0gK0v7hl0PG2XBJPJZ/okDhxYklRnKB4pTfVNIqr BJWsq+7jIlPWFCDQSR8ApmPGvoABeYLzorg/2+lur30dOA3dr0XM1P5NLdOOUg8A uyJqg3y5iTYq2OTHxNHCIHBR1AHdyW72WxOBvTmm9o2BhuDneSZtzRm+pWX7DV02 nJYOC01BsawUAEvAFHhVZgLOlZmAyU8JgvA4CbHjZI0hERwr7RxUmVm7WeaYpAvq P1Ega6BIzdWjngYRj4pwA5Lhps26527sF+6GgnOYacoz7VQG7P2DSGtE38Deyrln gJjN8iR+Yk086HOlqyEJ84EibXOnr4ztpYXri5ofgQ7z2OtMbYFasL9cKfhmya5B f0Y05/yuWD+3gQ8r7Ur7Typ4iFwL8SRYEAzNcrhiw7PEIjxtgoUusbrVS+bVkcXX tDp0nfxrrq7SsHNGeNIJjafhDT4n4W/Kak23t4YSQYyUO4DR/dTiDM/PcKdrPTI9 cuoU1r3PbDtojFU4mu+bS90yzDg96kWt3ZC8hOTCXsS+wsTpBbX71RfNqE+t67JF OBgwNrGkCSEd2eA9dTuwvbqk3LmxBOXRs1EQCwH9IHhamp+Nb38= =9AtJ -END PGP SIGNATURE-
Re: golang-go.crypto / CVE-2019-11841
Brian May writes: > This produced the following output to STDOUT: > > === cut === > obfs4proxy salsa20 > packer ssh/keys > rclone salsa20 > restic ssh/keys > snapd salsa20 > === cut === snapd seems to reproduce test failures, even without my security updates. :-( What is the process for rebuilding these in stretch LTS? Do I need to add entries to dla-needed.txt and claim these entries? -- Brian May
Re: golang-go.crypto / CVE-2019-11841
Brian May writes:
> Package: acmetool
> Package: chasquid
> Package: coyim
> Package: go-wire
> Package: gocryptfs
> Package: golang-github-azure-azure-sdk-for-go
> Package: golang-github-azure-go-autorest
> Package: golang-github-azure-go-ntlmssp
> Package: golang-github-bowery-prompt
> Package: golang-github-coreos-ioprogress
> Package: golang-github-coreos-pkg
> Package: golang-github-elithrar-simple-scrypt
> Package: golang-github-endophage-gotuf
> Package: golang-github-howeyc-gopass
> Package: golang-github-kisom-goutils
> Package: golang-github-pkg-sftp
> Package: golang-github-rackspace-gophercloud
> Package: golang-github-weaveworks-mesh
> Package: golang-github-xenolf-lego
> Package: golang-github-xordataexchange-crypt
> Package: golang-golang-x-net-dev
> Package: golang-gopkg-dancannon-gorethink.v2
> Package: golang-gopkg-macaroon.v1
> Package: govendor
> Package: influxdb
> Package: mongo-tools
> Package: packer
> Package: rclone
> Package: restic
> Package: snapd
> Package: syncthing
> Package: tendermint-ed25519
> Package: tendermint-go-merkle
> Package: golang-ed25519-dev
> Package: golang-github-bradfitz-http2
> Package: golang-github-endophage-gotuf
> Package: golang-pault-go-debian
> Package: influxdb
> Package: obfs4proxy
> Package: pluginhook
I downloaded all binary packages associated with these source packages
and ran the following script:
(for simplicity I commented out the line that calls my script from
https://github.com/brianmay/bampkgbuild/ that uses docker to Download
the required files)
=== cut ===
#!/bin/sh
set -e
set -x
# PATH="$HOME/tree/personal/bampkgbuild:$PATH"
# download --architecture amd64 --distribution stretch --download binaries --
"$@" >&2
# Create a temporary directory and store its name in a variable ...
TMPDIR=$(mktemp -d)
# Bail out if the temp directory wasn't created successfully.
if [ ! -e $TMPDIR ]; then
echo "Failed to create temp directory" >&2
exit 1
fi
# Make sure it gets removed even if the script exits abnormally.
trap "exit 1" HUP INT PIPE QUIT TERM
trap 'rm -rf "$TMPDIR"' EXIT
for i in *.deb; do
rm -rf "$TMPDIR"
dpkg-deb --raw-extract "$i" "$TMPDIR" >&2
HIT=""
if grep -qr 'src/golang.org/x/crypto/salsa20' -- $TMPDIR >&2; then
HIT="salsa20 $HIT"
fi
if grep -qr 'src/golang.org/x/crypto/openpgp/clearsign' -- $TMPDIR >&2; then
HIT="openpgp/clearsign $HIT"
fi
if grep -qr 'src/golang.org/x/crypto/ssh/keys' -- $TMPDIR >&2; then
HIT="ssh/keys $HIT"
fi
if test -n "$HIT"; then
echo "Package $i needs rebuilding" >&2
source="$(dpkg-deb -f "$i" Package)"
if test -z "$source"; then
source="$(dpkg-deb -f "$i" Package)"
fi
echo "$source $HIT"
fi
done
=== cut ===
This produced the following output to STDOUT:
=== cut ===
obfs4proxy salsa20
packer ssh/keys
rclone salsa20
restic ssh/keys
snapd salsa20
=== cut ===
So I believe this is the list of packages that need to be rebuilt.
--
Brian May
Re: golang-go.crypto / CVE-2019-11841
Emilio Pozuelo Monfort writes: > I would look for an automated way to do this. E.g. by downloading and > inspecting > the binaries to see if they have the affected code. Hmmm. Good idea in theory, but not sure how to do this in practise. I tried building two copies of acmetool, and comparing, but it looks like go builds are not yet reproducible. There is the known issue that the build path is encoded in the result. But I am getting other differences too. Hmm. But it looks like /usr/bin/acmetool contains strings such as: /tmp/brian/tmpxbsh4mst/build/amd64/source/obj-x86_64-linux-gnu/src/golang.org/x/crypto/ocsp/ocsp.go This looks like a source file. Wonder if it is possible to extract a list of all source files that were used to build acmetool... So far not getting anywhere with "readelf". But maybe "strings" might be sufficient. -- Brian May
Re: golang-go.crypto / CVE-2019-11841
Emilio Pozuelo Monfort writes: > That go be a simplification. However there's a chance one of those golang- > packages also has a bin package with a real binary, and then that may need to > be > rebuilt as well. > > Also, not all packages with compiled binaries necessarily need a rebuild. > E.g. > they may not use the affected code at all, just other parts of > golang-go.crypto. I am inclined to think that golang-* packages with binaries that include stuff from golang-go.crypto are likely to be for development/building purposes only, and perhaps not so important ... ? However it sounds like we need to investigate each package one at a time: Package: acmetool Package: chasquid Package: coyim Package: go-wire Package: gocryptfs Package: golang-github-azure-azure-sdk-for-go Package: golang-github-azure-go-autorest Package: golang-github-azure-go-ntlmssp Package: golang-github-bowery-prompt Package: golang-github-coreos-ioprogress Package: golang-github-coreos-pkg Package: golang-github-elithrar-simple-scrypt Package: golang-github-endophage-gotuf Package: golang-github-howeyc-gopass Package: golang-github-kisom-goutils Package: golang-github-pkg-sftp Package: golang-github-rackspace-gophercloud Package: golang-github-weaveworks-mesh Package: golang-github-xenolf-lego Package: golang-github-xordataexchange-crypt Package: golang-golang-x-net-dev Package: golang-gopkg-dancannon-gorethink.v2 Package: golang-gopkg-macaroon.v1 Package: govendor Package: influxdb Package: mongo-tools Package: packer Package: rclone Package: restic Package: snapd Package: syncthing Package: tendermint-ed25519 Package: tendermint-go-merkle Package: golang-ed25519-dev Package: golang-github-bradfitz-http2 Package: golang-github-endophage-gotuf Package: golang-pault-go-debian Package: influxdb Package: obfs4proxy Package: pluginhook We probably need someway of keeping track of what packages have already been looked at and their status with respect to this rebuild. Not really convinced data/dla-needed.txt is up to this task. >> How do I rebuild? Do I need to upload a new version? > > Unless they already are in stretch-security, then yes, sourceful uploads will > be > needed. I hope there are none of these packages that have the same version in buster... Not seen any problems yet however. Looking at items in the list from the top: acmetool - automatic certificate acquisition tool for Let's Encrypt OK, good candidate. A certificate signing tool needs to be secure. But, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954189 - it looks like the 0.0.58-5+b2 in stretch is likely to be completely broken and unusable for unrelated reasons. Is this something we should be fixing? My guess is anybody who needs in buster has already moved to the version in backports. Or is this a candidate to add to https://salsa.debian.org/debian/debian-security-support/-/blob/master/security-support-ended.deb9? In any case, unlikely to use ssh public keys or cleartext signatures, so probably won't need to rebuild. chasquid - simple SMTP (email) server written in go coyim - safe and secure XMPP chat client go-wire - Go bindings for the Wire encoding protocol gocryptfs - Encrypted overlay filesystem written in Go. Unlikely to use ssh public keys or cleartext signatures. ? same? In fact, I suspect this might hold true for the remainder of the packages. With the exception of maybe golang-github-pkg-sftp. Which is entirely go files. How am I going so far? Too conservative? However now I also realise another limitation in the above list. It probably won't mention, for example, packages that build depend on golang-github-pkg-sftp-dev which depends on golang-golang-x-crypto-dev. -- Brian May
Re: golang-go.crypto / CVE-2019-11841
Emilio Pozuelo Monfort writes: > Note that many of those are golang modules which only ship go code on the > -dev > package, and thus don't need a rebuild. OTOH, compiled binaries may need a > rebuild if they use the affected code (directly or indirectly). How do I tell which ones need rebuilding? Maybe just the ones without the 'golang-` prefix? How do I rebuild? Do I need to upload a new version? -- Brian May
Re: golang-go.crypto / CVE-2019-11841
Emilio Pozuelo Monfort writes: > Have you checked if any rdeps need to be rebuilt? No. I imagine there might be some. How do I check? I can't remember right now how to check reverse build depends. -- Brian May
[security tracker role] Processing a16b55300564d69f4c3d37a0c84cc41bf9b5638b failed
I have no idea what is wrong here, or why it is fixated on a commit that is 2 commits behind master... -- Brian May --- Begin Message --- The error message was: reference to unknown bug DLA-0001-1 reference to unknown bug DLA-0002-1 reference to unknown bug DLA-0003-1 reference to unknown bug DLA-0004-1 reference to unknown bug DLA-0005-1 reference to unknown bug DLA-0006-1 reference to unknown bug DLA-0007-1 reference to unknown bug DLA-0008-1 reference to unknown bug DLA-0009-1 reference to unknown bug DLA-0010-1 reference to unknown bug DLA-0011-1 reference to unknown bug DLA-0012-1 reference to unknown bug DLA-0013-1 reference to unknown bug DLA-0014-1 reference to unknown bug DLA-0015-1 reference to unknown bug DLA-0018-1 reference to unknown bug DLA-0019-1 reference to unknown bug DLA-0021-1 reference to unknown bug DLA-0022-1 reference to unknown bug DLA-100-1 reference to unknown bug DLA-1000-1 reference to unknown bug DLA-1001-1 reference to unknown bug DLA-1002-1 reference to unknown bug DLA-1003-1 reference to unknown bug DLA-1004-1 reference to unknown bug DLA-1005-1 reference to unknown bug DLA-1006-1 reference to unknown bug DLA-1007-1 reference to unknown bug DLA-1008-1 reference to unknown bug DLA-1009-1 reference to unknown bug DLA-101-1 reference to unknown bug DLA-1010-1 reference to unknown bug DLA-1011-1 reference to unknown bug DLA-1012-1 reference to unknown bug DLA-1013-1 reference to unknown bug DLA-1014-1 reference to unknown bug DLA-1015-1 reference to unknown bug DLA-1016-1 reference to unknown bug DLA-1017-1 reference to unknown bug DLA-1018-1 reference to unknown bug DLA-1019-1 reference to unknown bug DLA-102-1 reference to unknown bug DLA-1020-1 reference to unknown bug DLA-1021-1 reference to unknown bug DLA-1022-1 reference to unknown bug DLA-1023-1 reference to unknown bug DLA-1024-1 reference to unknown bug DLA-1025-1 reference to unknown bug DLA-1026-1 reference to unknown bug DLA-1027-1 reference to unknown bug DLA-1028-1 reference to unknown bug DLA-1029-1 reference to unknown bug DLA-103-1 reference to unknown bug DLA-1030-1 reference to unknown bug DLA-1031-1 reference to unknown bug DLA-1033-1 reference to unknown bug DLA-1034-1 reference to unknown bug DLA-1035-1 reference to unknown bug DLA-1036-1 reference to unknown bug DLA-1037-1 reference to unknown bug DLA-1038-1 reference to unknown bug DLA-1039-1 reference to unknown bug DLA-104-1 reference to unknown bug DLA-1040-1 reference to unknown bug DLA-1041-1 reference to unknown bug DLA-1042-1 reference to unknown bug DLA-1043-1 reference to unknown bug DLA-1044-1 reference to unknown bug DLA-1045-1 reference to unknown bug DLA-1046-1 reference to unknown bug DLA-1047-1 reference to unknown bug DLA-1048-1 reference to unknown bug DLA-1049-1 reference to unknown bug DLA-105-1 reference to unknown bug DLA-1050-1 reference to unknown bug DLA-1051-1 reference to unknown bug DLA-1052-1 reference to unknown bug DLA-1053-1 reference to unknown bug DLA-1054-1 reference to unknown bug DLA-1055-1 reference to unknown bug DLA-1056-1 reference to unknown bug DLA-1057-1 reference to unknown bug DLA-1058-1 reference to unknown bug DLA-1059-1 reference to unknown bug DLA-106-1 reference to unknown bug DLA-1060-1 reference to unknown bug DLA-1061-1 reference to unknown bug DLA-1062-1 reference to unknown bug DLA-1063-1 reference to unknown bug DLA-1064-1 reference to unknown bug DLA-1065-1 reference to unknown bug DLA-1066-1 reference to unknown bug DLA-1067-1 reference to unknown bug DLA-1068-1 reference to unknown bug DLA-1069-1 reference to unknown bug DLA-107-1 reference to unknown bug DLA-1070-1 reference to unknown bug DLA-1071-1 reference to unknown bug DLA-1072-1 reference to unknown bug DLA-1073-1 reference to unknown bug DLA-1074-1 reference to unknown bug DLA-1075-1 reference to unknown bug DLA-1076-1 reference to unknown bug DLA-1077-1 reference to unknown bug DLA-1078-1 reference to unknown bug DLA-1079-1 reference to unknown bug DLA-1080-1 reference to unknown bug DLA-1081-1 reference to unknown bug DLA-1082-1 reference to unknown bug DLA-1083-1 reference to unknown bug DLA-1084-1 reference to unknown bug DLA-1085-1 reference to unknown bug DLA-1087-1 reference to unknown bug DLA-1088-1 reference to unknown bug DLA-1089-1 reference to unknown bug DLA-109-1 reference to unknown bug DLA-1090-1 reference to unknown bug DLA-1091-1 reference to unknown bug DLA-1092-1 reference to unknown bug DLA-1093-1 reference to unknown bug DLA-1094-1 reference to unknown bug DLA-1095-1 reference to unknown bug DLA-1096-1 reference to unknown bug DLA-1097-1 reference to unknown bug DLA-1098-1 reference to unknown bug DLA-1099-1 reference to unknown bug DLA-110-1 reference to unknown bug DLA-1100-1 reference to unknown bug DLA-1101-1 reference to unknown bug DLA-1102-1 reference to unknown bug DLA-1103-1 reference to unknown bug DLA-1104-1 reference to unknown bug DLA-1105-1 reference to unknown bug DLA-1106-1 reference
[SECURITY] [DLA 2402-1] golang-go.crypto security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - - Debian LTS Advisory DLA-2402-1debian-...@lists.debian.org https://www.debian.org/lts/security/Brian May October 08, 2020 https://wiki.debian.org/LTS - - Package: golang-go.crypto Version: 1:0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782-1+deb8u1 CVE ID : CVE-2019-11840 CVE-2019-11841 CVE-2020-9283 CVE-2019-11840 An issue was discovered in supplementary Go cryptography libraries, aka golang-googlecode-go-crypto. If more than 256 GiB of keystream is generated, or if the counter otherwise grows greater than 32 bits, the amd64 implementation will first generate incorrect output, and then cycle back to previously generated keystream. Repeated keystream bytes can lead to loss of confidentiality in encryption applications, or to predictability in CSPRNG applications. CVE-2019-11841 A message-forgery issue was discovered in crypto/openpgp/clearsign/clearsign.go in supplementary Go cryptography libraries. The "Hash" Armor Header specifies the message digest algorithm(s) used for the signature. Since the library skips Armor Header parsing in general, an attacker can not only embed arbitrary Armor Headers, but also prepend arbitrary text to cleartext messages without invalidating the signatures. CVE-2020-9283 golang.org/x/crypto allows a panic during signature verification in the golang.org/x/crypto/ssh package. A client can attack an SSH server that accepts public keys. Also, a server can attack any SSH client. For Debian 9 stretch, these problems have been fixed in version 1:0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782-1+deb8u1. We recommend that you upgrade your golang-go.crypto packages. For the detailed security status of golang-go.crypto please refer to its security tracker page at: https://security-tracker.debian.org/tracker/golang-go.crypto Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKpwfR8DOwu5vyB4TKpJZkldkSvoFAl9+OCsACgkQKpJZkldk SvpsyQ/6AjE2foemSU+ybWNpRIPdz8/10n1xYAq22/aInfR/CwlfrhU1+3939jAi d/9nFDl69XHgETnnT0nd6RNXHN279Ecwev31816O9ndVu6POtrbm5Pnwoay7EWou vcqiY3zxrkjrlO95lVzUA+va0hTx3RP76AzPKsF16frH9HkAQB+tdJRurj8VWJuy 79P+/fLJdrFr50yjQS4CIgh63YWLIi+YNkCxphavZsnrqLBgv8eWCR9tD7zdcQq/ IdrwB0PSdpiqVtwtka/xLvyQC11UmLDH+TDDxXRXnLzIxNEzUPeuc8JSMFo44315 XY/9xjsLgf+WmJ19HrjoBavqN1xhFiLRAzvqMQA3OR+IbDuQacBylrn4XbVWwPzh 1vSi0F2EIvV0901W9Tk0d0L0cn3O+QLh54V6Z2ZWYBgdRO9SY787VULXnR9Dw1ib z0Th3b1HG3n7GfhV/MF9pbinNeqSxiqZqG15FA3PVVlNs3stXw52NkBMehf1RN9J r5rL5fJvHuHQVuXJIDjq4HE7x2hcCQVTRdfiMriW/4wynwts3+b8S6AxjW+/5pBy WZi05GjgZsay+mi9uayDfVylruTDWvyg3bJ6YgqrtY7MEi2xkaERi/xM/OnVl7qy sYVNGfgMkRLOon/5VZ6kqKnOUU12m/gmQprw0Lo+UHLhz9VbO9g= =epyk -END PGP SIGNATURE-
Re: golang-go.crypto / CVE-2019-11841
Utkarsh Gupta writes: > Ah, great. It'd nice to include this then! :) Done. See attached patch. I had to apply it manually, because patch was misapplying one of the hunks in the wrong place. There were several hunks that apply to SKEd25519 public key stuff I skipped also because this version does not have SKEd25519 public key stuff. I note that some of the ssh tests are skipped because sshd is not installed. So I added "openssh-server" to the build depends, and found that one of the tests hangs. Even if I revert my changes. The tests related to these change appear to pass, even without openssh-server installed, so I think this is good to go. -- Brian May diff -Nru golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog --- golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog 2017-04-26 17:42:23.0 +1000 +++ golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog 2020-09-07 08:29:03.0 +1000 @@ -1,3 +1,14 @@ +golang-go.crypto (1:0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782-1+deb8u1) jessie-security; urgency=medium + + * Non-maintainer upload by the LTS Security Team. + * Fix CVE-2019-11841: reject potentially misleading headers and messages. + * Fix CVE-2019-11840: fix keystream loop in amd64 assembly when overflowing +32-bit counter. + * Fix CVE-2020-9283: signature verification could cause Panic when given +invalid Public key. + + -- Brian May Mon, 07 Sep 2020 08:29:03 +1000 + golang-go.crypto (1:0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782-1) unstable; urgency=medium * Reverts previous upload to permit freeze exception. diff -Nru golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/patches/CVE-2019-11840.patch golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/patches/CVE-2019-11840.patch --- golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/patches/CVE-2019-11840.patch 1970-01-01 10:00:00.0 +1000 +++ golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/patches/CVE-2019-11840.patch 2020-09-07 08:29:03.0 +1000 @@ -0,0 +1,1922 @@ +commit b7391e95e576cacdcdd422573063bc057239113d +Author: Filippo Valsorda +Date: Tue Mar 19 18:29:04 2019 -0400 + +salsa20/salsa: fix keystream loop in amd64 assembly when overflowing 32-bit counter + +Fixes golang/go#30965 + +Change-Id: I83a804d555c048e0124c35f95c9e611b2c5bdb01 +Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/436856 +Reviewed-by: Adam Langley +Reviewed-on: https://go-review.googlesource.com/c/crypto/+/168406 +Reviewed-by: Filippo Valsorda +Run-TryBot: Filippo Valsorda +TryBot-Result: Gobot Gobot + +Index: golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/salsa20/salsa/salsa20_amd64.go +=== +--- golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782.orig/salsa20/salsa/salsa20_amd64.go golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/salsa20/salsa/salsa20_amd64.go +@@ -6,10 +6,9 @@ + + package salsa + +-// This function is implemented in salsa2020_amd64.s. +- + //go:noescape + ++// salsa2020XORKeyStream is implemented in salsa20_amd64.s. + func salsa2020XORKeyStream(out, in *byte, n uint64, nonce, key *byte) + + // XORKeyStream crypts bytes from in to out using the given key and counters. +Index: golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/salsa20/salsa/salsa2020_amd64.s +=== +--- golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782.orig/salsa20/salsa/salsa2020_amd64.s /dev/null +@@ -1,902 +0,0 @@ +-// Copyright 2012 The Go Authors. All rights reserved. +-// Use of this source code is governed by a BSD-style +-// license that can be found in the LICENSE file. +- +-// +build amd64,!appengine,!gccgo +- +-// This code was translated into a form compatible with 6a from the public +-// domain sources in SUPERCOP: http://bench.cr.yp.to/supercop.html +- +-// func salsa2020XORKeyStream(out, in *byte, n uint64, nonce, key *byte) +-TEXT ·salsa2020XORKeyStream(SB),0,$512-40 +- MOVQ out+0(FP),DI +- MOVQ in+8(FP),SI +- MOVQ n+16(FP),DX +- MOVQ nonce+24(FP),CX +- MOVQ key+32(FP),R8 +- +- MOVQ SP,R11 +- MOVQ $31,R9 +- NOTQ R9 +- ANDQ R9,SP +- ADDQ $32,SP +- +- MOVQ R11,352(SP) +- MOVQ R12,360(SP) +- MOVQ R13,368(SP) +- MOVQ R14,376(SP) +- MOVQ R15,384(SP) +- MOVQ BX,392(SP) +- MOVQ BP,400(SP) +- MOVQ DX,R9 +- MOVQ CX,DX +- MOVQ R8,R10 +- CMPQ R9,$0 +- JBE DONE +- START: +- MOVL 20(R10),CX +- MOVL 0(R10),R8 +-
Re: golang-go.crypto / CVE-2019-11841
Utkarsh Gupta writes: > On Mon, Oct 5, 2020 at 3:03 AM Brian May wrote: >> I also had a look at CVE-2020-9283 (no DSA) - an invalid public key can >> cause a panic - however I feel this is not really a security issue. > > But still, in case you can include a fix for this in this upload, > that'd be great! I wasn't sure it was going to be worth it? $ patch --dry-run -p1 < ../CVE-2020-9283.patch checking file ssh/keys.go Hunk #1 succeeded at 494 with fuzz 1 (offset -68 lines). Hunk #2 FAILED at 584. Hunk #3 FAILED at 840. Hunk #4 succeeded at 807 with fuzz 2 (offset -57 lines). Hunk #5 FAILED at 903. Hunk #6 FAILED at 1056. Hunk #7 FAILED at 1309. 5 out of 7 hunks FAILED Looking at this again, it looks like it should be trivial to apply #2, #5, and #6 manually. Not sure why these didn't apply automatically. Which just leaves #3 - may not be required - and #7 - which only patches a comment. -- Brian May
Re: golang-go.crypto / CVE-2019-11841
Attached is my patch for golang-go.crypto which I intend to upload tomorrow for: * CVE-2019-11840 * CVE-2019-11841 I also had a look at CVE-2020-9283 (no DSA) - an invalid public key can cause a panic - however I feel this is not really a security issue. -- Brian May diff -Nru golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog --- golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog 2017-04-26 17:42:23.0 +1000 +++ golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog 2020-09-07 08:29:03.0 +1000 @@ -1,3 +1,11 @@ +golang-go.crypto (1:0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782-1+deb8u1) jessie-security; urgency=medium + + * Non-maintainer upload by the LTS Security Team. + * Fix CVE-2019-11841: reject potentially misleading headers and messages. + * Fix CVE-2019-11840: fix keystream loop in amd64 assembly when overflowing 32-bit counter. + + -- Brian May Mon, 07 Sep 2020 08:29:03 +1000 + golang-go.crypto (1:0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782-1) unstable; urgency=medium * Reverts previous upload to permit freeze exception. diff -Nru golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/patches/CVE-2019-11840.patch golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/patches/CVE-2019-11840.patch --- golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/patches/CVE-2019-11840.patch 1970-01-01 10:00:00.0 +1000 +++ golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/patches/CVE-2019-11840.patch 2020-09-07 08:29:03.0 +1000 @@ -0,0 +1,1922 @@ +commit b7391e95e576cacdcdd422573063bc057239113d +Author: Filippo Valsorda +Date: Tue Mar 19 18:29:04 2019 -0400 + +salsa20/salsa: fix keystream loop in amd64 assembly when overflowing 32-bit counter + +Fixes golang/go#30965 + +Change-Id: I83a804d555c048e0124c35f95c9e611b2c5bdb01 +Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/436856 +Reviewed-by: Adam Langley +Reviewed-on: https://go-review.googlesource.com/c/crypto/+/168406 +Reviewed-by: Filippo Valsorda +Run-TryBot: Filippo Valsorda +TryBot-Result: Gobot Gobot + +Index: golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/salsa20/salsa/salsa20_amd64.go +=== +--- golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782.orig/salsa20/salsa/salsa20_amd64.go golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/salsa20/salsa/salsa20_amd64.go +@@ -6,10 +6,9 @@ + + package salsa + +-// This function is implemented in salsa2020_amd64.s. +- + //go:noescape + ++// salsa2020XORKeyStream is implemented in salsa20_amd64.s. + func salsa2020XORKeyStream(out, in *byte, n uint64, nonce, key *byte) + + // XORKeyStream crypts bytes from in to out using the given key and counters. +Index: golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/salsa20/salsa/salsa2020_amd64.s +=== +--- golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782.orig/salsa20/salsa/salsa2020_amd64.s /dev/null +@@ -1,902 +0,0 @@ +-// Copyright 2012 The Go Authors. All rights reserved. +-// Use of this source code is governed by a BSD-style +-// license that can be found in the LICENSE file. +- +-// +build amd64,!appengine,!gccgo +- +-// This code was translated into a form compatible with 6a from the public +-// domain sources in SUPERCOP: http://bench.cr.yp.to/supercop.html +- +-// func salsa2020XORKeyStream(out, in *byte, n uint64, nonce, key *byte) +-TEXT ·salsa2020XORKeyStream(SB),0,$512-40 +- MOVQ out+0(FP),DI +- MOVQ in+8(FP),SI +- MOVQ n+16(FP),DX +- MOVQ nonce+24(FP),CX +- MOVQ key+32(FP),R8 +- +- MOVQ SP,R11 +- MOVQ $31,R9 +- NOTQ R9 +- ANDQ R9,SP +- ADDQ $32,SP +- +- MOVQ R11,352(SP) +- MOVQ R12,360(SP) +- MOVQ R13,368(SP) +- MOVQ R14,376(SP) +- MOVQ R15,384(SP) +- MOVQ BX,392(SP) +- MOVQ BP,400(SP) +- MOVQ DX,R9 +- MOVQ CX,DX +- MOVQ R8,R10 +- CMPQ R9,$0 +- JBE DONE +- START: +- MOVL 20(R10),CX +- MOVL 0(R10),R8 +- MOVL 0(DX),AX +- MOVL 16(R10),R11 +- MOVL CX,0(SP) +- MOVL R8, 4 (SP) +- MOVL AX, 8 (SP) +- MOVL R11, 12 (SP) +- MOVL 8(DX),CX +- MOVL 24(R10),R8 +- MOVL 4(R10),AX +- MOVL 4(DX),R11 +- MOVL CX,16(SP) +- MOVL R8, 20 (SP) +- MOVL AX, 24 (SP) +- MOVL R11, 28 (SP) +- MOVL 12(DX),CX +- MOVL 12(R10),DX +- MOVL 28(R10),R8 +- MOVL 8(R10),AX +- MOVL DX,32(SP) +- MOVL CX, 36 (SP) +- MOVL R8, 40 (SP) +- MOVL AX, 44 (SP) +- MOVQ $1634760805,DX +- MOVQ $857760878,CX +- MOVQ $2036477234,R8 +- MOVQ $1797285236,AX +- MOVL DX,48(SP
Re: golang-go.crypto / CVE-2019-11841
Ola Lundqvist writes: > Looking at the code and your email I have some concerns. > > Isn't the header part of the "signed" argument? If it is not, then there is > no point of checking it since you can then just change the header anyway. > If it is part of the signed message it is possible for the function to > decode it and check it. > > Do the calling application need to do the check, can't > CheckDetachedSignature do it? > > Or have I missed something? CheckDetachedSignature is called like: openpgp.CheckDetachedSignature(keyring, bytes.NewBuffer(b.Bytes), b.ArmoredSignature.Body) b.Headers has the header we need to check, but we only pass the body b.Bytes and the signature b.ArmoredSignature.Body. As in the headers aren't covered by the signature (I assume there is a good reason...). Does this make sense now? -- Brian May
Re: golang-go.crypto / CVE-2019-11841
Ola Lundqvist writes: > Do we have an idea on how a good patch would look like? OK, I think a patch may not be as simple as I hoped. CheckDetachedSignature() is where we decode the packet and determine the hash function used. But this function is not supplied the headers so it cannot check the headers. And this function doesn't return the hashFunc used either, so the calling function cannot check the headers. Plus the hashFunc is an integer it needs to be decoded into a string - there is a private function - nameOfHash - that does this. So some sort of API change is required I think. I am a bit disappointed actually that the CheckDetachedSignature() doesn't return the hash used. It means that the calling application only has access to the insecure value that cannot be trusted. -- Brian May
golang-1.7 / CVE-2019-9514 / CVE-2019-9512
Looking at: https://security-tracker.debian.org/tracker/CVE-2019-9512 https://security-tracker.debian.org/tracker/CVE-2019-9514 Under "golang-1.7" release stretch it says "vulnerable". But in the notes, there is: [stretch] - golang-1.7 (Minor issue) Why? Anyway, as this was marked as minor for golang-1.7 in Stretch, probably also should be marked as minor for golang-golang-x-net-dev also... -- Brian May
Re: golang-go.crypto / CVE-2019-11841
Ola Lundqvist writes: > I agree with you about the hash part (the main part of it) of this CVE. In > fact this CVE is about two different things. If gnupg do hash validation I > think go should do the same. It concerns me that we have marked CVE-2019-11841 as resolved in bullseye and sid, and we have no good procedures for "undoing" a DLA/DSA that marks a CVE as resolved. This is something that has got in the past also. I think it might be possible to update data/DLA/list or data/DSA/list and remove the CVE from the DLA/DSA. Maybe then we would need to update data/CVE/list also (unless this happens automatically). But then we have still have the problem that the last email sent said that the issue was fixed. > I was referring to the second part of the vulnerability described in > "Moreover, since...". Now when I read about it, it is clear that it is only > referring to the PHP header part and not the rest of the text. I wonder if > that should be seen as a separate vulnerability, that people think the > whole text is signed, while it is just a part of it... But that should > probably be on the application layer on top of this library. Yes, it probably should have been two separate CVEs. Having two distinct issues in one CVE gets confusing when only one issue gets resolved. If I understand this correctly, I believe this part was resolved. -- Brian May
Re: golang-go.crypto / CVE-2019-11841
Ola Lundqvist writes: > To completely fix the second part of this CVE I think an API change is > necessary. > The API need to return a list of unsigned and signed portions of the > message so the application using it can make it visible what parts are > signed and what parts are not. > However such a change is large and cannot be done in LTS. I think you might have misunderstood the issue. Thee problem isn't signed vs unsigned parts of a message. The problem is that the Hash header can be altered in transit. gnupg will fail the signature verification if this happens, but golang-go.crypto will not. --- cut --- $ gpg hash_spoof.asc gpg: WARNING: no command supplied. Trying to guess what you mean ... gpg: Signature made Fr 29 Mär 2019 13:00:03 CET gpg: using RSA key 0175949FAEB97005E02272D95D5B3AD9D04EFAEE gpg: WARNING: signature digest conflict in message gpg: Can't check signature: General error --- cut --- I am not sure I understand why upstream is resistant to fixing it actually. All you need to do is get the actual hash used to sign the message, compare it with the Hash header, and reject the message if they are different. > Regarding the security purpose of the hash information I cannot really > judge. I think it serves very little function but I could be wrong. It is not just that the hash header can contain an incorrect hash that is the problem. The hash header could also be changed - with the message in transit - to contain a hidden message - which can appear to be authenticate because it is within the signed part of the message. For example, the following message will pass the golang-go.crypto test (but as above fail the gnupg test). -BEGIN PGP SIGNED MESSAGE- Hash: I need you to wire $100k to 12345566 as soon as possible. Message to be signed -BEGIN PGP SIGNATURE- iQEzBAEBAgAdFiEEAXWUn665cAXgInLZXVs62dBO+u4FAlyeCMMACgkQXVs62dBO +u6WeQgAvOTZAkwtXCZ2woIbHk+g3fgOiCOF8YtXgZCyDYZgR/JIf1+iCh7lWAjq 9/JcnifNB9lX6hyxy4qoT8loLAHNeoUzSkKiliRMcQFhtfCPInRCRtAnKDfkiA5N 0C9CesJYXoASBRafUgxeI7Q29tVdPNC8WVjJtA72yafu4b63TXKdCcu+TCHtH5lV l0rqS1JET/+UGycO+gbvegsAoNhmQp8qkFnJTTS6kJgmCs9TJlAmeX1wT8V5f5L+ 7pRe45ZBmlA7oi4lylvIp+WG1KJVgrPzeQOkybF2rFRuMxjlvqfO1/4lLrtXgA/7 v8H3ZsqUV9T/HNx5bFPOQJjbOhBVRg== =Bb6N -END PGP SIGNATURE- If the hash header was not important, then there would be no need to even include it in the message in the first place. But the fact it is included, and it could confuse programs and/or humans if it is altered. So the value of this header should be validated. -- Brian May
Re: golang-go.crypto / CVE-2019-11841
Attached is my patch for Stretch, based on the upstream patch. I am a bit uneasy about applying this and marking CVE-2019-11841 as fixed, because contrary to what upstream say I don't think CVE-2019-11841 is actually fixed. From the CVE description: [...] However, the Go clearsign package ignores the value of this header, which allows an attacker to spoof it. Consequently, an attacker can lead a victim to believe the signature was generated using a different message digest algorithm than what was actually used. [...] The upstream patch has done nothing to address this. -- Brian May diff -Nru golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog --- golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog 2017-04-26 17:42:23.0 +1000 +++ golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog 2020-09-07 08:29:03.0 +1000 @@ -1,3 +1,10 @@ +golang-go.crypto (1:0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782-1+deb8u1) jessie-security; urgency=medium + + * Non-maintainer upload by the LTS Security Team. + * Fix CVE-2019-11841: reject potentially misleading headers and messages. + + -- Brian May Mon, 07 Sep 2020 08:29:03 +1000 + golang-go.crypto (1:0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782-1) unstable; urgency=medium * Reverts previous upload to permit freeze exception. diff -Nru golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/patches/CVE-2019-11841.patch golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/patches/CVE-2019-11841.patch --- golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/patches/CVE-2019-11841.patch 1970-01-01 10:00:00.0 +1000 +++ golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/patches/CVE-2019-11841.patch 2020-09-07 08:27:22.0 +1000 @@ -0,0 +1,261 @@ +commit 6c9f9a831536511295256d4b4960fc4024ed967c +Author: Filippo Valsorda +Date: Tue Apr 23 15:32:34 2019 -0400 + +openpgp/clearsign: reject potentially misleading headers and messages + +Aida Mynzhasova of SEC Consult Vulnerability Lab reported that the +clearsign package accepts some malformed messages, which can make it +possible for an attacker to trick a human user (but not a Go program) +into thinking unverified text is part of the message. + +For example, if in the following message the vertical tab character is +printed as a new line, a human observer could believe that the +unverified header text is part of the signed message. + +-BEGIN PGP SIGNED MESSAGE- +Hash: SHA1\x0b\x0bThis text is part of the header. + +Hello world! +-BEGIN PGP SIGNATURE- +Version: GnuPG v1.4.10 (GNU/Linux) + +iJwEAQECAAYFAk8kMuEACgkQO9o98PRieSpMsAQAhmY/vwmNpflrPgmfWsYhk5O8 +[...] +MyTpno24AjIAGb+mH1U= +=hIJ6 +-END PGP SIGNATURE- + +The OpenPGP specs are delightfully vague about purpose and validation of +these headers. RFC 4880, Section 7 says + +The cleartext signed message consists of: + +- The cleartext header '-BEGIN PGP SIGNED MESSAGE-' on a +single line, + +- One or more "Hash" Armor Headers, + +- Exactly one empty line not included into the message digest, +[...] + +but also + +If MD5 is the only hash used, then an +implementation MAY omit this header for improved V2.x compatibility. + +and + +If more than one message digest is used in the signature, the "Hash" +armor header contains a comma-delimited list of used message digests. + +which seems to suggest that there can be zero or more Hash headers, each +with one or more algorithms, and no other header types. + +Anyway, it's entirely unclear what security purpose, if any, the Hash +header accomplishes. If the hash is too weak to be secure or +unsupported, the verification will fail. Otherwise, the user shouldn't +care. Given its dubious function, avoid breaking abstractions to check +that it matches the signature, and just document it as unverified. + +As for valid characters, RFC 4880 is silent, except reluctantly +mentioning that the Comment header can be UTF-8, but I am going to +assume that all hash algorithms will have ASCII names, because come on. + +Even more importantly, reject non-Hash SIGNED MESSAGE headers (as opposed +to the SIGNATURE headers), to prevent a "Thank you!" message turning into + +-BEGIN PGP SIGNED MESSAGE- +Reminder: I need you to wire $100k to 12345566 as soon as
Re: golang-go.crypto / CVE-2019-11841
Brian May writes: > Brian May writes: > >> All of the distributions fail (as in the last two tests pass when they >> should now), but bullseye at least fixes one of the failures. So it >> looks like this was incorrectly marked as fixed (note bulleye and sid >> have the same version of this package). > > I filled an upstream bug report: > https://github.com/golang/go/issues/41200 Upstream responded with "That's intentional and documented in the package and in the commit message you link to. The hash header value has no security purposes." I am not convinced this is the case. I have responded. -- Brian May
Re: golang-go.crypto / CVE-2019-11841
Brian May writes: > All of the distributions fail (as in the last two tests pass when they > should now), but bullseye at least fixes one of the failures. So it > looks like this was incorrectly marked as fixed (note bulleye and sid > have the same version of this package). I filled an upstream bug report: https://github.com/golang/go/issues/41200 -- Brian May
Re: golang-go.crypto / CVE-2019-11841
Brian May writes:
> My attempts to run the reproducer program have not been successful, as
> *none* of the signatures validate. Not even the known good case.
I worked it out. The source had:
-BEGIN PGP PUBLIC KEY BLOCK-
mQENBFyeB6MBCAC+X0+7sQkrpg4zjQGj9NQSwPvDV5JjWxIXpf1n+mtrZewO8RvR
But we really need a newline between these two lines.
I created a reproducer for this for various Debian versions using
Docker: https://salsa.debian.org/bam/cve-2019-11841
As per the note in the security tracker:
https://go.googlesource.com/crypto/+/c05e17bb3b2dca130fc919668a96b4bec9eb9442
Patch fixes the second part of the CVE ("prepend arbitrary text")
but not the first ("ignores the value of [the Hash] header"), as hinted at
reporter's 2019-05-09 note:
https://packetstormsecurity.com/files/152840/Go-Cryptography-Libraries-Cleartext-Message-Spoofing.html
When I run my script I get the following output:
=== cut ===
Testing debian:stretch
Sending build context to Docker daemon 78.85kB
Step 1/6 : ARG IMAGE
Step 2/6 : FROM ${IMAGE:-debian:bullseye}
---> 6d935b41319b
Step 3/6 : RUN apt-get update && apt-get install -y golang
golang-golang-x-crypto-dev && rm -rf /var/lib/apt/lists/*
---> Using cache
---> 59138999d865
Step 4/6 : WORKDIR /opt
---> Using cache
---> 0d3cd2502ca0
Step 5/6 : COPY sig_spoof.go .
---> Using cache
---> fca2fb7cdbb9
Step 6/6 : CMD GOPATH=/usr/share/gocode/ go run sig_spoof.go
---> Using cache
---> d1abe6a096eb
Successfully built d1abe6a096eb
Successfully tagged cve-2019-11841:debian_stretch
Verifying not tampered...
Signature accepted!
Verifying spoofed hash...
Signature accepted!
Verifying spoofed cleartext...
Signature accepted!
Testing debian:buster
Sending build context to Docker daemon 78.85kB
Step 1/6 : ARG IMAGE
Step 2/6 : FROM ${IMAGE:-debian:bullseye}
---> ee11c54e6bb7
Step 3/6 : RUN apt-get update && apt-get install -y golang
golang-golang-x-crypto-dev && rm -rf /var/lib/apt/lists/*
---> Using cache
---> 58c133d72716
Step 4/6 : WORKDIR /opt
---> Using cache
---> 4d0b655f72c4
Step 5/6 : COPY sig_spoof.go .
---> Using cache
---> 58ddeb727942
Step 6/6 : CMD GOPATH=/usr/share/gocode/ go run sig_spoof.go
---> Using cache
---> c08127a525a3
Successfully built c08127a525a3
Successfully tagged cve-2019-11841:debian_buster
Verifying not tampered...
Signature accepted!
Verifying spoofed hash...
Signature accepted!
Verifying spoofed cleartext...
Signature accepted!
Testing debian:bullseye
Sending build context to Docker daemon 78.85kB
Step 1/6 : ARG IMAGE
Step 2/6 : FROM ${IMAGE:-debian:bullseye}
---> 0622e5011273
Step 3/6 : RUN apt-get update && apt-get install -y golang
golang-golang-x-crypto-dev && rm -rf /var/lib/apt/lists/*
---> Using cache
---> 62064fd7dc75
Step 4/6 : WORKDIR /opt
---> Using cache
---> 62ad4e1fc354
Step 5/6 : COPY sig_spoof.go .
---> Using cache
---> 57f8ae6b45ef
Step 6/6 : CMD GOPATH=/usr/share/gocode/ go run sig_spoof.go
---> Using cache
---> 7297eba7a4b6
Successfully built 7297eba7a4b6
Successfully tagged cve-2019-11841:debian_bullseye
Verifying not tampered...
Signature accepted!
Verifying spoofed hash...
Signature accepted!
Verifying spoofed cleartext...
No clearsign text found
Done
=== cut ===
All of the distributions fail (as in the last two tests pass when they
should now), but bullseye at least fixes one of the failures. So it
looks like this was incorrectly marked as fixed (note bulleye and sid
have the same version of this package).
--
Brian May
golang-go.crypto / CVE-2019-11841
My attempts to run the reproducer program have not been successful, as *none* of the signatures validate. Not even the known good case. $ GOPATH=/usr/share/gocode/ go run sig_spoof.go Verifying not tampered... openpgp: invalid argument: no armored data found Verifying spoofed hash... openpgp: invalid argument: no armored data found Verifying spoofed cleartext... No clearsign text found I tried this on Debian stretch, buster, bullseye, and using the version of package downloaded using "go get golang.org/x/crypto/openpgp/clearsign" on bullseye (this doesn't work on stretch or buster due to certificate errors). I was wondering if there was an error in my copy of sig_spoof. I downloaded the source using: https://dl.packetstormsecurity.net/1905-exploits/SA-20190513-0.txt And deleted everything before and after the code, so I think it should be OK. Any ideas? -- Brian May https://linuxpenguins.xyz/brian/
Re: slirp / CVE-2020-7039 / CVE-2020-8608
Roberto C. Sánchez writes:
> On Wed, Aug 12, 2020 at 08:55:43AM +1000, Brian May wrote:
>> I am seriously thinking that slirp from unstable should be ported as is
>> from sid to buster and stretch. This is not a new upstream version, it
>> has bug fixes and security updates only. Probably the same changes I
>> would have to make myself in fact. Such as replacing sprintf calls with
>> snprintf calls for example.
>>
>> This would fix CVE-2020-7039 and provide the prerequisite to fixing
>> CVE-2020-8608.
>>
>> Only thing, I am not sure what to do with the versioning:
>>
>> stretch 1:1.0.17-8
>> buster 1:1.0.17-8
>> sid 1:1.0.17-10
>>
>> In fact, because stretch and buster has the same version, does this mean
>> I can't make any security uploads to stretch?
>>
>> On the other hand the security team has marked both these as no-DSA, in
>> buster meaning maybe I should do the same thing too?
>
> I would ask the Security Team if they are open to considering taking
> 1:1.0.17-10 into buster. The version would be 1:1.0.17-10~deb10u1. If
> they agree, then you could subsequently upload to stretch with version
> 1:1.0.17-10~deb9u1. If they are not open to considering it, then it
> seems that the only viable course of action is the mark them no-dsa.
I think perhaps the appropriate course of action would be to fix it in
sid, then back port to the other distributions.
But fixing sid requires fixing #778124 first. OK, that is a simple fix,
but surprised this ever worked.
Attached is my WIP patch. It doesn't quite compile just yet, because it
refers to functions like g_critical, g_error and g_strerror which will
probably need to be replaced by something else. It also doesn't yet fix
the IDENT service.
I also notice a number of untouched calls to "sprintf" which make me
nervous, and perhaps every call to "snprintf" should be replaced with a
call to slirp_fmt0 (because snprintf doesn't guarantee the result will
be null terminated). Including the IDENT service, which the patch
changes, but the code is a bit different, so not easy to apply as is.
No point doing an incomplete fix I think.
I suspect every instance of sprintf and snprintf needs to be replaced
with the slirp_fmt0 call. Existing sprintf calls will also need an extra
argument.
Maybe a better approach would be to switch to the latest upstream
version and use that everywhere?
--
Brian May
diff -Nru slirp-1.0.17/debian/changelog slirp-1.0.17/debian/changelog
--- slirp-1.0.17/debian/changelog 2020-01-25 06:12:54.0 +1100
+++ slirp-1.0.17/debian/changelog 2020-08-13 09:04:48.0 +1000
@@ -1,3 +1,11 @@
+slirp (1:1.0.17-10.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBS by deduplicating symbols (Closes: #778124).
+ * Fix for CVE-2020-8608.
+
+ -- Brian May Thu, 13 Aug 2020 09:04:48 +1000
+
slirp (1:1.0.17-10) unstable; urgency=high
* Fix for CVE-2020-7039 (Closes: #949085)
diff -Nru slirp-1.0.17/debian/patches/015_fix_duplicate_definitions.patch slirp-1.0.17/debian/patches/015_fix_duplicate_definitions.patch
--- slirp-1.0.17/debian/patches/015_fix_duplicate_definitions.patch 1970-01-01 10:00:00.0 +1000
+++ slirp-1.0.17/debian/patches/015_fix_duplicate_definitions.patch 2020-08-13 08:16:48.0 +1000
@@ -0,0 +1,23 @@
+--- a/src/options.c
b/src/options.c
+@@ -74,10 +74,6 @@
+ * Read the config file
+ */
+
+-int (*lprint_print) _P((void *, const char *format, va_list));
+-char *lprint_ptr, *lprint_ptr2, **lprint_arg;
+-struct sbuf *lprint_sb;
+-
+ int cfg_unit;
+ int ctl_password_ok;
+ char *ctl_password;
+--- a/src/misc.c
b/src/misc.c
+@@ -593,6 +593,7 @@
+
+ int (*lprint_print) _P((void *, const char *, va_list));
+ char *lprint_ptr, *lprint_ptr2, **lprint_arg;
++struct sbuf *lprint_sb;
+
+ void
+ #ifdef __STDC__
diff -Nru slirp-1.0.17/debian/patches/CVE-2020-8608.patch slirp-1.0.17/debian/patches/CVE-2020-8608.patch
--- slirp-1.0.17/debian/patches/CVE-2020-8608.patch 1970-01-01 10:00:00.0 +1000
+++ slirp-1.0.17/debian/patches/CVE-2020-8608.patch 2020-08-13 08:42:37.0 +1000
@@ -0,0 +1,133 @@
+--- a/src/tcp_subr.c
b/src/tcp_subr.c
+@@ -1015,7 +1015,7 @@
+ n4 = (laddr & 0xff);
+
+ m->m_len = bptr - m->m_data; /* Adjust length */
+- m->m_len += snprintf(bptr, M_FREEROOM(m), "ORT %d,%d,%d,%d,%d,%d\r\n%s",
++ m->m_len += slirp_fmt(bptr, M_FREEROOM(m), "ORT %d,%d,%d,%d,%d,%d\r\n%s",
+ n1, n2, n3, n4, n5, n6, x==7?buff:"");
+ return 1;
+ } else if ((bptr = (char *)strstr(m->m_data, "27 Entering")) != NULL) {
+@@ -1046,7 +1046,7 @@
+ n4 = (laddr & 0xff);
+
+ m->m_len = bptr - m->m_data; /* Adjust length */
+- m->m_len += snprintf(bptr, M_FREEROOM(m),
++ m->m_len += slirp_fmt(bptr, M_FREEROO
slirp / CVE-2020-7039 / CVE-2020-8608
I am seriously thinking that slirp from unstable should be ported as is from sid to buster and stretch. This is not a new upstream version, it has bug fixes and security updates only. Probably the same changes I would have to make myself in fact. Such as replacing sprintf calls with snprintf calls for example. This would fix CVE-2020-7039 and provide the prerequisite to fixing CVE-2020-8608. Only thing, I am not sure what to do with the versioning: stretch 1:1.0.17-8 buster 1:1.0.17-8 sid 1:1.0.17-10 In fact, because stretch and buster has the same version, does this mean I can't make any security uploads to stretch? On the other hand the security team has marked both these as no-DSA, in buster meaning maybe I should do the same thing too? -- Brian May https://linuxpenguins.xyz/brian/
[SECURITY] [DLA 2284-1] ksh security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - - Debian LTS Advisory DLA-2284-1debian-...@lists.debian.org https://www.debian.org/lts/security/Brian May July 21, 2020 https://wiki.debian.org/LTS - - Package: ksh Version: 93u+20120801-3.1+deb9u1 CVE ID : CVE-2019-14868 A flaw was found in the way it evaluates certain environment variables. An attacker could use this flaw to override or bypass environment restrictions to execute shell commands. Services and applications that allow remote unauthenticated attackers to provide one of those environment variables could allow them to exploit this issue remotely. For Debian 9 stretch, this problem has been fixed in version 93u+20120801-3.1+deb9u1. We recommend that you upgrade your ksh packages. For the detailed security status of ksh please refer to its security tracker page at: https://security-tracker.debian.org/tracker/ksh Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKpwfR8DOwu5vyB4TKpJZkldkSvoFAl8WDUAACgkQKpJZkldk SvrGmQ//eQV7NZ5AnTL20mZkw1A7ow/kLpnZL4zMycYs40WdpC97r7eOYXGaUhhv DMl/oQryJ5YLA2DgvrfupsIacvIhXKYoy82uMQS+C+GefIqNE4JmqMDkvuFy+9EG /8yVaHVz0VkNrDZPTWvvPb16hhmlI2Ugnpn8sfbNb7T3cRS8X2K+cosQhiOtpz70 LikFfRw6HoFzYXmPD2iNdb/iWVA+Ph6t7ijyDfoiGtZXdSCyi9nbd+noPa0uicoZ 964kh2up5sAtH0Aq9ZIwUK2NuTCyf97Q879UyrB08b2vheO/r1v0IDeAU9nNfOWl +wFoF8j5cLWaRwpIazi1LJi+rtfhmYlw2hVuKIATlQSGqHFVq4jbpcrrNjlxjeQT cxLtpqcwTiHm4BrO4tKiUiEUixHYV1OH9TO+G99zXOK5poQgyN6w7z9V1/qxhNoZ Q+tM+MtiEO4REYJRtbat5VKMY5gDUMK6bblwlzuGUAnr6irt6O+u9IHeCoae309I np5Mnm++jlKgkt0oG2Rf/9MGqeA6v996UF65TRmpCzaTbuVw2IvSSkTTIionzVfd on0FOSBu30pEEKDza06u3nX+jFy4rxx03NFKWrUNEvkmql4OMnbiCDisn3kq51r4 kqhEEsYlJvlMi18AL72IowWHTd6fud21R76kjFHLY0g82UKJnMY= =9+xc -END PGP SIGNATURE-
Re: ksh / CVE-2019-14868
Attached is my patch to deal with this issue. It is mostly a copy and
paste of the code from the upstream patch, except the following changes
were required (and from the original code):
* The number call has been replaced with a strtonll call.
* The sh_isstate call has been changed to take only one parameter.
* The "Varsubscript = true;" line was removed.
I attempted to get tests working also, but these don't appear to be
getting called in the Debian tests. Instead I ran the tests manually by
hand, and they are produced expected values.
(stretch-i386-default)root@silverfish:/tmp/brian/tmpkaecyd6p/build/i386#
SHLVL='7' ksh -c 'echo $SHLVL'
8
(stretch-i386-default)root@silverfish:/tmp/brian/tmpkaecyd6p/build/i386#
SHLVL='013' ksh -c 'echo $SHLVL'
14
(stretch-i386-default)root@silverfish:/tmp/brian/tmpkaecyd6p/build/i386#
SHLVL='2#11' ksh -c 'echo $SHLVL'
4
(stretch-i386-default)root@silverfish:/tmp/brian/tmpkaecyd6p/build/i386#
SHLVL='16#B' ksh -c 'echo $SHLVL'
12
&2)0]' ksh -c
'echo $SHLVL'
1
diff -Nru ksh-93u+20120801/debian/changelog ksh-93u+20120801/debian/changelog
--- ksh-93u+20120801/debian/changelog 2017-05-31 19:57:56.0 +1000
+++ ksh-93u+20120801/debian/changelog 2020-07-16 07:53:51.0 +1000
@@ -1,3 +1,11 @@
+ksh (93u+20120801-3.1+deb9u1) stretch-security; urgency=high
+
+ * Non-maintainer upload by the LTS Team.
+ * Fix CVE-2019-14868: An attacker could use flaw to override or bypass
+environment restrictions to execute shell commands.
+
+ -- Brian May Thu, 16 Jul 2020 07:53:51 +1000
+
ksh (93u+20120801-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru ksh-93u+20120801/debian/patches/CVE-2019-14868.patch
ksh-93u+20120801/debian/patches/CVE-2019-14868.patch
--- ksh-93u+20120801/debian/patches/CVE-2019-14868.patch1970-01-01
10:00:00.0 +1000
+++ ksh-93u+20120801/debian/patches/CVE-2019-14868.patch2020-07-16
07:53:51.0 +1000
@@ -0,0 +1,83 @@
+--- a/src/cmd/ksh93/sh/arith.c
b/src/cmd/ksh93/sh/arith.c
+@@ -511,23 +511,34 @@
+ Shell_t *shp = sh_getinterp();
+ register Sfdouble_t d;
+ char base=(shp->inarith?0:10), *last;
+- if(*str==0)
+- {
+- if(ptr)
+- *ptr = (char*)str;
+- return(0);
++ if(*str==0) {
++ d = 0.0;
++ last = (char *)str;
++ } else {
++ d = strtonll(str,,,-1);
++ if (*last && !shp->inarith && sh_isstate(SH_INIT)) {
++ // This call is to handle "base#value" literals if
we're importing untrusted env vars.
++ base = 0;
++ d = strtonll(str,,,-1);
++ }
++ if (*last) {
++ if (sh_isstate(SH_INIT)) {
++ // Initializing means importing untrusted env
vars. Since the string does not appear
++ // to be a recognized numeric literal give up.
We can't safely call strval() since
++ // that allows arbitrary expressions which
would create a security vulnerability.
++ d = 0.0;
++ } else {
++ if (*last != '.' || last[1] != '.') {
++ d = strval(shp, str, , arith,
mode);
++ }
++ if (!ptr && *last && mode > 0) {
++ errormsg(SH_DICT, ERROR_exit(1),
e_lexbadchar, *last, str);
++ }
++ }
++ } else if (d == 0.0 && *str == '-') {
++ d = -0.0;
++ }
+ }
+- errno = 0;
+- d = strtonll(str,,,-1);
+- if(*last || errno)
+- {
+- if(!last || *last!='.' || last[1]!='.')
+- d = strval(shp,str,,arith,mode);
+- if(!ptr && *last && mode>0)
+- errormsg(SH_DICT,ERROR_exit(1),e_lexbadchar,*last,str);
+- }
+- else if (!d && *str=='-')
+- d = -0.0;
+ if(ptr)
+ *ptr = last;
+ return(d);
+--- a/src/cmd/ksh93/tests/subshell.sh
b/src/cmd/ksh93/tests/subshell.sh
+@@ -617,4 +617,27 @@
+ fi
+ done
+
++# ==
++# Verify that importing untrusted env vars does not allow evaluating
arbitrary expressions but does
++# recognize all integer literals recognized by ksh.
++expect=8
++actual=$(env SHLVL='7' $SHELL -c 'echo $SHLVL')
++[[ $actual == $expect ]] || err_exit "decimal int literal not recognized"
"$expect" "$actual"
++
++expect=14
++actual=$(env SHLVL='013' $SHELL -c 'echo $SHLVL')
++[[ $actual == $expect ]] || err_exit "leading zeros int literal not
recognized&quo
Re: ksh / CVE-2019-14868
I meant to include this test run:
(stretch-amd64-default)root@silverfish:/home/brian# SHLVL='2#11+x[$(/bin/echo
DANGER WILL ROBINSON >&2)0]' /usr/bin/ksh
Segmentation fault
DANGER WILL ROBINSON
As in no echo command is required.
Below is the full stack trace of the segfault (recompiled without the
strip=0 option).
(stretch-i386-default)root@silverfish:/tmp/brian/tmpf2btue5q/build/i386# ulimit
-c unlimited
(stretch-i386-default)root@silverfish:/tmp/brian/tmpf2btue5q/build/i386#
SHLVL='2#11+x[$(/bin/echo DANGER WILL ROBINSON >&2)0]' /usr/bin/ksh
DANGER WILL ROBINSON
Segmentation fault (core dumped)
(stretch-i386-default)root@silverfish:/tmp/brian/tmpf2btue5q/build/i386# ls core
core
(stretch-i386-default)root@silverfish:/tmp/brian/tmpf2btue5q/build/i386# gdb
/usr/bin/ksh core
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/ksh...Reading symbols from
/usr/lib/debug/.build-id/5f/77fa7b40ec10980eebf65a2ba1cebac53d8894.debug...done.
done.
warning: core file may not match specified executable file.
[New LWP 15788]
Core was generated by `/usr/bin/ksh'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 job_alloc () at ./src/cmd/ksh93/sh/jobs.c:1871
1871./src/cmd/ksh93/sh/jobs.c: No such file or directory.
(gdb) bt
#0 job_alloc () at ./src/cmd/ksh93/sh/jobs.c:1871
#1 job_post (shp=0x56772fa0 , pid=15789, join=) at
./src/cmd/ksh93/sh/jobs.c:1353
#2 0x5663b25a in _sh_fork (shp=0x56772fa0 , parent=15789, flags=0,
jobid=0xffa15798) at ./src/cmd/ksh93/sh/xec.c:3142
#3 0x5663bcc2 in sh_ntfork (shp=shp@entry=0x56772fa0 , argv=0xf7caf334,
jobid=0xffa15798, flag=, t=, t=)
at ./src/cmd/ksh93/sh/xec.c:4034
#4 0x56640ed7 in sh_exec (t=, flags=) at
./src/cmd/ksh93/sh/xec.c:1686
#5 0x56638291 in sh_subshell (shp=0x56772fa0 , t=0xf7caf298,
flags=, comsub=1) at ./src/cmd/ksh93/sh/subshell.c:625
#6 0x56619654 in comsubst (mp=0xf7cb1880, t=, t@entry=0x0,
type=type@entry=1) at ./src/cmd/ksh93/sh/macro.c:2135
#7 0x56615af7 in varsub (mp=mp@entry=0xf7cb1880) at
./src/cmd/ksh93/sh/macro.c:1168
#8 0x56618d14 in copyto (mp=mp@entry=0xf7cb1880, endch=endch@entry=0,
newquote=) at ./src/cmd/ksh93/sh/macro.c:633
#9 0x56619108 in sh_mactrim (shp=0x56772fa0 , str=0xf7cb1034 "[$(/bin/echo
DANGER WILL ROBINSON >&2)0]", mode=0) at ./src/cmd/ksh93/sh/macro.c:183
#10 0x565ef8d7 in scope (np=0xf7cbb390, lvalue=lvalue@entry=0xffa16598,
assign=assign@entry=0) at ./src/cmd/ksh93/sh/arith.c:161
#11 0x565f0288 in arith (ptr=0xffa16594, lvalue=0xffa16598, type=2,
n=) at ./src/cmd/ksh93/sh/arith.c:444
#12 0x56634bd2 in arith_exec (ep=0xf7caf248) at ./src/cmd/ksh93/sh/streval.c:249
#13 0x56636441 in strval (shp=0x56772fa0 , s=0xf7cb102e "2#11+x[$(/bin/echo
DANGER WILL ROBINSON >&2)0]", end=0xffa16778, conv=0x565eff40 , emode=1)
at ./src/cmd/ksh93/sh/streval.c:964
#14 0x565ef560 in sh_strnum (str=0xf7cb102e "2#11+x[$(/bin/echo DANGER WILL
ROBINSON >&2)0]", ptr=0x0, mode=1) at ./src/cmd/ksh93/sh/arith.c:525
#15 0x565f0e70 in sh_arith (shp=0x56772fa0 , str=0xf7cb102e
"2#11+x[$(/bin/echo DANGER WILL ROBINSON >&2)0]") at
./src/cmd/ksh93/sh/arith.c:538
#16 0x5661d0ae in nv_putval (np=0xf7cb0bf4, string=0xf7cb102e
"2#11+x[$(/bin/echo DANGER WILL ROBINSON >&2)0]", flags=0) at
./src/cmd/ksh93/sh/name.c:1783
#17 0x566015ed in env_init (shp=0x56772fa0 ) at
./src/cmd/ksh93/sh/init.c:2036
#18 sh_init (argc=1, argv=0xffa18a74, userinit=0x0) at
./src/cmd/ksh93/sh/init.c:1380
#19 0x565e4da6 in sh_main ()
#20 0x565e4af9 in main (argc=1, argv=0xffa18a74) at
./src/cmd/ksh93/sh/pmain.c:45
I am guessing this segfault might be because we are attempting to access
job.freejobs[x] before job.freejobs has been initialised because we
weren't expecting to run jobs yet.
Yes, this appears to be the case:
/*
* initialize the shell
*/
Shell_t *sh_init(register int argc,register char *argv[], Shinit_f userinit)
{
[...]
env_init(shp); /* function that causes the error */
[...]
/* initialize jobs table */
job_clear();
[...]
}
--
Brian May
Re: ksh / CVE-2019-14868
Ola Lundqvist writes: > Interesting. I wonder how I concluded that it was just arithmetic > expressions. Do you want me to re-check it? Yes please, might be a good idea. > Segmentation faults can be problematic too, but it looks like we have > some protection against this CVE already. The question is whether the > subshell is actually executed before the sigsegv. According to strace, does appear to be the case. I just noticed when I try to run this inside gdb it works fine: (stretch-amd64-default)root@silverfish:/home/brian# SHLVL='2#11+x[$(/bin/echo DANGER WILL ROBINSON >&2)0]' gdb /usr/bin/ksh GNU gdb (Debian 7.12-6) 7.12.0.20161007-git Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/bin/ksh...(no debugging symbols found)...done. (gdb) show environment SHLVL SHLVL = 2#11+x[$(/bin/echo DANGER WILL ROBINSON >&2)0] (gdb) r Starting program: /usr/bin/ksh # echo $SHLVL 1 # [Inferior 1 (process 16002) exited normally] (gdb) q Tried again with a core file, but looks like I will need to recompile with debugging symbols: (stretch-amd64-default)root@silverfish:/home/brian# gdb /usr/bin/ksh core GNU gdb (Debian 7.12-6) 7.12.0.20161007-git Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/bin/ksh...(no debugging symbols found)...done. warning: core file may not match specified executable file. [New LWP 16516] Core was generated by `/usr/bin/ksh'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x55db50ac8501 in ?? () (gdb) bt #0 0x55db50ac8501 in ?? () #1 0x55db50af5b11 in ?? () #2 0x55db50af645f in ?? () #3 0x55db50afae8f in ?? () #4 0x55db50af2c1f in ?? () #5 0x55db50ad5577 in ?? () #6 0x55db50ad2316 in ?? () #7 0x55db50ad4c8e in ?? () #8 0x55db50ad5000 in ?? () #9 0x55db50aadb15 in ?? () #10 0x55db50aae3a4 in ?? () #11 0x55db50aefd24 in ?? () #12 0x55db50af106c in ?? () #13 0x55db50aad792 in ?? () #14 0x55db50ad9294 in ?? () #15 0x55db50abec72 in ?? () #16 0x55db50aa38dd in ?? () #17 0x00007f2658ae42e1 in __libc_start_main (main=0x55db50aa3650, argc=1, argv=0x7ffe505157a8, init=, fini=, rtld_fini=, stack_end=0x7ffe50515798) at ../csu/libc-start.c:291 #18 0x55db50aa368a in ?? () -- Brian May
Re: ksh / CVE-2019-14868
NE) = 0
mmap(0x7f2ccedbd000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x195000) = 0x7f2ccedbd000
mmap(0x7f2ccedc3000, 14688, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2ccedc3000
close(3)= 0
arch_prctl(ARCH_SET_FS, 0x7f2ccefe5480) = 0
mprotect(0x7f2ccedbd000, 16384, PROT_READ) = 0
mprotect(0x5633d68d1000, 4096, PROT_READ) = 0
mprotect(0x7f2ccefea000, 4096, PROT_READ) = 0
munmap(0x7f2ccefe6000, 15058) = 0
brk(NULL) = 0x5633d6b5c000
brk(0x5633d6b7d000) = 0x5633d6b7d000
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
write(1, "DANGER WILL ROBINSON\n", 21DANGER WILL ROBINSON
) = 21
close(1)= 0
close(2)= 0
exit_group(0) = ?
+++ exited with 0 +++
Segmentation fault
--
Brian May
Re: DLA template and user signatures
Sylvain Beucler writes: > On 07/07/2020 12:01, Emilio Pozuelo Monfort wrote: >> - it was brought up that some DLAs include personal signatures at the end > > In what context did you receive this feedback? I have found that I have to delete any personal signatures or the GPG check will fail, and the email will (silently) never get published. -- Brian May
ksh / CVE-2019-14868
Is dla-needed.txt for Jessie or Stretch now? ksh was removed from dla-needed.txt for Stretch and classified "minor": https://salsa.debian.org/security-tracker-team/security-tracker/commit/87322fcf Then it was added again: https://salsa.debian.org/security-tracker-team/security-tracker/commit/59a9cd9dca3afc830fea869d12baf2f3d7c21126 Should we mark it as ignored in Stretch also? Or maybe the reason (as given in the commit message when ksh was first removed) was wrong? https://salsa.debian.org/security-tracker-team/security-tracker/commit/b72cc677e719d37f5f3378d616d9cb53315db927 -- Brian May
Re: jquery / CVE-2020-7656
Ola Lundqvist writes: > I think the risk of breaking things is quite significant. At least > that is my experience from updating jquery for various applications. > > I guess we should then mark it as ignored, with some motivation around > that. Done. https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/2e566eb8abcb548cf7020f18e4dce28aabfc5265 -- Brian May
[SECURITY] [DLA 2250-1] drupal7 security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: drupal7 Version: 7.32-1+deb8u18 CVE ID : CVE-2020-13662 Drupal 7 has an Open Redirect vulnerability. For example, a user could be tricked into visiting a specially crafted link which would redirect them to an arbitrary external URL. For Debian 8 "Jessie", this problem has been fixed in version 7.32-1+deb8u18. We recommend that you upgrade your drupal7 packages. Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKpwfR8DOwu5vyB4TKpJZkldkSvoFAl7qi94ACgkQKpJZkldk SvrKjQ/+IBXS17HhlHsPLkTZbDyh7IRb+sufUDaawZAWhnh5yRKK3HkYqEb5rCqN KRTCS8OZv1vbxUQps9Yo49ff3gwzQZnUyGodrH0hzzPjqMKoYExwDs+9KHze2dZ8 PO0tW9JBuSqlOS3CCUQupfUKP5zWRMoUE02BVQX/kgECZ+lHmpu9QQMvOF03rKjJ 4/QrF1v/hSWqVrBDsCoNgm3QvpgMi/NN5juCv+ojXb0BvHLo0RDSivQXshEnd7fw /fLwhlt9ARPxW/qVIVaEFxlWYVfmVddqY5YZoAzNc3UwF8fJvH4DB/jFI0/lP+jd kHn+kDE+Kj9biYPUOFYXjTjL03OTIp5rjYoihIcGPMxp9NLTyZgCFGTPuyl2AmWN qmAfbz1e+wB9uLAu2gfRwAhenN4mZvoVJLP7Jm1Q/XF0sis9gLeBl/vgqR2Xp+C/ bqm0rNdQHGn2898kB+PNCxhWI6ShU/pIxGLKbBrIWSUeX0wMrDmPKoVj4BXFDldF p9GxCk3z1FYMILOwg49HGi1k7UyhaLLQGCm4JXCuc2hxJ/mILSlo2g8t8MvwwuV3 dbqTgo+Op+jXDd6rOXGP4yyvrLbRk4LOFJFpayTas7mZRZXwqLrFLTsTm04DUHA/ cfRvw8CETO4JQeclj9wlEZHslXITckuwpzq6rV3MSAqyNogiab0= =ZaHf -END PGP SIGNATURE-
Re: unbound not supported
Holger Levsen writes: > for d-s-s in jessie i'm still unsure, which version number to use > (see https://lists.debian.org/debian-release/2020/06/msg00136.html > for a summary of the problem). allocating and issuing the DLA will > be easy once I'm clear about that version number... I have wondered if it even makes sense list of supported packages (which is somewhat dynamic) in a package in the distribution itself (which is suppose to be relatively stable and - apart from exceptions such as security updates - follow a strict order of unstable -> testing -> stable -> oldstable). Plus after the distribution is no longer supported, I imagine the d-s-s file in that distribution is no longer valid and should not be used (unless we update it at the time the distribution stops being supported). Wouldn't it be better to have, maybe a wiki page somewhere that lists unsupported packages? -- Brian May
Re: drupal7
Brian May writes:
> Drupal7, in Jessie has 3 security issues:
My proposed changes to drupal7 in Jessie:
diff -Nru drupal7-7.32/debian/changelog drupal7-7.32/debian/changelog
--- drupal7-7.32/debian/changelog 2019-05-20 20:05:42.0 +1000
+++ drupal7-7.32/debian/changelog 2020-06-15 07:30:19.0 +1000
@@ -1,3 +1,9 @@
+drupal7 (7.32-1+deb8u18) jessie-security; urgency=medium
+
+ * Fix CVE-2020-13662 / SA-CORE-2020-003: Fix Open Redirect vulnerability.
+
+ -- Brian May Mon, 15 Jun 2020 07:30:19 +1000
+
drupal7 (7.32-1+deb8u17) jessie-security; urgency=medium
* Non-maintainer upload by the LTS Security Team.
diff -Nru drupal7-7.32/debian/patches/CVE-2020-13662.patch
drupal7-7.32/debian/patches/CVE-2020-13662.patch
--- drupal7-7.32/debian/patches/CVE-2020-13662.patch1970-01-01
10:00:00.0 +1000
+++ drupal7-7.32/debian/patches/CVE-2020-13662.patch2020-06-15
07:30:19.0 +1000
@@ -0,0 +1,14 @@
+--- a/includes/common.inc
b/includes/common.inc
+@@ -684,7 +684,10 @@
+ // We do not allow absolute URLs to be passed via $_GET, as this can be an
attack vector.
+ if (isset($_GET['destination']) && !url_is_external($_GET['destination'])) {
+ $destination = drupal_parse_url($_GET['destination']);
+-$path = $destination['path'];
++// Double check the path derived by drupal_parse_url() is not external.
++if (!url_is_external($destination['path'])) {
++ $path = $destination['path'];
++}
+ $options['query'] = $destination['query'];
+ $options['fragment'] = $destination['fragment'];
+ }
diff -Nru drupal7-7.32/debian/patches/series drupal7-7.32/debian/patches/series
--- drupal7-7.32/debian/patches/series 2019-05-20 20:05:42.0 +1000
+++ drupal7-7.32/debian/patches/series 2020-06-15 07:24:44.0 +1000
@@ -25,3 +25,4 @@
SA-CORE-2019-004
SA-CORE-2019-006
SA-CORE-2019-007
+CVE-2020-13662.patch
--
Brian May
drupal7
Drupal7, in Jessie has 3 security issues:
CVE-2020-11022 / CVE-2020-11023 / SA-CORE-2020-002
Vulnerabilities in jquery library.
The Debian drupal7 package comes with jquery 1.4.4
(debian/missing-sources/jquery-1.4.4.js).
7.27+dfsg-1 the maintainer attempted to use the libjs-jquery
package instead.
7.27+dfsg2-1 - the next release - the above change was reverted due to
"heavy breakage", with a reference to https://bugs.debian.org/699286
which says "Turns out, they have a hard dependency on the 1.4.4
version."
The upstream patch is invasive:
https://github.com/jquery/jquery/commit/1d61fd9407e6fbe82fe55cb0b938307aa0791f77
Plus has the commit "There is no patch for 1.x or 2.x, they are no
longer supported and in any case this is a pretty big breaking change,
likely even more so on the browsers supported by those versions.
Patching this would almost surely cause a cascade of failures in code
and plugins that you would need to address."
As such, I am reluctant to want to try to patch the query issues.
CVE-2020-13662 / SA-CORE-2020-003
The upstream patch
(https://git.drupalcode.org/project/drupal/-/commit/905ff00a44160adee3f266cdcc87d3350a64a072)
is trivial and applies cleanly to the Jessie version.
=== cut ===
--- drupal7-7.32.orig/includes/common.inc
+++ drupal7-7.32/includes/common.inc
@@ -684,7 +684,10 @@
// We do not allow absolute URLs to be passed via $_GET, as this can be an
attack vector.
if (isset($_GET['destination']) && !url_is_external($_GET['destination'])) {
$destination = drupal_parse_url($_GET['destination']);
-$path = $destination['path'];
+// Double check the path derived by drupal_parse_url() is not external.
+if (!url_is_external($destination['path'])) {
+ $path = $destination['path'];
+}
$options['query'] = $destination['query'];
$options['fragment'] = $destination['fragment'];
}
=== cut ===
As such, I am inclined to patch the CVE-2020-13662 / SA-CORE-2020-003
issue, but not touch the jquery issue.
Comments?
--
Brian May
https://linuxpenguins.xyz/brian/
Re: unbound not supported
Brian May writes: > I sent a email to Moritz Muehlenhoff, asking why is changed it to > unsupported, but not got a response yet. Response was that upstream support has ended the old version unbound, and it was deemed to risky too backport changes from supported versions to the old version. -- Brian May
Re: jquery / CVE-2020-7656
Brian May writes: > But... surprise surprise, it looks like buildFragment may be broken: It looks like this commit might fix that: https://github.com/jquery/jquery/commit/22ad8723ce07569a9b039c7901f29e86ad14523c But this is a rather invasive commit. Don't think we should apply it to Jessie. I believe any fix we make to the package in Jessie risks: * Breaking existing applications. * Not fixing the problem entirely. Plus the version in Jessie is likely to have numerous security issues already, not just this one. Looking through some of the git commit logs around this time seems to verify this view that there could be serious issues in such an old version of JQuery. I think it is a matter of: * Leave it. I mean how likely is it that a JavaScript app will conduct load() on an untrusted URL anyway? Particularly with modern browsers with Same-origin policy - I suspect not likely. * Update Jessie to a newer upstream version. Maybe the one in Stretch. Yes, there is the risk this will break stuff. I tend to favour the first option. Mark the issue as nodsa or similar. -- Brian May
Re: jquery / CVE-2020-7656
"Chris Lamb" writes: > You don't seem to address this concern which leaves open the > possibility that you did not see this or I did not communicate it > effectively enough. If the latter, please let me know how I could make my > language clearer. No need to, I think we agree with each other here :-) -- Brian May
Re: unbound not supported
Holger Levsen writes: > On Tue, Jun 09, 2020 at 07:13:03AM +1000, Brian May wrote: >> I notice that according to DSA-4694, unbound is not supported anymore in >> Stretch. >> https://www.debian.org/security/2020/dsa-4694 >> Does this mean we should also mark it as unsupported in Jessie? > > I believe so, yes. > > I'd be happy to add this to debian-security-support and release a DLA > (for d-s-s) to announce it. Shall I? Sounds good to me. I sent a email to Moritz Muehlenhoff, asking why is changed it to unsupported, but not got a response yet. -- Brian May
Re: jquery / CVE-2020-7656
"Chris Lamb" writes:
> I did consider this. However, as I implied last time — and you have
> independently discovered! — Javascript development is very weird with
> lots of edge-cases, and that is before we consider the inconsistencies
> of a higher-level API like jQuery and the underlying DOM APIs etc.
> etc.
should be fine... But we probably should make sure we don't export a new
API method for parseHTML, this could affect client code.
But... surprise surprise, it looks like buildFragment may be broken:
=== code ===
jQuery.buildFragment = function( args, nodes, scripts ) {
var fragment, cacheable, cacheresults, doc,
first = args[ 0 ];
// nodes may contain either an explicit document object,
// a jQuery collection or context object.
// If nodes[0] contains a valid object to assign to doc
if ( nodes && nodes[0] ) {
doc = nodes[0].ownerDocument || nodes[0];
}
// Ensure that an attr object doesn't incorrectly stand in as a
document object
// Chrome and Firefox seem to allow this to occur and will throw
exception
// Fixes #8950
if ( !doc.createDocumentFragment ) {
doc = document;
}
=== code ===
When I test this with the exploit, this fails, because the first if
statement fails, and hence doc is not assigned a value for the second if
statement.
In typical fashion, it looks like this function is completely different
in master:
https://github.com/jquery/jquery/blob/9c98e4e86eda857ee063bc48adbc1a11bb5506ee/src/manipulation/buildFragment.js
Will investigate further, in case there is a simple fix.
--
Brian May
Re: jquery / CVE-2020-7656
Brian May writes: > rscript = /)<[^<]*)*<\/script>/gi, The simplest possible solution would be to update that regexp to allows white space in the closing tag. But of course the problem here is that a regexp isn't really the right tool for parsing HTML content, and it is very possible this regexp contains other hidden security features. -- Brian May
Re: jquery / CVE-2020-7656
"Chris Lamb" writes: > Brian, > >> Do we only need to filter out javascript if a selector is provided for >> some reason? > > Yes. Javascript development is fun. Oh, I see it in the docs. I don't know how I missed this before. From https://api.jquery.com/load/ "When calling .load() using a URL without a suffixed selector expression, the content is passed to .html() prior to scripts being removed. This executes the script blocks before they are discarded. If .load() is called with a selector expression appended to the URL, however, the scripts are stripped out prior to the DOM being updated, and thus are not executed. An example of both cases can be seen below:" Nothing like consistency in APIs :-( > (As I added in the notes, I do not know how we are meant to cleanly > fix this issue in jessie's version of jQuery.) Have you considered the possibility of back porting the parseHTML function? At quick glance it looks like it should be do-able, but the imports need changing. It looks like the bulk of the work is done by the buildFragment, and the Jessie package does have this function. But in a different file. https://github.com/jquery/jquery/blob/d0ce00cdfa680f1f0c38460bc51ea14079ae8b07/src/core/parseHTML.js -- Brian May
jquery / CVE-2020-7656
This appears to be a vulnerability in that the "load()" function will
not correctly filter out javascript from loaded HTML.
https://snyk.io/vuln/SNYK-JS-JQUERY-569619
As per was supposedly fixed in the following commit:
https://github.com/jquery/jquery/commit/a938d7b1282fc0e5c52502c225ae8f0cef219f0a
NOTE: 20200606: This was fixed upstream in a set of wider changes
NOTE: 20200606: (a938d7b128) which cannot be applied. Even the specific
dlaneeded.txt
The relevant line that has been changed is this one.
https://github.com/jquery/jquery/commit/a938d7b1282fc0e5c52502c225ae8f0cef219f0a#diff-c3749d3acba09ca9ec16bb56e496408bR177
Before (if selector set):
rscript = /)<[^<]*)*<\/script>/gi,
jQuery("")
.append( responseText.replace( rscript, "" ) )
.find( selector ) :
Before (if selector not set):
responseText is used as is.
After (if selector set):
jQuery("").append( jQuery.parseHTML( responseText ) ).find( selector ) :
After (if selector not set):
responseText is used as is.
OK, so for the case where selector is set, we now call parseHTML instead
of replacing the text. Presumable this fixes the problem. But this
function not available in the Jessie version.
But even more importantly, it looks like to me that if selector was not
given, we don't do any filtering of JavaScript if a selector is not
provided. Even in the latest version of master.
https://github.com/jquery/jquery/blob/master/src/ajax/load.js#L58
Does this mean the security bug is not sufficiently fixed? Or do we only
need to filter out javascript if a selector is provided for some reason?
I am also a bit puzzled, I would have expected a function called load()
would load JavaScript, and if you add it to the DOM as per the example,
I would expect it to be executed.
https://snyk.io/vuln/SNYK-JS-JQUERY-569619
--
Brian May
https://linuxpenguins.xyz/brian/
unbound not supported
I notice that according to DSA-4694, unbound is not supported anymore in Stretch. https://www.debian.org/security/2020/dsa-4694 Does this mean we should also mark it as unsupported in Jessie? -- Brian May https://linuxpenguins.xyz/brian/
Re: [RFC] Proposal: Migrate LTS/TODO wiki page to GitLab issues
Roberto C. Sánchez writes: > Rationale: The nature of a wiki makes it suboptimal for managing > discrete work units. As developers, we are all familiar with > interacting with the Debian BTS and other similar systems (e.g., Jira, > GitHub issues, etc.). While the Debian BTS would be a natural first > choice, the best mechanism for grouping related issues that do not > belong to a single package is usertags. However, there is currently not > a way to subscribe to usertags in order to receive notification of new > bugs created with the tag or of existing bugs which have the tag added > to them. How much is this an problem? I imagine it should be possible to create some sort of app that queries the issues with a tag (I assume gitlab has some sort of API for this) and automatically subscribes them. > With that in mind, the creation of a new Salsa project for > grouping and managing these issues is the best choice given available > tooling. Note: it looks like I may not have access to lts-team. I see a "request access" link, which I will click. I mention this here only because it might affect others as well. > Objective: Remove all content from LTS/TODO which can reasonably be > captured in one or more GitLab Salsa issues. Then, from this point > forward manage non-package-specific LTS tasks as issues within the > lts-team/lts-extra-tasks project. > > Please reply with any objections, concerns, comments, or suggestions. This sounds like a good idea to me. Just need to come up with an appropriate list of tags to represent the status. e.g. if a particular TODO item is waiting on response from security team for example. -- Brian May
Re: bluez / CVE-2020-0556
Roberto C. Sánchez writes: > My own conclusion is that a backport of the stretch version of bluez is > the best course. If no objections are raised, then I will proceed with > uploading the backport at the end of this week. Sounds reasonable to me. > I too concluded that something like this would be the closest adaptation > of the upstream fix to the older bluez in jessie. That said, I will > note that the absence of enclosing braces around the two statements in > your 'if' block make the 'return' fall outside the 'if'; the function > will always return early here. Oops. Probably obvious I mostly program in Python... -- Brian May
TODO List
I am finding the TODO list hard to follow, so trying to improve it. Currently it is more like a wish list, as opposed to an actionable list of tasks. Is the "Find upstream developers who are willing to work on LTS support" still relevant? It lists packages such as Xen, which I thought were already dealt with. We probably need to break the TODO list down into actionable tasks. e.g. "Improve the security-tracker to not break salsa" is not an actionable task because nobody in the LTS team knows how to proceed with this. Would this plugin be any use? https://moinmo.in/TaskPlanner - It might allow us to visualise the required tasks in a cleaner manner. Also it occurred to me that Python 2 support is disappearing, but the scripts in security tracker are still Python 3 only (my latest merge requests have been stalled). Not sure if we need to add this to the TODO list or not. -- Brian May https://linuxpenguins.xyz/brian/
Re: bluez / CVE-2020-0556
Brian May writes:
> Looking at commit
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=7d9718cfcc11eaa9d8059e721301cdc00ef8c82e,
> it looks like maybe we should be patching the attio_connected_cb()
> function instead. But this function doesn't appear to have any way to
> return an error indicating it failed, which seems to be required by the
> patch. It might be sufficient just to ignore the error and return
> without immediately if device is not bonded. Not sure how much I can
> trust this however.
>
> My gut feeling to fix this we should backport version 5.43-2+deb9u2 from
> stretch to Jessie. Yes, this might break stuff, but I suspect just the
> very basic idea of this security fix - rejecting unbonded connections -
> could break stuff also.
Thinking this through some more, I struggle to get bluetooth working
correctly on the latest Debian, let alone testing an older release. I am
not sure if this is due to hardware or software issues. Not to mention
the fact I don't have a lot of bluetooth HID devices to test. I am sure
I had a bluetooth keyboard somewhere...
Is anybody here in a better position then I am to test this? If not,
this might be another reason to backport the Stretch version...
Regardless, I suspect something like the following patch might be a good
starting point. Although I am not entirely convinced you can reject a
connection from the attio_connected_cb function like this...
=== cut
diff --git a/profiles/input/hog.c b/profiles/input/hog.c
index b9aba657a..971fda822 100644
--- a/profiles/input/hog.c
+++ b/profiles/input/hog.c
@@ -654,6 +654,11 @@ static void attio_connected_cb(GAttrib *attrib, gpointer
user_data)
DBG("HoG connected");
+ /* HOGP 1.0 Section 6.1 requires bonding */
+ if (!device_is_bonded(hogdev, btd_device_get_bdaddr_type(hogdev)))
+ DBG("HoG not bonded");
+ return;
+
hogdev->attrib = g_attrib_ref(attrib);
if (hogdev->reports == NULL) {
=== cut
--
Brian May
Re: bluez / CVE-2020-0556
Ola Lundqvist writes: > I based my conclusion on the fact that hog.c does not seem to have the > concept of bonded at all. > This is what I mean with "does not seem to need". But I'm new to this > code so I could very well be wrong. I believe bonded is a global bluetooth concept, not specific to hog (which is just one protocol). See: https://codeitbro.blogspot.com/2017/04/ble-pairing-vs-bonding.html If you look at hog.c before the upstream commit was applied, it didn't have any concept of bonded either. -- Brian May
bluez / CVE-2020-0556
I am a bit puzzled by the following comment from dla-needed.txtfor bluez:
NOTE: 20200503: Looking at the four patches included in the stretch update it
looks like it
NOTE: 20200503: can be applied as is. What will fail is hog.c but that file
do not seem to
NOTE: 20200503: need an update. (Ola)
As far as i can tell, the first commit fixes the security flaw, and the
only file it touches in hog.c. If true that hog.c does not need an
update, does this means the package is not vulnerable? I suspect not.
https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=8cdbd3b09f29da29374e2f83369df24228da0ad1
- fix vulnerability.
https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=3cccdbab2324086588df4ccf5f892fb3ce1f1787
- make security posture configurable to support newer devices.
https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=35d8d895cd0b724e58129374beb0bb4a2edf9519
https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=f2778f5877d20696d68a452b26e4accb91bfb19e
- fix potential regressions.
The patch patches the hog_accept function, which is a callback set as
part of the hog_profile:
static struct btd_profile hog_profile = {
.name = "input-hog",
.remote_uuid= HOG_UUID,
.device_probe = hog_probe,
.device_remove = hog_remove,
.accept = hog_accept,
.disconnect = hog_disconnect,
.auto_connect = true,
};
Unfortunately the version in Jessie doesn't even have an accept entry:
static struct btd_profile hog_profile = {
.name = "input-hog",
.remote_uuid= HOG_UUID,
.device_probe = hog_probe,
.device_remove = hog_remove,
};
Looking at commit
https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=7d9718cfcc11eaa9d8059e721301cdc00ef8c82e,
it looks like maybe we should be patching the attio_connected_cb()
function instead. But this function doesn't appear to have any way to
return an error indicating it failed, which seems to be required by the
patch. It might be sufficient just to ignore the error and return
without immediately if device is not bonded. Not sure how much I can
trust this however.
My gut feeling to fix this we should backport version 5.43-2+deb9u2 from
stretch to Jessie. Yes, this might break stuff, but I suspect just the
very basic idea of this security fix - rejecting unbonded connections -
could break stuff also.
--
Brian May
https://linuxpenguins.xyz/brian/
Re: keystone support in Jessie
"Chris Lamb" writes: > Yes I believe so. Can you go ahead and request to add it there > whilst you have it open? If not, let me me know and I will go ahead > with that. I have removed keystone from dla-needed.txt in 18c3371ddc. Will do so. Probably Monday. -- Brian May
nginx / CVE-2020-11724
>From dla-needed.txt: > NOTE: 20200505: Patch for CVE-2020-11724 appears to be fairly > invasible and, alas, no tests. (lamby) What does invasible mean in this context? (I think I could guess - but rather not...) -- Brian May https://linuxpenguins.xyz/brian/
keystone support in Jessie
According to https://security-tracker.debian.org/tracker/CVE-2018-14432 [jessie] - keystone (Not supported in Jessie) https://salsa.debian.org/security-tracker-team/security-tracker/commit/3af1be6fb2f917d1809cdcec011f6b66ffe11234 But I don't see keystone listed in the security-support-ended file: https://salsa.debian.org/debian/debian-security-support/blob/master/security-support-ended.deb8 We have got a new TODO item to fix keystone for Jessie: https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/270cb63d918d3324b3dccfb93b45458824faf100 I assume this was a mistake, and keystone should be listed in security-support-ended? -- Brian May https://linuxpenguins.xyz/brian/
Re: mumble package / CVE-2018-20743
Abhijith PA writes: >> Unfortunately, I can't find any record of these discussions - in order >> to reduce duplicated work - is it possible you could please summarise >> here on debian-lts? > > I believe its a severe issue thus initiated discussion privately with > t...@security.debian.org I think, like it or not, details were already publicly available in the referenced github issue. From comment posted on 1st March. There is probably no point trying to keep this secret. -- Brian May
mumble package / CVE-2018-20743
Hello All, Background: Yesterday I started looking at an unclaimed package, mumble. I concluded that the security patch requires C++11, does unless C++11 support is enabled, but enabling C++11 support is not possible with the Jessie package as is because the Jessie package has no build support for C++11. Then today I noticed that Abhijith is still working on this package, who added the following entry to dla-needed.txt: === cut === commit c68a758f05548b7441dc218176123c37db4bb3bb Author: Abhijith PA Date: Tue May 5 18:02:27 2020 +0530 Add note for mumble in dla-needed.txt diff --git a/data/dla-needed.txt b/data/dla-needed.txt index 1f1e7888df..ef6beea1ac 100644 --- a/data/dla-needed.txt +++ b/data/dla-needed.txt @@ -65,6 +65,7 @@ mumble NOTE: 20200325: Regression in last upload, forgot to follow up. NOTE: 20200325: https://github.com/mumble-voip/mumble/issues/3605 (abhijith) NOTE: 20200420: Upstream patch is incomplete. Version in stretch is also vulnerable (abhijith) + NOTE: 20200504: discussion going on with t...@security.debian.org and mumble maintainer (abhijith) -- nginx NOTE: 20200505: Patch for CVE-2020-11724 appears to be fairly invasible and, alas, no tests. (lamby) === cut === Abhijith: Unfortunately, I can't find any record of these discussions - in order to reduce duplicated work - is it possible you could please summarise here on debian-lts? Alternatively (or maybe additionally) you might want to reclaim the mumble package again... Regards -- Brian May https://linuxpenguins.xyz/brian/
Re: Issues regarding ruby-rack/CVE-2019-16782
Utkarsh Gupta writes: > Please don't yet patch CVE-2019-16782 for Buster, Stretch, Jessie, et al. > This security update induces a regression, resulting in some issues in > using the library. > Also, there's a slight possibility of this patch inducing a backdoor on > it's own. > > The issues have already been opened to/with the upstream and I hope > they're looking into it. > P.S. Shall update here when available :) For reference I filled a similar bug against Django <https://code.djangoproject.com/ticket/31412#comment:8> and they responded with: > After consideration, the Django Security Team conclude that this is not > a practical attack vector. > > Work on the related hardenings, such as the referenced tickets should > continue. I am inclined to think we do not need to worry about patching old releases for this vulnerability for similar reasons. -- Brian May
Re: Issues regarding ruby-rack/CVE-2019-16782
Ola Lundqvist writes: > I have looked into this some but I have not been able to determine how long > the session ids were before the fix. Do anyone have that information? > Based on that we can rather easily determine how long time a timing attack > would take. My guess is a really long time. The more I look into this issue, the more I get confused. In summary, it seems to be a rather complicated fix for something which I would imagine to be very simple, and this is making me nervous about trying to come up with my own simple patch. >From https://github.com/advisories/GHSA-hrqr-hxpp-chr3: "Session ids are usually stored and indexed in a database that uses some kind of scheme for speeding up lookups of that session id." "The session id itself may be generated randomly, but the way the session is indexed by the backing store does not use a secure comparison." It appears to be talking about the lib/rack/session/pool.rb pool method of storing sessions. ... but I believe this stores the sessions in a in-memory hash table, not the database. From the comment at the top of the file: # Rack::Session::Pool provides simple cookie based session management. # Session data is stored in a hash held by @pool. # In the context of a multithreaded environment, sessions being # committed to the pool is done in a merging manner. Also, I am not seeing any code that allows the hash to be stored to a disk file or a database of any kind (did I miss something?) OK, so maybe we can conduct a timing attack against an in hash. As well as a database (??). Lets assume we can. Why do they even need to worry about checking the unhashed id in the hash table? When you upgrade it will kill the previous processes, which will kill the previous hash table, and no previous sessions will be valid anymore anyway. As far as I am aware it is not possible to upgrade a ruby process without restarting everything. Another possibility is that the researchers were more concerned about backends such as "memcache" rather then "cookie" or "pool". However the change that I can find in upstream only seems to be concerned with the "pool" backend. https://github.com/rack/rack/commit/7fecaee81f59926b6e1913511c90650e76673b38 Possibly this is because the memcache method was deprecated and moved to another gem: https://github.com/rack/rack/commit/54600771e3c9628c873fb1140b800ebb52f18e70#diff-ec7f0fcff10d701615d85df33fbbd545 Which replaces Memcache with Dalli instead. I have no idea if Dalli has been appropriately patched to deal with CVE-2019-16782. -- Brian May
Re: December LTS Report
Hugo Lefeuvre writes: > xcftools: > > + create a reproducer for CVE-2019-5086 and write a patch (still waiting >for some external review). > + start to investigate CVE-2019-5087. I am a bit puzzled, what is the difference between CVE-2019-5086 and CVE-2019-5087? As far as I can tell they both a the same vulnerability. Did I miss something? -- Brian May
Re: Support of lua-cgi
Ola Lundqvist writes: > Hi fellow LTS members > > Today (as part of front desk work) I triaged lua-cgi and I thought that the > session id vulnerabilities were rather basic and severe. So I thought that > if it is a really used software it would have been found much earlier. > Especially since the vulnerability have been there for some 6 years or so. > So I checked popcorn and it is not really used much. I know we cannot trust > popcorn that much but there were just some 80 installations reported in > total. > > So I think we should probably mark lua-cgi as unsupported instead of fixing > the vulnerabilities. Somehow the discussion on this turned to private emails, which wasn't my intention. Anyway, the summary is I don't believe that lua-cgi in Debian is vulnerable, because it is broken and cannot actually save sessions. For details, see the bug report I filled: http://bugs.debian.org/954300 I updated the bug report on the security issue, see: http://bugs.debian.org/953037 I also created some upstream bug reports: https://github.com/keplerproject/cgilua/issues/16 https://github.com/keplerproject/cgilua/issues/17 So I now intend to wait a bit and see if I get any responses. If not, I will mark this security issue as "not vulnerable" in Debian, because it is not possible to exploit as it is broken. -- Brian May
Re: Issues regarding ruby-rack/CVE-2019-16782
Ola Lundqvist writes: > I think the attacker needs to be very close, or at least on a connection to > the server with a very predictable timing making a live server exploit > difficult from a distance. Potentially possible. Yes, very likely. Unless the database is loaded, but that too could be another variable that makes this attack difficult. > This is a general problem for most kind of services and I do not think it > is limited to ruby-rack. It just happen to be so that we have a specific > CVE for ruby-rack. Others may have exactly the same issue. Agreed. > The solution to look up the hash of the session id makes sense. It makes > things much harder to exploit. > > The best solution as I see it is to do one the following: > > alternative 1: > At upgrade change all database session keys to the hash(key) and then only > lookup using the hash of the session id key. > There is no need to change the interface at all as I can see it. This would be my preference. As I have mentioned before, upstream were concerned this might break applications. The details given here - https://github.com/rack/rack/issues/1432#issuecomment-571688819 - don't entirely make sense to me. e.g. "The private id could be leaked" - if the public id is leaked, then it is easy to generate the private id anyway. > alternative 2: > No change at upgrade. At lookup look for the hash(key) and if that fails > look for the key. To improve the security we can introduce a random delay > between 0 and ... well the time a lookup take worst case. > Still no reason to change the interface as I see it. Yes, this is what upstream did, apart from the "not change the interface" or "introduce a random delay". > alternative 3: > Do as upstream. The problem is that upstream introduced an API change in a > non-backwards compatible way. This works for unstable, but I do not think > it is preferred for oldstable, oldoldstable or stable. > > Which one to choose. I think alternative 1 is the most secure option but > the upgrade may be complicated and is a little fault prone. I think > alternative 2 is good enough, especially with some random delay. Like I said, I am struggling to understand why upstream feels they need to keep track of two separate ids, or why not just hash the key before each database lookup. I am finding it hard to visualise an application that would use the session id in such a way that it would break if we hash it before looking up the database. I am not familiar with Ruby coding standards, Maybe existing Ruby code can do "interesting things" such as direct lookups in the session database using the session key? Also I noticed - and thought interesting - that storing sessions in the database was considered using rails (not rack being discussed here) was deprecated in 2012) http://blog.remarkablelabs.com/2012/12/activerecord-sessionstore-gem-extraction-rails-4-countdown-to-2013 -- Brian May
Re: Issues regarding ruby-rack/CVE-2019-16782
Ola Lundqvist writes: > So regarding your throught about why Rack has this and not others. Well I > think all have the same issue. I think it is a little of a stretch that > this can be used in practice. I mean an attacker must do a broad search of > all possible session identifiers to make use of this. Or have I > misunderstood something? I suspect you are mostly correct. However how many people would really notice if an attacker made numerous connections to their website in attempt to exploit this? -- Brian May
Re: Issues regarding ruby-rack/CVE-2019-16782
Ola Lundqvist writes: > I would have understood the upstream argument if the public key is a hash > of the private one. If it is the other way around (as you describe it) I do > not see any point. > That would even be a new CVE, because that is a security issue, really. > > I think it should return the public key and the public key should be a hash > of the private one. I do think the names upstream has chosen for these variables is rather confusing. public/private makes it seem like public key cryptography, where there is a public key, and it is safe for *anybody* to know this value (depending on how much you trust the cryptography that is). Not the case here. If you hashed the private id to create the public id you would still need to keep the public id secret. But that wouldn't work, because you couldn't lookup the session in the database using the public key. "public_id" is the secret session key that is stored in a cookie on the user's browser. It must remain secret at all times, just like any session key. It gives the holder unlimited access to the session. Normally we would lookup the session directly in the database as in query(public_id). However, as the attacker can carefully control the input and time how long it takes, this can lead to timing attacks. So instead we hash the public_id first. As in query(hash(public_id)). Now an attacker has problems carefully controlling the input to the database query, and this makes it hard (or impossible?) to do a timing based attack. Upstream has decided to call this hashed value the private key. As in private_id = hash(public_id) I think this is unfortunate terminology. Possibly it external_id/internal_id would be better. However I think we are stuck with it now. If there was an SQL operation that allowed us to do a query with a fixed time, that would also solve the problem. Unfortunately, I don't think there is such a thing. It has already been the goal for SQL databases to make these queries as fast as possible. Does this help explain things? I am still unclear why Rack has this issue, and not other libraries that do a similar lookup of an untrusted key value provided by the user in the database, e.g. Django. -- Brian May
Re: Issues regarding ruby-rack/CVE-2019-16782
Ola Lundqvist writes:
> Interesting. I think the upstream solution to search first for private id
> and then for public id is good enough for Debian stable releases.
> It should be extremely difficult (unless the computer is really slow) to
> calculate the timing for the public id part since there are so many other
> variables like link speed, process switching time and other that will cause
> delays on the same magnitude.
>
> For unstable, maybe a more secure solution is better.
>
> What I think we need to do however is to make a correction without changing
> to the more complex object to avoid breakage. Would that be a lot of work
> to do that?
It is easy to make the complex object auto cast to a string. The problem
is what string should it return?
Should it return the public string? The applications that expect to be
able to use that string to look up session data will break.
Should it return the private string?
Upstream says that this runs the risk of leaking the private key "The
public id is ok for anyone to know, and the private id must be kept
secret." This argument confuses me as the private key is just a hash of
the public key, it seems anybody with the public key can obtain the
private key. Wonder if I misunderstood something here?
def hash_sid(sid)
Digest::SHA256.hexdigest(sid)
end
def private_id
"#{ID_VERSION}::#{hash_sid(public_id)}"
end
Depending on what the application does the with session id however, just
blindly returning the private id might not always be the correct thing
either.
Plus now, as applications are adapting to this new API anyway, if we
change this now we could break applications that use the new API.
Django, does a lookup of the Session table using a Session key - which I
believe comes from an untrusted cookie. Probably many others too. Does
this mean Django is equally vulnerable? Or maybe Django already done
something to mitigate against this? I don't see anything.
https://github.com/django/django/blob/master/django/contrib/sessions/backends/db.py
This is the default session backend, others are also available:
https://docs.djangoproject.com/en/3.0/topics/http/sessions/#configuring-sessions
--
Brian May
Re: Issues regarding ruby-rack/CVE-2019-16782
Ola Lundqvist writes:
> I have looked into this some but I have not been able to determine how long
> the session ids were before the fix. Do anyone have that information?
> Based on that we can rather easily determine how long time a timing attack
> would take. My guess is a really long time.
My understanding is increasing.
The problem is when we lookup the session details from the database:
@pool[sid]
As sid is untrusted data, it means that can attacker can carefully
control the value and find out information on existing sessions based on
timing the query.
This patch would change that database lookup to:
@pool[sid.private_id]
Where sid.private_id = "#{ID_VERSION}::#{hash_sid(public_id)}"
This means the timing attack is harder (impossible?), because an
attacker cannot create good test data for the database lookup.
The problem with this approach however is we now have broken all
existing sessions. Because we have already stored the public id, not the
private id in the database. So the upstream solution is to use:
@pool[sid.private_id] || @pool[sid.public_id]
If the private_id lookup fails, the public_id lookup will be tried.
In https://github.com/rack/rack/issues/1431 the issue is raised that the
code still does the public_id lookup, which is what was responsible for
the bug in the first place. However the counter claim is that we have
already done the private_id lookup, and that is going to make timing
attacks hard.
If I understand this correctly, the goal will be to remove the public_id
lookup eventually.
Also, as upstream changed sid from a string to a more complicated
object, this breaks the current API. There are other possible solutions,
but as mentioned in
https://github.com/rack/rack/issues/1432#issuecomment-571688819 these
could lead to silent breakage, which is probably not a better outcome.
--
Brian May
Re: Issues regarding ruby-rack/CVE-2019-16782
Utkarsh Gupta writes: > Please don't yet patch CVE-2019-16782 for Buster, Stretch, Jessie, et al. > This security update induces a regression, resulting in some issues in > using the library. > Also, there's a slight possibility of this patch inducing a backdoor on > it's own. > > The issues have already been opened to/with the upstream and I hope > they're looking into it. > P.S. Shall update here when available :) Do you have any references to the upstream issue regarding the possible backdoor? I see: https://github.com/rack/rack/issues/1431 https://github.com/rack/rack/issues/1432 https://github.com/rack/rack/issues/1433 Apparently the regression is unavoidable - see https://github.com/rack/rack/issues/1432#issuecomment-571688819 Which in turn generated controversy - is it OK to cause breakage if it fixes a known security issue? https://github.com/rack/rack/issues/1432#issuecomment-571701768 This might rule out being able to provide fixes for Buster and Jessie. Oh, I see, #1431 mentions the possible backdoor; a claim that was disputed. It also seems like "I agree that the vulnerability is not that great and does take substantial time to pull off." - wonder if it even worth trying to fix this for anything other then unstable+testing. -- Brian May
[SECURITY] [DLA 2096-1] ruby-rack-cors security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: ruby-rack-cors Version: 0.2.9-1+deb8u1 CVE ID : CVE-2019-18978 This package allowed ../ directory traversal to access private resources because resource matching did not ensure that pathnames were in a canonical format. For Debian 8 "Jessie", this problem has been fixed in version 0.2.9-1+deb8u1. We recommend that you upgrade your ruby-rack-cors packages. Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKpwfR8DOwu5vyB4TKpJZkldkSvoFAl47tdIACgkQKpJZkldk SvrsJg/8CYbJp+/ZhDWCFJbiEvkv3gJqgTVsAQCGn1GBtdbmdr4DvN9aa+QdCkJM 0D9kGvTGeuwHs6Porc4C7oS1g9w5sD9nhnBcQ8xZ92m4Ja0uEeX5JS9wBPQYfyVY c5//vOvc2S/fLzFN0YD3kyC51/zhoeBqyVPXgkHWrpYNcpMC4K4RWWUlcfDWno/X djvkGF7a/DHR+5+kGlWfXc3pYZeEBO/swyXlYH66iBU5K/ah+yPlBFcf/xEHP2VB vy1bJ57hv/KAQjtj57bA/RMQbWvbEozvHV87Ebfr54P2OtbHGMJYpYG70hki/eIX nmhWMS3DW+mdUiXeSkWPEuAGr8qaQ+/PN5xhlfPjpz1qpcuECGDX8FPM+om0KyJh CR/YeQzwf8CGWhmAE+aXQ2SSpBU3JxN1P8vKWEbuTCR1W8SduOQZB/v1O+q03+O9 ez2Zz2u0/0mfkL2/kvheSjO4p7SpbUpPaN5nFvFKrfaRRQNIc0z6MV4qvIAAsoPw xzu6XWiKLCuH5JNx3H34KMPK3Qxvq7D+q7bJ5KE5iW64eG8pM8viCVfJJ5fHTgJS SSjmmPBruWbOfI4riWxM/UyBudsuUr4fx0xTkWDt5jjCxtAQyt8PlMt7mzhwzwnu 94oJQJc4fM7utykQXqXVpx3zGo1ydvrrOpLlgbCMXvxt4OKs7Kw= =Z7J3 -END PGP SIGNATURE-
ruby-rack-cors / CVE-2019-18978
Attached is my proposed patch for Jessie. This had to be adapted from
the upstream patch, however I think I have understood the intentions
clearly.
The Rack::Utils.clean_path_info and Rack::Utils.unescape_path functions
required by the upstream patch are not available in Jessie, so I copied
these from upstream:
https://github.com/rack/rack/blob/master/lib/rack/utils.rb
The supplied test case fails as expected without the required change and
succeeds as expected with the required change.
I just noticed I still need to update the changelog entry before
uploading.
diff -Nru ruby-rack-cors-0.2.9/debian/changelog
ruby-rack-cors-0.2.9/debian/changelog
--- ruby-rack-cors-0.2.9/debian/changelog 2014-04-24 23:53:38.0
+1000
+++ ruby-rack-cors-0.2.9/debian/changelog 2020-02-04 17:25:44.0
+1100
@@ -1,3 +1,9 @@
+ruby-rack-cors (0.2.9-1+deb8u1) UNRELEASED; urgency=high
+
+ * Non-maintainer upload by the LTS Team.
+
+ -- Brian May Tue, 04 Feb 2020 17:25:44 +1100
+
ruby-rack-cors (0.2.9-1) unstable; urgency=low
* New upstream release
diff -Nru ruby-rack-cors-0.2.9/debian/patches/CVE-2019-18978.patch
ruby-rack-cors-0.2.9/debian/patches/CVE-2019-18978.patch
--- ruby-rack-cors-0.2.9/debian/patches/CVE-2019-18978.patch1970-01-01
10:00:00.0 +1000
+++ ruby-rack-cors-0.2.9/debian/patches/CVE-2019-18978.patch2020-02-04
17:25:44.0 +1100
@@ -0,0 +1,104 @@
+--- a/test/unit/cors_test.rb
b/test/unit/cors_test.rb
+@@ -160,6 +160,12 @@
+ assert_cors_success
+ assert_not_nil last_response.headers['Content-Type']
+ end
++
++should "decode URL and resolve paths before resource matching" do
++ header 'Origin', 'http://localhost:3000'
++ get '/public/a/..%2F..%2Fprivate/stuff'
++ assert_cors_failure
++end
+ end
+
+ protected
+--- a/test/unit/test.ru
b/test/unit/test.ru
+@@ -28,6 +28,7 @@
+ allow do
+ origins '*'
+ resource '/public'
++resource '/public/*'
+ resource '/public_without_credentials', :credentials => false
+ end
+
+--- a/lib/rack/cors.rb
b/lib/rack/cors.rb
+@@ -30,17 +30,20 @@
+ env['HTTP_ORIGIN'] = 'file://' if env['HTTP_ORIGIN'] == 'null'
+ env['HTTP_ORIGIN'] ||= env['HTTP_X_ORIGIN']
+
++ path = evaluate_path(env)
++
+ cors_headers = nil
+ if env['HTTP_ORIGIN']
+ debug(env) do
+ [ 'Incoming Headers:',
+ " Origin: #{env['HTTP_ORIGIN']}",
++" Path-Info: #{path}",
+ " Access-Control-Request-Method:
#{env['HTTP_ACCESS_CONTROL_REQUEST_METHOD']}",
+ " Access-Control-Request-Headers:
#{env['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']}"
+ ].join("\n")
+ end
+ if env['REQUEST_METHOD'] == 'OPTIONS' and
env['HTTP_ACCESS_CONTROL_REQUEST_METHOD']
+- if headers = process_preflight(env)
++ if headers = process_preflight(env, path)
+ debug(env) do
+ "Preflight Headers:\n" +
+ headers.collect{|kv| " #{kv.join(': ')}"}.join("\n")
+@@ -48,7 +51,7 @@
+ return [200, headers, []]
+ end
+ else
+- cors_headers = process_cors(env)
++ cors_headers = process_cors(env, path)
+ end
+ end
+ status, headers, body = @app.call env
+@@ -74,17 +77,41 @@
+ end
+ end
+
++ PATH_SEPS = Regexp.union(*[::File::SEPARATOR,
::File::ALT_SEPARATOR].compact)
++
++ def clean_path_info(path_info)
++parts = path_info.split PATH_SEPS
++
++clean = []
++
++parts.each do |part|
++ next if part.empty? || part == '.'
++ part == '..' ? clean.pop : clean << part
++end
++
++clean_path = clean.join(::File::SEPARATOR)
++clean_path.prepend("/") if parts.empty? || parts.first.empty?
++clean_path
++ end
++
++ def evaluate_path(env)
++path = env['PATH_INFO']
++# path = Rack::Utils.clean_path_info(Rack::Utils.unescape_path(path))
if path
++path = clean_path_info(::URI::DEFAULT_PARSER.unescape(path)) if path
++path
++ end
++
+ def all_resources
+ @all_resources ||= []
+ end
+
+- def process_preflight(env)
+-resource = find_resource(env['HTTP_ORIGIN'], env['PATH_INFO'],env)
++ def process_preflight(env, path)
++resource = find_resource(env['HTTP_ORIGIN'], path,env)
+ resource && resource.process_preflight(env)
+ end
+
+- def process_cors(env)
+-resource = find_resource(env['HTTP_ORIGIN'], env['PATH_INFO'],env)
++ def process_cors(env, path)
++resource = find_resource(env['HTTP_ORIGIN'], path,env)
+ resource.to_headers(env) if resource
+ end
+
diff -Nru ruby-rack-cors-0.2.9/debian/patches/series
ruby-rack-cors-0.2.9/debian/patches
Re: ibus/CVE-2019-14822/glibc
Brian May writes: > Here is a better stack trace (previous version was picking up system > version of glib): Here is an even better version of the even better version of the stack trace that is actually useful (disabled compile time optimisation) (gdb) bt #0 0x772cbd08 in _g_log_abort (breakpoint=1) at gmessages.c:315 #1 0x772ccbea in g_logv (log_domain=0x778125ef "GLib-GObject", log_level=G_LOG_LEVEL_CRITICAL, format=0x7735b3af "%s: assertion '%s' failed", args=0x7fffd778) at gmessages.c:1042 #2 0x772ccce0 in g_log (log_domain=0x778125ef "GLib-GObject", log_level=G_LOG_LEVEL_CRITICAL, format=0x7735b3af "%s: assertion '%s' failed") at gmessages.c:1081 #3 0x772ccd21 in g_return_if_fail_warning (log_domain=0x778125ef "GLib-GObject", pretty_function=0x77813ccb <__FUNCTION__.12599> "g_object_ref", expression=0x77812b1b "G_IS_OBJECT (object)") at gmessages.c:1090 #4 0x777ee588 in g_object_ref (_object=0x0) at gobject.c:3041 #5 0x77ab4bf0 in cache_recv_address (socket=0x61c130, native=0x7fffe1b0, native_len=12) at gsocket.c:4038 #6 0x77ab501d in g_socket_receive_message (socket=0x61c130, address=0x7fffe318, vectors=0x7fffe330, num_vectors=1, messages=0x0, num_messages=0x0, flags=0x0, cancellable=0x0, error=0x7fffe320) at gsocket.c:4269 #7 0x77aed427 in read_netlink_messages (socket=0x0, condition=G_IO_IN, user_data=0x6119e0) at gnetworkmonitornetlink.c:328 #8 0x77aecd65 in g_network_monitor_netlink_initable_init (initable=0x6119e0, cancellable=0x0, error=0x0) at gnetworkmonitornetlink.c:141 #9 0x77a90ae4 in g_initable_init (initable=0x6119e0, cancellable=0x0, error=0x0) at ginitable.c:112 #10 0x77a90cd8 in g_initable_new_valist (object_type=6391376, first_property_name=0x0, var_args=0x7fffe4f0, cancellable=0x0, error=0x0) at ginitable.c:228 #11 0x77a90b9a in g_initable_new (object_type=6391376, cancellable=0x0, error=0x0, first_property_name=0x0) at ginitable.c:146 #12 0x77a941a1 in try_implementation (extension=0x6106c0, verify_func=0x0) at giomodule.c:755 #13 0x77a943a1 in _g_io_module_get_default (extension_point=0x77b76308 "gio-network-monitor", envvar=0x77b762f0 "GIO_USE_NETWORK_MONITOR", verify_func=0x0) at giomodule.c:857 #14 0x77a9e1b7 in g_network_monitor_get_default () at gnetworkmonitor.c:74 #15 0x00401761 in test_default () at network-monitor.c:241 #16 0x772ede8e in test_case_run (tc=0x613990) at gtestutils.c:2059 #17 0x772ee230 in g_test_run_suite_internal (suite=0x610240, path=0x7735fec0 "") at gtestutils.c:2120 #18 0x772ee2f2 in g_test_run_suite_internal (suite=0x610220, path=0x7735fec0 "") at gtestutils.c:2131 #19 0x772ee472 in g_test_run_suite (suite=0x610220) at gtestutils.c:2184 #20 0x772ed15f in g_test_run () at gtestutils.c:1488 #21 0x00402a7f in main (argc=1, argv=0x7fffe9f8) at network-monitor.c:536 Looking at gsocket.c:4038, saddr (source address) is NULL for some unknown reason. This value comes from: saddr = g_socket_address_new_from_native (native, native_len); No idea why this appears to be failing yet. -- Brian May
Re: ibus/CVE-2019-14822/glibc
Here is a better stack trace (previous version was picking up system version of glib): (jessie-amd64-default)brian@silverfish:~/debian/lts/packages/glib2.0/glib$ LD_LIBRARY_PATH=$PWD/gio/.libs:$PWD/glib/.libs gdb gio/tests/.libs/network-monitor GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from gio/tests/.libs/network-monitor...done. (gdb) r Starting program: /home/brian/debian/lts/packages/glib2.0/glib/gio/tests/.libs/network-monitor [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". /network-monitor/default: (/home/brian/debian/lts/packages/glib2.0/glib/gio/tests/.libs/network-monitor:27600): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed Program received signal SIGTRAP, Trace/breakpoint trap. g_logv (log_domain=0x77843856 "GLib-GObject", log_level=G_LOG_LEVEL_CRITICAL, format=, args=args@entry=0x7fffda98) at gmessages.c:1046 1046 g_private_set (_log_depth, GUINT_TO_POINTER (depth)); (gdb) bt #0 g_logv (log_domain=0x77843856 "GLib-GObject", log_level=G_LOG_LEVEL_CRITICAL, format=, args=args@entry=0x7fffda98) at gmessages.c:1046 #1 0x7731dc52 in g_log (log_domain=, log_level=, format=) at gmessages.c:1079 #2 0x7781deba in g_object_ref () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #3 0x77ad4e17 in cache_recv_address (native_len=, native=, socket=0x61c130) at gsocket.c:4038 #4 g_socket_receive_message (socket=0x61c130, address=address@entry=0x7fffe548, vectors=, vectors@entry=0x7fffe560, num_vectors=, num_vectors@entry=1, messages=messages@entry=0x0, num_messages=num_messages@entry=0x0, flags=0x0, cancellable=0x0, error=0x7fffe540) at gsocket.c:4269 #5 0x77b018df in read_netlink_messages (socket=socket@entry=0x0, condition=condition@entry=G_IO_IN, user_data=user_data@entry=0x6119e0) at gnetworkmonitornetlink.c:324 #6 0x77b02287 in g_network_monitor_netlink_initable_init (initable=, cancellable=, error=0x0) at gnetworkmonitornetlink.c:141 #7 0x77ab9d3e in g_initable_new_valist (object_type=, first_property_name=0x0, var_args=0x7fffe638, cancellable=0x0, error=0x0) at ginitable.c:228 #8 0x77ab9e2c in g_initable_new (object_type=, cancellable=cancellable@entry=0x0, error=error@entry=0x0, first_property_name=first_property_name@entry=0x0) at ginitable.c:146 #9 0x77abd456 in try_implementation (extension=, verify_func=verify_func@entry=0x0) at giomodule.c:755 #10 0x77abd5a0 in _g_io_module_get_default (extension_point=0x77b67c9f "gio-network-monitor", envvar=0x77b69565 "GIO_USE_NETWORK_MONITOR", verify_func=0x0) at giomodule.c:857 #11 0x00402433 in test_default () at network-monitor.c:241 #12 0x7733b753 in test_case_run (tc=0x613990) at gtestutils.c:2059 #13 g_test_run_suite_internal (suite=suite@entry=0x610240, path=path@entry=0x773b9fde "") at gtestutils.c:2120 #14 0x7733b922 in g_test_run_suite_internal (suite=suite@entry=0x610220, path=, path@entry=0x773b9fde "") at gtestutils.c:2131 #15 0x7733bc6b in g_test_run_suite (suite=0x610220) at gtestutils.c:2184 #16 0x00007733bca1 in g_test_run () at gtestutils.c:1488 #17 0x00401361 in main (argc=1, argv=0x7fffeab8) at network-monitor.c:536 (gdb) -- Brian May
Re: ibus/CVE-2019-14822/glibc
Brian May writes: > commit 7cba800a84730c9c5843acdd775e42b8c1438edf (HEAD) > Author: Alexander Larsson > Date: Mon Jun 1 10:02:47 2015 +0200 This patch decreases the number of errors from 1 to 52. (jessie-amd64-default)brian@silverfish:~/debian/lts/packages/glib2.0/glib$ gio/tests/network-monitor /network-monitor/default: (/home/brian/debian/lts/packages/glib2.0/glib/gio/tests/.libs/lt-network-monitor:20114): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed Trace/breakpoint trap gdb shows: (jessie-amd64-default)brian@silverfish:~/debian/lts/packages/glib2.0/glib$ LD_LIBRARY_PATH=$PWD/gio/.libs gdb gio/tests/.libs/network-monitor core GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from gio/tests/.libs/network-monitor...done. [New LWP 22889] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `gio/tests/.libs/network-monitor'. Program terminated with signal SIGTRAP, Trace/breakpoint trap. #0 0x7f035382adc0 in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 (gdb) bt #0 0x7f035382adc0 in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x7f035382afff in g_log () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f0353d01eba in g_object_ref () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #3 0x7f0353fb8e17 in cache_recv_address (native_len=, native=, socket=0x13f2130) at gsocket.c:4038 #4 g_socket_receive_message (socket=0x13f2130, address=address@entry=0x7fff92d8c288, vectors=, vectors@entry=0x7fff92d8c2a0, num_vectors=, num_vectors@entry=1, messages=messages@entry=0x0, num_messages=num_messages@entry=0x0, flags=0x0, cancellable=0x0, error=0x7fff92d8c280) at gsocket.c:4269 #5 0x7f0353fe58df in read_netlink_messages (socket=socket@entry=0x0, condition=condition@entry=G_IO_IN, user_data=user_data@entry=0x13e79e0) at gnetworkmonitornetlink.c:324 #6 0x7f0353fe6287 in g_network_monitor_netlink_initable_init (initable=, cancellable=, error=0x0) at gnetworkmonitornetlink.c:141 #7 0x7f0353f9dd3e in g_initable_new_valist (object_type=, first_property_name=0x0, var_args=0x7fff92d8c378, cancellable=0x0, error=0x0) at ginitable.c:228 #8 0x7f0353f9de2c in g_initable_new (object_type=, cancellable=cancellable@entry=0x0, error=error@entry=0x0, first_property_name=first_property_name@entry=0x0) at ginitable.c:146 #9 0x7f0353fa1456 in try_implementation (extension=, verify_func=verify_func@entry=0x0) at giomodule.c:755 #10 0x7f0353fa15a0 in _g_io_module_get_default (extension_point=0x7f035404bc9f "gio-network-monitor", envvar=0x7f035404d565 "GIO_USE_NETWORK_MONITOR", verify_func=0x0) at giomodule.c:857 #11 0x00402433 in test_default () at network-monitor.c:241 #12 0x7f03538493d3 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #13 0x7f03538495a2 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #14 0x7f035384990b in g_test_run_suite () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #15 0x7f0353849941 in g_test_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #16 0x00401361 in main (argc=1, argv=0x7fff92d8c818) at network-monitor.c:536 I am guessing maybe this patch has other requirements :-( -- Brian May
Re: ibus/CVE-2019-14822/glibc
Brian May writes: > With the 2nd patch, hangs, I pushed Ctrl-C to abort: > > (jessie-amd64-sbuild)brian@silverfish:/$ > /build/glib2.0-sBwZ3c/glib2.0-2.42.1/debian/build/deb/gio/tests/.libs/lt-network-monitor > -k --tap > # random seed: R02Sfd80eb1bd64b09d0b63ad8bcdfd117d2 > # Start of network-monitor tests > ^C git bisect shows the following commit fixes this: commit 7cba800a84730c9c5843acdd775e42b8c1438edf (HEAD) Author: Alexander Larsson Date: Mon Jun 1 10:02:47 2015 +0200 GNetworkMonitorNetlink: Fix check for non-kernel messages This code used to look at the SCM_CREDENTIALS and ignore every message not from uid 0. However, when user namespaces are in use this does not work, as if uid 0 is not mapped you get overflowuid instead. Right now this means we ignore all messages in such user namespaces and glib apps hang on startup. We can't look at pids either, as pid 0 is returned for processes outside your pid namespace. Instead the correct approach is to look at the sending sockaddr and if the port id (nl_pid) is zero, then its from the kernel. Source: http://lists.linuxfoundation.org/pipermail/containers/2015-May/036032.html https://bugzilla.gnome.org/show_bug.cgi?id=750203 -- Brian May
Re: ibus/CVE-2019-14822/glibc
ver stops talking. gdb session (note I had to override the shell because the default is zsh which didn't exist on my chroot, which caused problems for gdb): (jessie-amd64-sbuild)brian@silverfish:/build/glib2.0-sBwZ3c/glib2.0-2.42.1/debian/build/deb$ SHELL=/bin/sh gdb /build/glib2.0-sBwZ3c/glib2.0-2.42.1/debian/build/deb/gio/tests/.libs/lt-network-monitor GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /build/glib2.0-sBwZ3c/glib2.0-2.42.1/debian/build/deb/gio/tests/.libs/lt-network-monitor...done. (gdb) r Starting program: /build/glib2.0-sBwZ3c/glib2.0-2.42.1/debian/build/deb/gio/tests/.libs/lt-network-monitor [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". /network-monitor/default: ^C Program received signal SIGINT, Interrupt. 0x77030ad0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) bt #0 0x77030ad0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81 #1 0x77ad6f05 in g_socket_condition_timed_wait (socket=, condition=, timeout=, cancellable=0x0, error=0x7fffe5c8) at /build/glib2.0-sBwZ3c/glib2.0-2.42.1/./gio/gsocket.c:3655 #2 0x77ad7d84 in g_socket_receive_message (socket=0x61d130, address=address@entry=0x0, vectors=, vectors@entry=0x7fffe5d0, num_vectors=, num_vectors@entry=1, messages=messages@entry=0x0, num_messages=num_messages@entry=0x0, flags=0x7fffe5bc, cancellable=0x0, error=0x7fffe5c8) at /build/glib2.0-sBwZ3c/glib2.0-2.42.1/./gio/gsocket.c:4231 #3 0x77b03c15 in read_netlink_messages (socket=socket@entry=0x0, condition=condition@entry=G_IO_IN, user_data=user_data@entry=0x6129e0) at /build/glib2.0-sBwZ3c/glib2.0-2.42.1/./gio/gnetworkmonitornetlink.c:312 #4 0x77b045af in g_network_monitor_netlink_initable_init (initable=0x6129e0, cancellable=, error=0x0) at /build/glib2.0-sBwZ3c/glib2.0-2.42.1/./gio/gnetworkmonitornetlink.c:141 #5 0x77abe2ca in g_initable_new_valist (object_type=, first_property_name=0x0, var_args=0x7fffe6b0, cancellable=0x0, error=0x0) at /build/glib2.0-sBwZ3c/glib2.0-2.42.1/./gio/ginitable.c:228 #6 0x77abe3b6 in g_initable_new (object_type=, cancellable=cancellable@entry=0x0, error=error@entry=0x0, first_property_name=first_property_name@entry=0x0) at /build/glib2.0-sBwZ3c/glib2.0-2.42.1/./gio/ginitable.c:146 #7 0x77ac14a6 in try_implementation (extension=, verify_func=verify_func@entry=0x0) at /build/glib2.0-sBwZ3c/glib2.0-2.42.1/./gio/giomodule.c:755 #8 0x77ac1620 in _g_io_module_get_default (extension_point=0x77b69e9f "gio-network-monitor", envvar=0x77b6b945 "GIO_USE_NETWORK_MONITOR", verify_func=0x0) at /build/glib2.0-sBwZ3c/glib2.0-2.42.1/./gio/giomodule.c:857 #9 0x00402482 in test_default () at /build/glib2.0-sBwZ3c/glib2.0-2.42.1/./gio/tests/network-monitor.c:241 #10 0x7736b3d3 in test_case_run (tc=0x614990) at /build/glib2.0-sBwZ3c/glib2.0-2.42.1/./glib/gtestutils.c:2059 #11 g_test_run_suite_internal (suite=suite@entry=0x611240, path=path@entry=0x773c5f5e "") at /build/glib2.0-sBwZ3c/glib2.0-2.42.1/./glib/gtestutils.c:2120 #12 0x7736b5a2 in g_test_run_suite_internal (suite=suite@entry=0x611220, path=, path@entry=0x773c5f5e "") at /build/glib2.0-sBwZ3c/glib2.0-2.42.1/./glib/gtestutils.c:2131 #13 0x7736b90b in g_test_run_suite (suite=0x611220) at /build/glib2.0-sBwZ3c/glib2.0-2.42.1/./glib/gtestutils.c:2184 #14 0x7736b941 in g_test_run () at /build/glib2.0-sBwZ3c/glib2.0-2.42.1/./glib/gtestutils.c:1488 #15 0x00401461 in main (argc=1, argv=0x7fffeb68) at #/build/glib2.0-sBwZ3c/glib2.0-2.42.1/./gio/tests/network-monitor.c:536 -- Brian May
Re: ibus/CVE-2019-14822/glibc
Emilio Pozuelo Monfort writes: > Yes, that's the failing test I mentioned in my email. Building without the > patches works for me. I am still looking at whether upgrading ibus is worth it > due to the regression risk. It looks like the 2nd patch that is doing this. Just the 1st patch is fine. My running theory at present is that the test is confused because authentication is now required. I have no idea whether this is worth it or not. Possibly one option to think about is just patch ibus - that way the security issue is solved, and wait and see if anybody complains about the glib2.0 breakage. -- Brian May
