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. Additional info: See URL for the Deban BTS entry [1] for more details. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=442840
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 this time.
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. ...Ken 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. https://savannah.nongnu.org/patch/?6209 ...Ken
More from upstream: Guys, There have been a couple of upstream fixes that may be of interest: Bug 21123 - duplicity does not find any backup chains - Important https://savannah.nongnu.org/bugs/?21123 Patch 6211 - restore strict host checking in sshBackend - Security https://savannah.nongnu.org/patch/index.php?6211 ...Ken
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 regarding this.
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.