Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 755896 (CVE-2020-36420, CVE-2021-38614)

Summary: net-proxy/polipo: multiple vulnerabilities (CVE-2020-36420, CVE-2021-38614)
Product: Gentoo Security Reporter: John Helmert III <ajak>
Component: VulnerabilitiesAssignee: Gentoo Security <security>
Status: IN_PROGRESS ---    
Severity: minor CC: bircoph, qa, sam, treecleaner
Priority: Normal Keywords: PMASKED
Version: unspecified   
Hardware: All   
OS: Linux   
URL: https://www.openwall.com/lists/oss-security/2020/11/18/1
Whiteboard: B3 [glsa?]
Package list:
Runtime testing required: ---

Description John Helmert III archtester Gentoo Infrastructure gentoo-dev Security 2020-11-21 00:23:28 UTC
From $URL:

RFC7233 states [4]:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
A server that supports range requests MAY ignore or reject a Range
header field that consists of more than two overlapping ranges, or a
set of many small ranges that are not listed in ascending order,
since both are indications of either a broken client or a deliberate
denial-of-service attack (Section 6.1). ...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Polipo doesn't ignore/reject the malformed header. Instead, it has
an assertion:

    server.c:1473: assert(from >= 0 && (to < 0 || to > from));

So, a malformed Range header ("Range: bytes=3-2" for example) will
cause an assertion failed.  This error handling allows an attacker
to cause a denial of service.



Polipo is unmaintained, so no patches available.
Comment 1 Conrad Kostecki gentoo-dev 2021-07-13 11:44:09 UTC
Upstream project has been marked as archived / read-only.
Comment 2 John Helmert III archtester Gentoo Infrastructure gentoo-dev Security 2021-07-14 17:25:57 UTC
CCing treecleaner, package is unmaintained upstream
Comment 3 Larry the Git Cow gentoo-dev 2021-07-14 19:08:15 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6090311521594e454fd6366e5f453a1993512709

commit 6090311521594e454fd6366e5f453a1993512709
Author:     John Helmert III <ajak@gentoo.org>
AuthorDate: 2021-07-14 18:55:24 +0000
Commit:     John Helmert III <ajak@gentoo.org>
CommitDate: 2021-07-14 19:05:49 +0000

    package.mask: Last rite net-proxy/polipo
    
    Bug: https://bugs.gentoo.org/755896
    Bug: https://bugs.gentoo.org/781467
    Signed-off-by: John Helmert III <ajak@gentoo.org>

 profiles/package.mask | 5 +++++
 1 file changed, 5 insertions(+)
Comment 4 NATTkA bot gentoo-dev 2021-07-29 17:25:17 UTC Comment hidden (obsolete)
Comment 5 NATTkA bot gentoo-dev 2021-07-29 17:33:50 UTC Comment hidden (obsolete)
Comment 6 NATTkA bot gentoo-dev 2021-07-29 17:41:43 UTC Comment hidden (obsolete)
Comment 7 NATTkA bot gentoo-dev 2021-07-29 17:49:52 UTC Comment hidden (obsolete)
Comment 8 NATTkA bot gentoo-dev 2021-07-29 18:05:46 UTC
Package list is empty or all packages have requested keywords.
Comment 9 Larry the Git Cow gentoo-dev 2021-08-11 14:55:05 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=50377a1996dc8e19e54e1d7322733eff93b90938

commit 50377a1996dc8e19e54e1d7322733eff93b90938
Author:     Andrew Savchenko <bircoph@gentoo.org>
AuthorDate: 2021-08-11 14:51:46 +0000
Commit:     Andrew Savchenko <bircoph@gentoo.org>
CommitDate: 2021-08-11 14:54:55 +0000

    profiles: apply net-proxy/polipo mask only to vulnerable versions
    
    Bug: https://bugs.gentoo.org/755896
    Bug: https://bugs.gentoo.org/781467
    
    Signed-off-by: Andrew Savchenko <bircoph@gentoo.org>

 profiles/package.mask | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a6d841717c0d8a3cd1c56a88f0bd067551762384

commit a6d841717c0d8a3cd1c56a88f0bd067551762384
Author:     Andrew Savchenko <bircoph@gentoo.org>
AuthorDate: 2021-08-11 14:47:20 +0000
Commit:     Andrew Savchenko <bircoph@gentoo.org>
CommitDate: 2021-08-11 14:54:51 +0000

    net-proxy/polipo: fix CVE-2020-36420
    
    Discard packet with invalid range field instead of raising assert, this
    conforms to RFC7233. Return appropriate error message.
    
    Bug: https://bugs.gentoo.org/755896
    Package-Manager: Portage-3.0.20, Repoman-3.0.3
    Signed-off-by: Andrew Savchenko <bircoph@gentoo.org>

 .../polipo/files/polipo-1.1.1-cve-2020-36420.patch | 26 +++++++++
 net-proxy/polipo/polipo-1.1.1-r5.ebuild            | 61 ++++++++++++++++++++++
 net-proxy/polipo/polipo-9999.ebuild                |  7 +--
 3 files changed, 91 insertions(+), 3 deletions(-)
Comment 10 Andrew Savchenko gentoo-dev 2021-08-11 14:58:49 UTC
I fixed this CVE: quite trivial issue with minor impact anyway. Package mask is changed to apply to vulnerable versions only. No need to treeclean this package.

I'm not sure if there is a need to stabilize this package.
Comment 11 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-08-11 21:14:06 UTC
(In reply to Andrew Savchenko from comment #10)
> I fixed this CVE: quite trivial issue with minor impact anyway. Package mask
> is changed to apply to vulnerable versions only. No need to treeclean this
> package.
> 

It would've been appreciated if you could've given us a heads up / let us
in security@ and treecleaner@ know about your intentions.

This package isn't maintained upstream any longer (since 2016!)
and after doing some tests, ajak and I have reproduced another heap buffer
overflow *with* your patch.

I don't feel that adding piecework patches now will will fix the myriad issues
that seem present, given that ASAN blows up pretty quickly with *valid*
input (using an adapted version of the Perl script from the oss-security thread).

If you want to maintain a full fork, that's your perogative, but it will
require more than a few quick patches to get it up to any sort
of safe standard. I don't know if you want to make such a large
time commitment.

We suspect there's likely to be other issues given how simple
this one was, and its utility is rather diminished in 2021
anyway given the use of HTTPS. AFAIK, you may be able to
use Squid for this instead - which, while heavier, is
a lot more battle-hardened.

> I'm not sure if there is a need to stabilize this package.

The previous version (1.1.1-r4, before your patch) in Gentoo has stable keywords
for both amd64 and x86, so stabilisation would be required if we were keeping
the package to protect users.

I'd also note that while you've unmasked the package, it still has QA issues:
* bug 781467 (GLEP 81 support) has not been resolved;
* seems to use DEPEND incorrectly (texinfo should be BDEPEND afaik?);
* unusual conditional installation of cron files based on USE=systemd (although
  there may be a few other cases of this in tree);
* still retains the live ebuild (even though upstream's repository is archived).

So, with all that said, I'm going to restore the mask. I don't think it's
in a suitable state for users and I don't see the issue as resolved.
Comment 12 Larry the Git Cow gentoo-dev 2021-08-11 21:14:55 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8dac54528398bcd32c75fedc037bbe388b192e1f

commit 8dac54528398bcd32c75fedc037bbe388b192e1f
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-08-11 21:14:20 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-08-11 21:14:46 +0000

    Revert "profiles: apply net-proxy/polipo mask only to vulnerable versions"
    
    See bug for explanation; package is still vulnerable.
    
    This reverts commit 50377a1996dc8e19e54e1d7322733eff93b90938.
    
    Bug: https://bugs.gentoo.org/755896
    Signed-off-by: Sam James <sam@gentoo.org>

 profiles/package.mask | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)
Comment 13 Andrew Savchenko gentoo-dev 2021-08-12 19:35:21 UTC
(In reply to Sam James from comment #11)
> (In reply to Andrew Savchenko from comment #10)
> > I fixed this CVE: quite trivial issue with minor impact anyway. Package mask
> > is changed to apply to vulnerable versions only. No need to treeclean this
> > package.
> > 
> 
> It would've been appreciated if you could've given us a heads up / let us
> in security@ and treecleaner@ know about your intentions.

I made so by stating that CVE is trivial:
https://bugs.gentoo.org/781467#c4
And fixing it within reasonable time before treecleaning deadline.

> This package isn't maintained upstream any longer (since 2016!)

Some parts of kernel or glibc are not changed since 90-th. So if code works, this is fine and not an argument for packages mask or removal by itself.

> and after doing some tests, ajak and I have reproduced another heap buffer
> overflow *with* your patch.

What do you mean by *another*? CVE-2020-36420 is NOT a buffer overflow! Please read this CVE or my patch (or both). This CVE is about an assert working on invalid packet header field instead of discarding or ignoring such packet. As any assert it leads to controlled program termination, there are no overflows here. I can hardly call this vulnerability, but formally it may be called so of course: if local user decides to kill his own local polipo instance, they can do it this way.

If you have found another problem, please report it separately and register another CVE.

> I don't feel that adding piecework patches now will will fix the myriad
> issues
> that seem present, given that ASAN blows up pretty quickly with *valid*
> input (using an adapted version of the Perl script from the oss-security
> thread).

Asan will blow up on half of the portage tree in one or other configuration. Furthermore asan is known to occasionally produce false or unrelated warnings.

> If you want to maintain a full fork, that's your perogative, but it will
> require more than a few quick patches to get it up to any sort
> of safe standard. I don't know if you want to make such a large
> time commitment.

Software doesn't need to be 100% perfect and 100% compatible with all possible standards in order to be usable.

> We suspect there's likely to be other issues given how simple
> this one was, and its utility is rather diminished in 2021
> anyway given the use of HTTPS.

Unless someone uses it together with privoxy with https inspection.

> AFAIK, you may be able to
> use Squid for this instead - which, while heavier, is
> a lot more battle-hardened.

This is not just question of being heavier (though such argument is valid concern by itself). In my opinion the Squid is less secure, because of much larger code size. Compare number of CVEs reported for squid and polipo over 10 years or so. This means that right now Squid is vulnerable, but these vulnerabilities are not yet disclosed or even reported, this will be done later with timeflow. The same is valid for polipo of course. But smaller code mean smaller attack surface and smaller number of mistakes. Of course lack of active maintenance hampers polipo security, but it is still at reasonable levels IMO.
 
> > I'm not sure if there is a need to stabilize this package.
> 
> The previous version (1.1.1-r4, before your patch) in Gentoo has stable
> keywords
> for both amd64 and x86, so stabilisation would be required if we were keeping
> the package to protect users.

I'm fine with this. If package would not be masked, I would proceed this way without questions. Since it is already masked I decided that maybe stable version is not needed. I don't object to stable version to be available, of course.

> I'd also note that while you've unmasked the package, it still has QA issues:

Let me note that this is security bug, not QA bug. Let's not mix different issues in the single bug. While unfixed CVE is valid reason for PMASK, minor QA issues are not. But CVE-2020-36420 is already fixed, so no justified reason for PMASK left.

> * bug 781467 (GLEP 81 support) has not been resolved;

It was not resolved because of proposed commits being reverted due to this treecleaning. So we have chicken and the egg problem here. To unravel it I fixed CVE and propesed original author to reapply GLEP 81 changes, adding myself for fallback if there will be no activity or interest. See bug 781467 

> * seems to use DEPEND incorrectly (texinfo should be BDEPEND afaik?);

Yes, this is mistaken both myself and repoman full check overlooked. I'll fix it, but this is not a security issue.

> * unusual conditional installation of cron files based on USE=systemd
> (although
>   there may be a few other cases of this in tree);

As far as I remember there was no need or requests for such cron job for systemd users, . I don't use systemd myself even on test setups (and will not recommend other people to use it), so I provide only third-party systemd support in my packages: either upstream, or user, or other dev contributed as long as they don't break non-systemd setups.

> * still retains the live ebuild (even though upstream's repository is
> archived).

It can be dropped or snapsoht can be made, this is not a problem at all.

> So, with all that said, I'm going to restore the mask. I don't think it's
> in a suitable state for users and I don't see the issue as resolved.

The main subject of this discussion — CVE-2020-36420 — is fixed. Anyone can verify this by running test perl script provided by CVE reporter: https://www.openwall.com/lists/oss-security/2020/11/18/1
on polipo-1.1.1-r5.

There are no open CVEs left for this package and hereby no reason for security team to mask package and ask for its removal. Please revert your latest commit with full PMASK.
Comment 14 David Seifert gentoo-dev 2021-08-12 19:54:48 UTC
(In reply to Andrew Savchenko from comment #13)
> (In reply to Sam James from comment #11)
> > (In reply to Andrew Savchenko from comment #10)
> > > I fixed this CVE: quite trivial issue with minor impact anyway. Package mask
> > > is changed to apply to vulnerable versions only. No need to treeclean this
> > > package.
> > > 
> > 
> > It would've been appreciated if you could've given us a heads up / let us
> > in security@ and treecleaner@ know about your intentions.
> 
> I made so by stating that CVE is trivial:
> https://bugs.gentoo.org/781467#c4
> And fixing it within reasonable time before treecleaning deadline.
> 
> > This package isn't maintained upstream any longer (since 2016!)
> 
> Some parts of kernel or glibc are not changed since 90-th. So if code works,
> this is fine and not an argument for packages mask or removal by itself.
> 
> > and after doing some tests, ajak and I have reproduced another heap buffer
> > overflow *with* your patch.
> 
> What do you mean by *another*? CVE-2020-36420 is NOT a buffer overflow!
> Please read this CVE or my patch (or both). This CVE is about an assert
> working on invalid packet header field instead of discarding or ignoring
> such packet. As any assert it leads to controlled program termination, there
> are no overflows here. I can hardly call this vulnerability, but formally it
> may be called so of course: if local user decides to kill his own local
> polipo instance, they can do it this way.
> 
> If you have found another problem, please report it separately and register
> another CVE.
> 
> > I don't feel that adding piecework patches now will will fix the myriad
> > issues
> > that seem present, given that ASAN blows up pretty quickly with *valid*
> > input (using an adapted version of the Perl script from the oss-security
> > thread).
> 
> Asan will blow up on half of the portage tree in one or other configuration.
> Furthermore asan is known to occasionally produce false or unrelated
> warnings.
> 
> > If you want to maintain a full fork, that's your perogative, but it will
> > require more than a few quick patches to get it up to any sort
> > of safe standard. I don't know if you want to make such a large
> > time commitment.
> 
> Software doesn't need to be 100% perfect and 100% compatible with all
> possible standards in order to be usable.
> 
> > We suspect there's likely to be other issues given how simple
> > this one was, and its utility is rather diminished in 2021
> > anyway given the use of HTTPS.
> 
> Unless someone uses it together with privoxy with https inspection.
> 
> > AFAIK, you may be able to
> > use Squid for this instead - which, while heavier, is
> > a lot more battle-hardened.
> 
> This is not just question of being heavier (though such argument is valid
> concern by itself). In my opinion the Squid is less secure, because of much
> larger code size. Compare number of CVEs reported for squid and polipo over
> 10 years or so. This means that right now Squid is vulnerable, but these
> vulnerabilities are not yet disclosed or even reported, this will be done
> later with timeflow. The same is valid for polipo of course. But smaller
> code mean smaller attack surface and smaller number of mistakes. Of course
> lack of active maintenance hampers polipo security, but it is still at
> reasonable levels IMO.
>  
> > > I'm not sure if there is a need to stabilize this package.
> > 
> > The previous version (1.1.1-r4, before your patch) in Gentoo has stable
> > keywords
> > for both amd64 and x86, so stabilisation would be required if we were keeping
> > the package to protect users.
> 
> I'm fine with this. If package would not be masked, I would proceed this way
> without questions. Since it is already masked I decided that maybe stable
> version is not needed. I don't object to stable version to be available, of
> course.
> 
> > I'd also note that while you've unmasked the package, it still has QA issues:
> 
> Let me note that this is security bug, not QA bug. Let's not mix different
> issues in the single bug. While unfixed CVE is valid reason for PMASK, minor
> QA issues are not. But CVE-2020-36420 is already fixed, so no justified
> reason for PMASK left.
> 
> > * bug 781467 (GLEP 81 support) has not been resolved;
> 
> It was not resolved because of proposed commits being reverted due to this
> treecleaning. So we have chicken and the egg problem here. To unravel it I
> fixed CVE and propesed original author to reapply GLEP 81 changes, adding
> myself for fallback if there will be no activity or interest. See bug 781467 
> 
> > * seems to use DEPEND incorrectly (texinfo should be BDEPEND afaik?);
> 
> Yes, this is mistaken both myself and repoman full check overlooked. I'll
> fix it, but this is not a security issue.
> 
> > * unusual conditional installation of cron files based on USE=systemd
> > (although
> >   there may be a few other cases of this in tree);
> 
> As far as I remember there was no need or requests for such cron job for
> systemd users, . I don't use systemd myself even on test setups (and will
> not recommend other people to use it), so I provide only third-party systemd
> support in my packages: either upstream, or user, or other dev contributed
> as long as they don't break non-systemd setups.
> 
> > * still retains the live ebuild (even though upstream's repository is
> > archived).
> 
> It can be dropped or snapsoht can be made, this is not a problem at all.
> 
> > So, with all that said, I'm going to restore the mask. I don't think it's
> > in a suitable state for users and I don't see the issue as resolved.
> 
> The main subject of this discussion — CVE-2020-36420 — is fixed. Anyone can
> verify this by running test perl script provided by CVE reporter:
> https://www.openwall.com/lists/oss-security/2020/11/18/1
> on polipo-1.1.1-r5.
> 
> There are no open CVEs left for this package and hereby no reason for
> security team to mask package and ask for its removal. Please revert your
> latest commit with full PMASK.

I have looked at this package and spoken to members of security. This package will not be unmasked.
Comment 15 Andrew Savchenko gentoo-dev 2021-08-12 21:01:22 UTC
(In reply to David Seifert from comment #14)
> I have looked at this package and spoken to members of security. This
> package will not be unmasked.

Explain your reasons please from security point of view.
Comment 16 John Helmert III archtester Gentoo Infrastructure gentoo-dev Security 2021-08-12 21:05:47 UTC
(In reply to Andrew Savchenko from comment #13)
> (In reply to Sam James from comment #11)
> > (In reply to Andrew Savchenko from comment #10)
> > > I fixed this CVE: quite trivial issue with minor impact anyway. Package mask
> > > is changed to apply to vulnerable versions only. No need to treeclean this
> > > package.
> > > 
> > 
> > It would've been appreciated if you could've given us a heads up / let us
> > in security@ and treecleaner@ know about your intentions.
> 
> I made so by stating that CVE is trivial:
> https://bugs.gentoo.org/781467#c4
> And fixing it within reasonable time before treecleaning deadline.
> 
> > This package isn't maintained upstream any longer (since 2016!)
> 
> Some parts of kernel or glibc are not changed since 90-th. So if code works,
> this is fine and not an argument for packages mask or removal by itself.
> 
> > and after doing some tests, ajak and I have reproduced another heap buffer
> > overflow *with* your patch.
> 
> What do you mean by *another*? CVE-2020-36420 is NOT a buffer overflow!
> Please read this CVE or my patch (or both). This CVE is about an assert
> working on invalid packet header field instead of discarding or ignoring
> such packet. As any assert it leads to controlled program termination, there
> are no overflows here. I can hardly call this vulnerability, but formally it
> may be called so of course: if local user decides to kill his own local
> polipo instance, they can do it this way.
> 
> If you have found another problem, please report it separately and register
> another CVE.

Sure. Requested. It will be added to this bug, and will be another reason to remove the package, and likely another reason for other distributions to start to remove the package.

> > I don't feel that adding piecework patches now will will fix the myriad
> > issues
> > that seem present, given that ASAN blows up pretty quickly with *valid*
> > input (using an adapted version of the Perl script from the oss-security
> > thread).
> 
> Asan will blow up on half of the portage tree in one or other configuration.
> Furthermore asan is known to occasionally produce false or unrelated
> warnings.

Is this one invalid?

> > If you want to maintain a full fork, that's your perogative, but it will
> > require more than a few quick patches to get it up to any sort
> > of safe standard. I don't know if you want to make such a large
> > time commitment.
> 
> Software doesn't need to be 100% perfect and 100% compatible with all
> possible standards in order to be usable.

I think it's obvious why we should try to avoid shipping blatantly vulnerable packages.

> [snip]
>
> The main subject of this discussion — CVE-2020-36420 — is fixed. Anyone can
> verify this by running test perl script provided by CVE reporter:
> https://www.openwall.com/lists/oss-security/2020/11/18/1
> on polipo-1.1.1-r5.
> 
> There are no open CVEs left for this package and hereby no reason for
> security team to mask package and ask for its removal. Please revert your
> latest commit with full PMASK.

CVEs don't equate to vulnerabilities. There's an obvious heap overflow here that multiple people have reproduced. The fact that this vulnerability doesn't have a CVE doesn't mean it doesn't exist.

You can reproduce by modifying the Perl script to send a valid Range header.
Comment 17 Larry the Git Cow gentoo-dev 2021-08-14 19:13:04 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=58902da07474481bbbe106f55128e25fd9e5d1fa

commit 58902da07474481bbbe106f55128e25fd9e5d1fa
Author:     Jakov Smolic <jakov.smolic@sartura.hr>
AuthorDate: 2021-08-14 19:12:29 +0000
Commit:     David Seifert <soap@gentoo.org>
CommitDate: 2021-08-14 19:12:29 +0000

    net-proxy/polipo: Remove last-rited pkg
    
    Closes: https://bugs.gentoo.org/781467
    Bug: https://bugs.gentoo.org/755896
    Signed-off-by: Jakov Smolic <jakov.smolic@sartura.hr>
    Signed-off-by: David Seifert <soap@gentoo.org>

 net-proxy/polipo/Manifest                          |  1 -
 net-proxy/polipo/files/config                      |  8 ---
 .../polipo/files/polipo-1.1.1-cve-2020-36420.patch | 26 ---------
 net-proxy/polipo/files/polipo.crond-2              | 22 --------
 net-proxy/polipo/files/polipo.initd-5              | 65 ----------------------
 net-proxy/polipo/files/polipo_at.service           | 11 ----
 net-proxy/polipo/metadata.xml                      |  7 ---
 net-proxy/polipo/polipo-1.1.1-r4.ebuild            | 60 --------------------
 net-proxy/polipo/polipo-1.1.1-r5.ebuild            | 61 --------------------
 net-proxy/polipo/polipo-9999.ebuild                | 61 --------------------
 profiles/package.mask                              |  5 --
 11 files changed, 327 deletions(-)