Description of problem:
When duplicity's FTP backend calls ncftp, it passws the password argument via
command line. That's bad -- anyone can see that. On the other side, it's a very
good practice to overwrite the password string in the address space wfter it's
used, though it can still be viewed under a time-dependent race condition,
that's why I am cloning this to ncftp also.
See URL for the Deban BTS entry  for more details.
Bug #293091 is the ncftp one.
The CVE identifier for this was requested.
Thanks for you report, Lubomir. Do you know, whether upstream was already
notified about this security issue? I would like to avoid, that upstream and/or
multiple downstreams are doing the same work in parallel.
Robert -- I have no idea whether upstream knows about the issue. I usually put
all information I know into the bug report. Please look at the debian bug to see
whether they did report and check the public mailing lists of the project (I
presume this would be reported via a public mailing list, as it's a public issue).
Also, please don't change the Version of the Product this report is assigned to.
I care about having this fixed in f7 and this report is also for my track. It is
usually natural that all fixes for problems from stable branches propagate to
devel, if devel is affected.
I don't care about the version number, the issue has to be resolved in any
case for EL4, EL5, FC6 (when a fix comes up before EOL), F7 and F8/devel. I
will contact upstream directly to see, whether they know anything about it
Here is the reply from the upstream guy:
Yes, I am aware of the problem. One of the RCs used that solution. [comment:
the FIFO I mentioned in my e-mail]
The problem is that the ncftp program has different command line and
control file semantics for at least three of the most recent versions of
the program. Since we cannot lock the user into only one version of an
external program, I chose the path of least resistance.
Its an easy patch to make it work with a single version, but it would
break when ncftp is upgraded. That's not a situation we want to get
into for any distro.
Disclaimer: If you are on a system that is that insecure to begin with,
you need to rethink protocol. Not only is it available on the command
line, but on the net. Anyone with a sniffer could get it just as easy,
from inside and outside your net.
I'd say it's no problem to lock to a particular ncftp version we ship in Fedora,
and note a Require: on that version. It might be nice to put a comment above
Version: to both packages so that a developer that eventually bumps revision
ensures that he didn't break compatibility.
I also don't see a problem to lock duplicity to a specific ncftp version,
finally one more reply from upstream below:
I don't have a patch available. That feature was in a version a few
iterations ago and used mkstemp() to securely make a temp file. I'll
look into the FIFO option and get back to you. It would be a good thing
to have a patch available for others to use if they wanted.
Reply from upstream but only a possible solution for ncftp 3.2.1 which is not
in all branches available IIRC:
Here's the fix for users of ncftp 3.2.1. The previous versions of ncftp
have bugs relating to the use of -f, or require non-orthogonal command
options for the various utilities.
More from upstream:
There have been a couple of upstream fixes that may be of interest:
Bug 21123 - duplicity does not find any backup chains - Important
Patch 6211 - restore strict host checking in sshBackend - Security
As you might get noticed, ncftp thingie was closed, and future versions of ncftp
will be overwriting the password in argv as it is used. Still a race though.
Robert: When would it be possible to roll an updated package?
Ehm Lubomir, the ncftp bug report was marked as NOTABUG. Finally I can't see
any fix which would work for all Fedora and EPEL branches...maybe you've to
remove the tomatoes from my eyes, please?
CVE id CVE-2007-5201 was assigned to this issue.
Lubomir? Ping? Can you please reply to comment #11? No reply, no update ;-)
Robert; Well, leave this open. Maybe once I'll find time to look at this. Mabye
you --- all in all, you're the maintainer and one that is responsible to keep
his package secure :)
Please let me know, when a fix is available. Upstream doesn't see this as real
issue and http://www.nongnu.org/duplicity/CHANGELOG doesn't point out changes
duplicity-0.4.9-1.fc7 has been submitted as an update for Fedora 7
duplicity-0.4.9-1.fc8 has been submitted as an update for Fedora 8
duplicity-0.4.9-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
duplicity-0.4.9-1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.