Bug 844631 - Corrupted files after login failure
Summary: Corrupted files after login failure
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: vsftpd
Version: 5.8
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Jiri Skala
QA Contact: BaseOS QE Security Team
Depends On:
TreeView+ depends on / blocked
Reported: 2012-07-31 09:05 UTC by Assen Totin
Modified: 2014-11-09 22:35 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-12-03 08:35:59 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Assen Totin 2012-07-31 09:05:33 UTC
Description of problem:
Login failure due to incorrect password, followed by a correct login in the same session, results in corrupted file upload (at least for certain files). 

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1. Create a gzipped tar file from a directory by calling "tar cf..." and then "gzip..." on the tar file.

2. Connect to VsFTPd using default Linux command line FTP client (e.g., Fedora 17). Enter a correct username and incorrect password (login will be rejected). Without closing the session, enter "user <username>" (where <username> is the same username that have failed to log in) and then, when prompted, the correct password. 

3. Upload the tar.gzip file by calling "put ...tar.gz"

4. Check the size and MD5 of local and remote files. 

Actual results:

The file sizes and the MD5 checksums differ.
Expected results:

The file sizes and the MD5 checksums should be the same (the Linux console client has "bin" mode on by default).

Additional info:

1. If you log in properly at the first attempt, same file is transferred correctly. No need to specify "bin" mode explicitly. 

2. If you log in at the second attempt, but at some point issue a "bin" command, then all following file transfers are correct. 

3. Depending on the file contents and type, the uploaded file is sometimes _larger_ than the original one, which makes the initial suggestion that, for whatever reason, "ascii" mode is in effect, probably incorrect (ASCII mode should result in smaller, not larger, file).

Comment 1 Jiri Skala 2012-07-31 14:54:42 UTC
thanks for reporting.

I'd like to ask you if you tested another FTP client. I recommend lftp.

Thanks & Best regards


Comment 2 Assen Totin 2012-08-01 16:41:56 UTC

I have not tested with other FTP client for a reason - not many FTP clients have an interactive shell; in particular, lftp only logs onto the remote server after you actually try to upload/download something, so the situation as I described it cannot be repeated with lftp.

However, before reporting here I did test against different FTP server in order to check whether this is client's or server's fault. Same FTP client and same test case against NcFTPd (www.ncftpd.com) produces properly uploaded file. 

For the sake of completeness, I think I have somewhere a copy of RH7 (Guinness), which used wu-ftpd - I might try this too :)

Comment 3 Jiri Skala 2013-04-27 11:13:41 UTC
I'm not able to reproduce it. The ftp hangs after the second password insertion. Please, could you provide me an output of this grep:

# grep -v '^#\|^$' /etc/vsftpd/vsftpd.conf

Do you have a content in the file ~/.netrc on your client system? If so I'd like to see it.

The recommended lftp works fine for me. So It would be helpful to provide me an output of 'lftp -du <username> <server>' too.

Thanks, Jiri

Comment 4 Assen Totin 2013-04-28 17:14:17 UTC
Still 100% reproducible for me (clint is now ftp console client on F18 since F17 was long time ago). 

As I wrote: attempt logon once with wrong password, then (when prompt returns) force a second logging by sending the 'username xxx' command and enter your correct password when prompted. Upload a file, then download it (first is the original file, second is what I get after uploading and downloading it; filesystem is the same): 

File before uploading: 

[root@archimed ~]# ls -l rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm 
-rw-r--r-- 1 root root 2745140 Feb 27 19:59 rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm

File on the server: 

ftp> ls
227 Entering Passive Mode (217,75,128,2,186,204)
150 Here comes the directory listing.
-rw-r--r--    1 558      558       2755620 Apr 28 16:59 msttcorefonts-2.5-1.noarch.rpm
226 Directory send OK.

File after downloading: 

[root@archimed ~]# ls -l msttcorefonts-2.5-1.noarch.rpm 
-rw-r--r-- 1 root root 2755620 Apr 28 19:59 msttcorefonts-2.5-1.noarch.rpm

No even need to md5 as files are clearly of a different size. 

Can't help you with the vsftpd.conf as I no longer have SSH access to the server (SSH access is restriced by IP address). From what I see, some for of virtual chroot is configured as I cannot get up my home directory. 

I have no .netcr in my home directory (dedfault hoem directory as created by the 'adduser' on Fedora 17 and 18). 

lftp even with debug does not reveal anything to me:

[root@archimed ~]# lftp -du assen server.domain.com
lftp assen.com:~> 

lftp may somehow be mitigating the issue but, as I wrote before, it is 100% reproducible by using yet another client, the NcFTP client. Can't buy the idea of only using lftp against vsftpd.

Comment 5 Jiri Skala 2013-04-29 06:46:42 UTC
as I wrote I'm currently not able to reproduce it. So I need more data that will lead to identifying the issue. Please, do understand my recommendation to use lftp at least as a workaround to be able to get files correctly.

You "can't buy the idea of only using lftp ..." but I didn't read if lftp works fine for you without any issue. Please, do clear me up this question.

I'd like to see debug logs from 'lftp -du assen server.domain.com'. Entering a password doesn't produce logs. You have to continue putting commands (ls, get, etc.). The logs could help me to reproduce the issue. I'm not able to do anything without reproducer. If the lftp works fine we can't predicate vsftpd is buggy.

Thanks, Jiri

Comment 6 Jiri Skala 2013-12-03 08:35:59 UTC
There are no answers to comment #5, no vsftpd.conf. I don't have enough data to investigate. So I'm going to close this bug.
You can reopen it when the difficulties persist and the desired data is available.

Note You need to log in before you can comment on or make changes to this bug.