<!-- SBZ_reproduce  -->
see attachement.

Created attachment 16170 [details]
vendor-sec discussion

Created attachment 16171 [details]
wu-ftpd-CAN-2004-0148.diff

OK, thanx! I'll check it.

Date: Wed, 25 Feb 2004 13:26:35 -0800 
From: Matt Zimmerman <mdz@debian.org> 
To: vendor-sec@lst.de 
Subject: [vendor-sec] Re: [Security bug in wu-ftpd 2.6.2, users breaking out 
with chmod] 
 
On Tue, Feb 17, 2004 at 09:50:11PM -0800, Matt Zimmerman wrote: 
 
> This just came in; I've assigned it CAN-2004-0148.  Based on past experience 
> I have some doubt that we'll hear from the upstream maintainers, but the 
> submitter says that he contacted them already. 
 
Oh, it's worth mentioning that this bug doesn't appear to be present (based 
on my reading of the code and not any actual testing) if you build with 
-DPARANOID. 
 
-- 
 - mdz 
 

Yes,
in PARANOID mode it is not allowed for normal users to login if their
$HOME doesn't exists - the complete sequence is (now):

    if (!anonymous && !guest) {
        if (chdir(pw->pw_dir) < 0) {
#ifdef PARANOID
#ifdef VERBOSE_ERROR_LOGING
            syslog(LOG_NOTICE, "FTP LOGIN FAILED (cannot chdir) for %s, %s",
                   remoteident, pw->pw_name);
#endif
            reply(530, "User %s: can't change directory to %s.",
                  pw->pw_name, pw->pw_dir);
            goto bad;
#else
            if (restricted_user || chdir("/") < 0) {
#ifdef VERBOSE_ERROR_LOGING
                syslog(LOG_NOTICE, "FTP LOGIN FAILED (cannot chdir) for %s, %s",
                       remoteident, pw->pw_name);
#endif
                reply(530, "User %s: can't change directory to %s.",
                      pw->pw_name, pw->pw_dir);
                goto bad;
            }
            else {
                lreply(230, "No directory! Logging in with home=/");
#ifdef ALTERNATE_CD
                home = defhome;
#endif
            }
#endif
        }
    }


And the fix seems to work fine:

220 E212.suse.de FTP server (Version wu-2.6.0(1) Thu Feb 26 09:22:29 GMT 2004)
ready.
Name (localhost:root): htester
331 Password required for htester.
Password:
230-No directory! Logging in with home=/
230 User htester logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> quit

220 E212.suse.de FTP server (Version wu-2.6.0(1) Thu Feb 26 09:22:29 GMT 2004)
ready.
Name (localhost:root): htester
331 Password required for htester.
Password:
530 User htester: can't change directory to /home/htester.
ftp: Login failed.
ftp> quit
221 Goodbye.

BTW:
The wuftpd-2.4 version doesn't have the restricted-{uid,gid}
options (chroot emulation ;-).

Created attachment 16202 [details]
adopted CAN-2004-0148 diff for wu-ftpd-2.6.0 in sles7

adopted CAN-2004-0148 diff for wu-ftpd-2.6.0 in sles7
(wu-ftpd-2.6.0-CAN-2004-0148.dif)

checked in into SLES7-s390x, SLES7-PPC, SLES7

Thank you. 
Submitted Laufzettel. 
 

Date: Thu, 26 Feb 2004 19:08:29 +0100 (CET)
From: Thomas Biege <thomas@suse.de>

Hi,
hier ist noch einer... ich kann den aber erst Montag eintueten.

---------- Forwarded message ----------
Date: Thu, 26 Feb 2004 11:44:32 +0000 (GMT)
From: Mark J Cox <mjc@redhat.com>
To: Solar Designer <solar@openwall.com>
Cc: vendor-sec@lst.de
Subject: Re: [vendor-sec] Sharing details of public issues

> For me, it's the latter which matters.

So here is another wu-ftpd issue that folks might have overlooked;
probably worth fixing at the same time as the new wu-ftpd CAN-2004-0148   
issue.

http://www.securiteam.com/unixfocus/6X00Q1P8KC.html
ftp://ftp.wu-ftpd.org/pub/wu-ftpd/patches/apply_to_2.6.2/skeychallenge.patch

CVE applied for

Mark

_______________________________________________
Vendor Security mailing list

The skeychallenge.patch is not needed in our versions - already
fixed in wu-ftpd-2.6.0-tom.dif and wu-ftpd-2.4.2-beta-18.dif.

<!-- SBZ_reopen -->Reopened by hmuelle@suse.de at Thu Apr  1 13:10:47 2004, took initial reporter thomas@suse.de to cc

No reaction by security-team or Marius to mail - setting to blocker now for
waking up  - could be reduced to critical afterwards:

------------------------------------------------------------------------------
cc'ed Marius and the security-team for information - i will not reject
the update _yet_, maybe we can fix it without rejecting...

On Thu, Mar 18, Sebastian Vollath wrote:

> SLES7-PPC
> ---------

[.. prodtpd ..]
>  wuftpd:
>  -------
>  Failed dependencies: needs ftpdir.
>  wuftpd (like proftd) wasn't shipped with sles7-ppc, but is released as update
>  in the sdb. While proftpd rpm can be applied, all wuftpd updates in the sdb
+are
>  missing ftpdir package.
>  So we should provide a ftpdir package for ppc, too.
------------------------------------------------------------------------------

Hi Marius, 
can you comment on this, I do not know enough about this situation. 

Not really, sorry!
I can't because I do not know what's the problem is or what I can do here.

Both, "is_maintained proftpd" as well as "is_maintained wuftpd" shows the
sles7-ppc distribution in the output.

As far as I can see, the proftpd tests was successfull. (proftpd does not
need the stuff from ftpdir [mostly ls binary], because it uses internal ls
function / command).
I don't know what's the problem is here. Nobody explained it to me.


The wuftpd package allways needed the ftpdir package (to be able to run in
a chroot). OK, it was forgotten and shipped via update...

Why not to install the ftpdir package before the test?

You can't have any system with installed wuftpd and no ftpdir (except you
have used the broken "yast2 -i wuftpd" command that ignores any dependency).
You write "sdb update" - what does this mean. Is the ftpdir package not
avaliable via "you update" ?

I do not understand what the problem really is or what I can do here?

There was no problem with it in the last wuftpd update we've done...

Can somebody from QA team explain what happend here?

wuftpd is not on 9.1.  So, closing.

<!-- SBZ_reopen -->Reopened by hmuelle@suse.de at Thu Apr  1 15:08:12 2004

Sorry, i haven't seen that it wasn't set to Enterprise Server.
The bug hits only SLES7 all architectures.

Hmm...
Still no description from QA-Team what's the problem really is.

First problem:
I don't know why hmuelle reopened _this_ bug report.
I don't know the email, hmuelle sent to you.

Second problem:
You don't understand comment #14 (which is ph not related to this bug), and you
don't know sles7-ppc.

Third problem:
I don't know what to explain. My description in comment #14 is clear, and
related to the maintenace web and sles7-ppc.

Comment #14 is related to this bug as it is the bug for tracking the security
fix/update!

If a package has new(?) dependencies and it causes trouble during a YOU update,
it is 

a) a bug of the packages itself

b) a bug of the patchinfo as it has to solve this new dependency

c) a (known) bug as the unsolved dependency existed before and isn't new

Could someone tell me if it is (a), (b) or (c) than i could make a suggestion
how to solve the problem.

I can't reproduce myself or help as i have no PPC-machine or LPAR to test.
Marcus are you able to enligten us?

ad Comment #21)
   the mail from Comment #14

ad Comment #22)
   it is case 'c'.

   As I already wrote in Comment #16, wuftpd has (since 6.x) _allways_
   required the ftpdir package. As far as I understand the problem, the
   ftpdir package was forgotten on sles7-ppc and shipped later via update.

   Whatever happened, you can't have an allready installed wuftpd without
   ftpdir, except you've ignored the wuftpd dependencies earlier and now
   try to update it with dependencies.
   I mean, this is happened while test:
       yast2 -i wuftpd  (AFAIK ignores dependencies) => OK
       yast2 online_update or rpm -Uvh wuftpd.rpm    => failure

Solution => provide a patch including ftpdir package ?

- ftpdir is on the sles7 PowerPC CD2, i checked schell/CD-ARCHIVE/SLES7/....  
- there is no new dependenc. The wuftpd.rpm on the CD already required ftpdir  
  
So what is the exact problem?  
  
So Comment#14 is wrong:  
>  Failed dependencies: needs ftpdir.  
  
        It does.  
  
>  wuftpd (like proftd) wasn't shipped with sles7-ppc,   
  
        It was on CD2.  
  
> but is released as update  
>  in the sdb. While proftpd rpm can be applied, all wuftpd updates in the sdb  
+are  
>  missing ftpdir package.  
  
        The ftpdir needs to be installed from the CD2, just like  
the original wuftpd.rpm.  
 

-> QA did not test correctly I think. 

Don't know. IMO QA-Team "emulates" users, so it can't fix this itself
if it is not possible inside of you...

OK,
we mean to know what is happened here, Harald will fix the dependency
problem with the ppc people.

Ah... a collision happened and I've seen only Comment #26.

Yes, in this case (Comment #25) QA Test was wrong, since
the package _was_ avaliable...

take it for release tracking

Oh yes it is. There is no sles7-ppc CD2. It is the "Source Code" CD. The binary
packages for wuftpd and ftpdir are on the sles7 "SOURCE CODE" CD for ppc.

This is great, well done. It is really a testing error. sorry !

It could have been under my chair, but it _was_ on the source cd.
I bet there was an email, 3 years ago, where I could have read this great
information.

mt@e212:~ > find /mounts/schnell/CD-ARCHIVE/SLES7/sles7-ppc-RC5/ -name "ftpdir*"
/mounts/schnell/CD-ARCHIVE/SLES7/sles7-ppc-RC5/CD2/suse/n2/ftpdir.rpm
/mounts/schnell/CD-ARCHIVE/SLES7/sles7-ppc-RC5/CD2/suse/zq1/ftpdir.spm
/mounts/schnell/CD-ARCHIVE/SLES7/sles7-ppc-RC5/CD2/suse/contents/ftpdir
/mounts/schnell/CD-ARCHIVE/SLES7/sles7-ppc-RC5/CD2/full-names/ppc/ftpdir-2001.10.22-4.ppc.rpm
/mounts/schnell/CD-ARCHIVE/SLES7/sles7-ppc-RC5/CD2/full-names/src/ftpdir-2001.10.22-4.src.rpm

As you can see, it was there. But this is not the only point.

You can't have any installed wuftpd package without ftpdir.
If this is the case, you have ignored the dependencies before
and you can't update propelly now. That easy is this.

I know, you'll be very surprised, if I tell you that there was no wuftpd package
in the system. I never stated that there was wuftpd on the system, I don't know
why you are thinking that dependencies were ignored.
Customers do not install from schnell. The product has no CD2 - it is labled
"Source Code".
But don't mind, SUSE seems to have a budget for its broken and braindead
processes, otherwise things would change.

I don't see where CD2 of sles7-ppc is labeled "Source CD", but it actually
doesn't really matter. Can we live with the facts please?
For my understanding, it was noone's fault....

Roman.

Packages are released now - i will close this bug as solved fixed

Thanx!

CVE-2004-0148: CVSS v2 Base Score: 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C)