Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug #4372: Ensure that mod_copy checks for <Limits> for its SITE CPFR… #816

Merged
merged 1 commit into from Jul 17, 2019

Conversation

@Castaglia
Copy link
Member

commented Jul 17, 2019

…/CPTO

commands.

@Castaglia Castaglia added this to the 1.3.7 milestone Jul 17, 2019

@Castaglia Castaglia self-assigned this Jul 17, 2019

@Castaglia Castaglia force-pushed the site-cpfr-cpto-limits-bug4372 branch from 5e28a88 to 71cd49e Jul 17, 2019

@coveralls

This comment has been minimized.

Copy link

commented Jul 17, 2019

Coverage Status

Coverage remained the same at 82.446% when pulling 71cd49e on site-cpfr-cpto-limits-bug4372 into e12bf92 on master.

@Castaglia Castaglia merged commit d19dd64 into master Jul 17, 2019

3 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
coverage/coveralls Coverage remained the same at 82.446%
Details

@Castaglia Castaglia deleted the site-cpfr-cpto-limits-bug4372 branch Jul 17, 2019

@carnil

This comment has been minimized.

Copy link

commented Jul 21, 2019

FTR, the CVE related to this CVE-2019-12815.

@computersalat

This comment has been minimized.

Copy link

commented Jul 22, 2019

FTR, the CVE related to this CVE-2019-12815.

will this result in new releases for 1.3.5 and 1.3.6 ?

@ReillyProcentive

This comment has been minimized.

Copy link

commented Jul 24, 2019

@computersalat Hopefully it does, but you may need to build from source from the 1.3.6 branch until a release happens. I don't think the fix has been backported to 1.3.5 yet.

@benlarsendk

This comment has been minimized.

Copy link

commented Jul 25, 2019

If I installed 1.3.6 when it was released via RPM, would that version be vulnerable as well? From what I can read on NVD it's only up to 1.3.5b?

@ReillyProcentive

This comment has been minimized.

Copy link

commented Jul 25, 2019

@benlarsendk 1.3.6 is vulnerable as well. You will need to either build a new RPM from the 1.3.6 branch (you can refer to contrib/dist/travis/docker-rpmbuild.sh for how to do this) or wait for your package maintainer to do so.

@gittur

This comment has been minimized.

Copy link

commented Jul 27, 2019

why does it say every where that it is upto 1.3.5b then? are all version still vulnerable?

@Castaglia

This comment has been minimized.

Copy link
Member Author

commented Jul 27, 2019

@gittur there is a different issue, Bug#4169, that was addressed earlier in mod_copy.

@gittur

This comment has been minimized.

Copy link

commented Jul 27, 2019

ohh pheww! Thanks as always then :)

@hpreusse

This comment has been minimized.

Copy link

commented Jul 28, 2019

@Castaglia
Today I built a Debian package using source code of 1.3.5e and noticed that the issue is still reproducible. At least I can still create a malicious.php as described in Bug 4372. Please double check. Thanks!

@carnil

This comment has been minimized.

Copy link

commented Jul 28, 2019

@hpreusse

This comment has been minimized.

Copy link

commented Jul 28, 2019

Actually for Debian stretch Hilmar Preusse did backport the changes, see https://bugs.debian.org/932453 but in Debian we have not yet releases a so called DSA, because the version for 1.3.5 backport shows a strange behaviour.

It wasn't a backport what I did. I simply adapted the patch we got in this pull request so it applies to the source tree and compilation runs OK. As said: I didn't even do functional testing. ;-(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.