-
Notifications
You must be signed in to change notification settings - Fork 199
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
Conversation
5e28a88
to
71cd49e
Compare
FTR, the CVE related to this CVE-2019-12815. |
will this result in new releases for 1.3.5 and 1.3.6 ? |
@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. |
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? |
@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 |
why does it say every where that it is upto 1.3.5b then? are all version still vulnerable? |
ohh pheww! Thanks as always then :) |
@Castaglia |
Hi,
On Sun, Jul 28, 2019 at 06:34:35AM -0700, hpreusse wrote:
> @GitTur there is a _different_ issue, [Bug#4169](http://bugs.proftpd.org/show_bug.cgi?id=4169), that was addressed earlier in `mod_copy`.
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!
Some additional information: There were other issues related to
mod_copy, but CVE-2019-12815 is specific to the issue reported in
http://bugs.proftpd.org/show_bug.cgi?id=4372 .
The reporters (Tobias Mädel) blogpost about it is at
https://tbspace.de/cve201912815proftpd.html .
The CVE description should always be taken with a salt of grain. It
might just reflect the information available at a given point in time
or might reflect which versions were tested, but not mentioning
further followup versions in a branch does not necessarly mean it was
fixed after the mentioned version (unless it is clearly stated that
the issue is fixed in version x.y).
Sorry for the lengthly excurse, but I hope it is of benefit for all
following this issue as there was some confusion on which are the
fixed versions. At time of writing there is the fix commited but there
is no upstream version which would contain already the fix.
Hope this helps :)
If the fix additionally to on top of the 1.3.6 series could be
backported to the 1.3.5 series that would help downstreams shipping
this version :)
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. When trying to reproduce the issue, the
connection just terminates (plugging effectively the issue, but for
the 1.3.6 version it returns correctly a permission denied and
connection remains intact). There might thus missed some prerequeisite
commits for backports to the 1.3.5 series in e.g. the error handling
or so.
|
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. ;-( |
…/CPTO
commands.