from:"Brian May"

Re: Golang packages

2021-05-19 Thread Brian May

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

2021-05-17 Thread Brian May

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

2021-02-11 Thread Brian May

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/

openjpeg2

2021-02-04 Thread Brian May

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 *

ruby-actionpack-page-caching / CVE-2020-8159

2021-01-14 Thread Brian May

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

Re: golang-1.7 / CVE-2019-9514 / CVE-2019-9512

2020-12-07 Thread Brian May

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

2020-12-06 Thread Brian May

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.

Re: golang-1.7 / CVE-2019-9514 / CVE-2019-9512

2020-12-03 Thread Brian May

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

2020-12-03 Thread Brian May

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

2020-12-02 Thread Brian May

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&keywords=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

2020-12-02 Thread Brian May

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

2020-12-02 Thread Brian May

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

2020-12-01 Thread Brian May

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

2020-11-30 Thread Brian May

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)

2020-11-19 Thread Brian May

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

Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)

2020-11-16 Thread Brian May

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

1 2 3 4 5 6 >

1 - 100 of 527 matches

Mail list logo