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.
Upstream project has been marked as archived / read-only.
CCing treecleaner, package is unmaintained upstream
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(+)
Package list is empty or all packages have requested keywords.
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(-)
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.
(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.
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(-)
(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.
(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.
(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.
(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.
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(-)
