Re: privoxy stretch package 3.0.26-3+deb9u2 prepared
Hi Abhijith! On Di, 09 Mär 2021, Abhijith PA wrote: > Roland, thanks again for the patch. I can see that last LTS update > (3.0.26-3+deb9u1) done by you. Hope you can upload this time as > well. If not, let me know. I am happy to help. Once uploaded to > archive I will take care of DLA and announcements. Thanks for your support. I just uploaded privoxy_3.0.26-3+deb9u2_source.changes to security-master. Once it is installed, it would be great if you could do DLA etc. Greetings Roland signature.asc Description: PGP signature
Re: CVE-2021-3121 stretch patch review request and request for test help
Hi, I'll let the Go packagers answer authoritatively but as I'm currently working on golang fixes I'd like to share a few points: On 08/03/2021 22:48, Ola Lundqvist wrote: I have prepared a patch for CVE-2021-3121 described in: https://security-tracker.debian.org/tracker/CVE-2021-3121 You can find the patch here: http://apt.inguza.net/stretch-lts/golang-gogoprotobuf/CVE-2021-3121-1.patch The patch is based on the following commit: https://github.com/gogo/protobuf/commit/b03c65ea87cdc3521ede29f62fe3ce239267c1bc My conclusion is that the field function in stretch is unaffected. The reason is that there is no skippy check there at all in the stretch version. For the generate function the iNdEx check was not in place so I added it, similar to the patch. I do have a problem, and that is to check whether the code introduce some regression issue. Also since the CVE lack a description of the effect of this problem I have little knowledge on what the result of this may be. Therefore I would highly appreciate a description of what this problem is and how to regression test the package. This appears to be a tricky issue to fix. First, due to static linking in Go, dependencies need to be rebuilt too, but even then, the vulnerability lies in generated code. (see below for a list of deps) Then, the vulnerability appears to be a serialization issue but even the netapp report is vague. To test the fix, the package comes with a testsuite, though the original patch includes dozens of testsuite changes (mostly regenerated files). Then all the dependencies (that need a rebuild) do provide another way to check if something broke. It should be noted that golang* packages are supported in stretch but come with limited support, not to due to code generation but due to Go static linking in the first place: https://salsa.debian.org/debian/debian-security-support/-/blob/stretch/security-support-limited If you do decide to support this package, I recently documented how to find direct reverse build dependencies at: https://wiki.debian.org/LTS/TestSuites/golang $ dose-ceve --deb-native-arch=amd64 -r golang-github-gogo-protobuf-dev -T debsrc debsrc:///var/lib/apt/lists/ftp.fr.debian.org_debian_dists_stretch_main_source_Sources deb:///var/lib/apt/lists/ftp.fr.debian.org_debian_dists_stretch_main_binary-amd64_Packages | grep-dctrl -n -s Package '' | sort -u gobgp golang-github-appc-goaci golang-github-appc-spec golang-github-mesos-mesos-go influxdb syncthing (Note: this is not recursive.) In addition, apt-file does provide a list of generated .pb.go files, though it also includes those from "plain" protobuf (of which gogoprotobuf if a fork) so not all are affected (the affected ones should contain "skippy" somewhere): # apt-file search .pb.go | cut -d: -f1 | sort -u golang-github-appc-spec-dev golang-github-gogo-protobuf-dev golang-github-golang-groupcache-dev golang-github-influxdb-influxdb-dev golang-github-mesos-mesos-go-dev golang-github-opencontainers-runc-dev golang-github-osrg-gobgp-dev golang-github-prometheus-alertmanager-dev golang-github-prometheus-client-model-dev golang-github-syncthing-syncthing-dev golang-gomega-dev golang-google-appengine-dev golang-google-genproto-dev golang-google-grpc-dev golang-gopkg-dancannon-gorethink.v1-dev golang-gopkg-dancannon-gorethink.v2-dev golang-goprotobuf-dev Cheers! Sylvain
Re: privoxy stretch package 3.0.26-3+deb9u2 prepared
On 09/03/21 10:47 AM, Roland Rosenfeld wrote: > Hi Abhijith! > > On Di, 09 Mär 2021, Abhijith PA wrote: > > > Roland, thanks again for the patch. I can see that last LTS update > > (3.0.26-3+deb9u1) done by you. Hope you can upload this time as > > well. If not, let me know. I am happy to help. Once uploaded to > > archive I will take care of DLA and announcements. > > Thanks for your support. > > I just uploaded privoxy_3.0.26-3+deb9u2_source.changes to > security-master. > > Once it is installed, it would be great if you could do DLA etc. DLA 2587-1. This is done. Thanks --abhijith
Re: CVE-2020-36193 php-pear vs drupal7
Hi Gunnar, all
See below.
On Tue, 9 Mar 2021 at 05:11, Gunnar Wolf wrote:
> Hello Ola, Salvatore, Chris et. al.!
>
> Ola Lundqvist dijo [Mon, Mar 08, 2021 at 11:51:35PM +0100]:
> > Hi Salvatore, Gunnar, all
> >
> > When looking further into this issue I do not think drupal7 is completely
> > fixed.
> > The durpal 7 package include the following fix:
> > +if (strpos(realpath(dirname($v_header['link'])),
> > realpath($p_path)) !== 0) {
> >
> > But it is missing the depth check
> >
> https://github.com/pear/Archive_Tar/commit/b6da5c32254162fa0752616479fb3d3c5297c1cf
> >
> > Or is it something that makes that depth check unnecessary?
> >
> > I'm asking since I'm looking into the php-pear fix and it should be very
> > similar to the drupal 7 fix.
>
> Umh... Did you consider the following patch?
>
>
> https://salsa.debian.org/debian/drupal7/-/blob/stretch/debian/patches/SA-CORE-2021-001
>
>
Yes, that is the "if (strpos(..." fix I was referring to below.
This is needed, but for php-pear there is also the fix to check for
multiple ../.. as protection mentioned as part of this CVE. This is not
included in the Drupal fix you mention and then obviously not in the
uploaded package either.
To me it looks like we have one more flaw to fix in Drupal. The question is
whether it should be handled as part of this CVE, or if we should consider
requesting a new CVE for it.
> I understand, but will admit that I didn't dig deep at all, that the
> Drupal7 team considers this as fixed WRT CVE-2020-36193. But, of
> course, my handling of this issue was basically only backporting the
> (very simple) diff in question from their 7.78 to our 7.52.
>
I see.
Best regards
// Ola
> Greetings,
>
--
--- Inguza Technology AB --- MSc in Information Technology
| o...@inguza.como...@debian.org|
| http://inguza.com/Mobile: +46 (0)70-332 1551 |
---
