Bugzilla Bug 72820

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There is buffer overflow in ncplogin and ncpmap in nwclient.c.


static void strcpy_cw(wchar_t *w, const char* s) {
~        while ((*w++ = *(const nuint8*)s++) != 0);
}

NWDSCCODE NWDSCreateContextHandleMnt(NWDSContextHandle* ctx, const
NWDSChar * treeName){
...
wchar_t wc_treeName[MAX_DN_CHARS+1];

~  if (!treeName)
~      return ERR_NULL_POINTER;

~  strcpy_cw (wc_treeName,treeName);

Currently i have not managed to successfully exploit this bug on x86.

How to reproduce :

ncplogin -T `perl -e '{print"a"x"330"}'`
ncpmap -T `perl -e '{print"a"x"330"}'` /

Tested on ncpfs-2.2.4-1 from fedora core 2

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBqxzaFTSet8AbQUQRAiycAJ4+5YDHawXMrXiu2wPHt6IRN2Xx0wCeM7vm
LpGHtO/7DHkoRO18OQwve4M=
=YwvU
-----END PGP SIGNATURE-----

Pulling net-fs for advice...

I don't know ncpfs so I can't tell if it's a real vulnerability or just an overflow in command-line argument that can be exploited by local users to execute code with their own rights (i.e. a bug, but not a vulnerability). Is ncplogin/ncpmap suid root ? Is the "-T" option argument directly under the control of a remote attacker ?

-rws--x--x  1 root root 2529574 Nov 29 23:19 /usr/bin/ncplogin
-rws--x--x  1 root root 2424639 Nov 29 23:19 /usr/bin/ncpmap

All I have time for right now.

Hmm interesting.
So it's a potential local root through overflow on a SUID root binary.

No fixed version yet. Upstream should be contacted for a fixed version, if they don't react it looks like an easy patch.

Upstream has just released a 2.2.5 version
(ftp://platan.vc.cvut.cz/pub/linux/ncpfs/Changes-2.2.5)
From the changelog:

ChangeSet@1.294, 2004-11-30 16:42:25+01:00
  Fix bad buffer overflow in NWDSCreateContextHandleMnt.  Plus fix
  bogus interpretation of treeName.  And split 
  NWDSCreateContextHandleMnt into two functions, anything taking string
  as argument must take context, as string's encoding is defined by 
  context settings...

strcpy_cw is still present in the source, but it is no longer called. The 
treename input is now handled in a completely different way.

!!! NOTE: I'm not saying that it fixes the problem, I'm just saying that it
looks like they have worked on it !!!

Please provide an ebuild for that version, we'll test that the vulnerability is
gone there.

It'll take another 20 hours or so before I get a chance to do the ebuild.
If anyone else can do it sooner, go right ahead. I'm not the maintainer anyway.

Version 2.2.5 is now in portage. The build succeeds, but that is all I can
test.
All keywords have been reverted to "~arch", only x86 and ppc64 have ever been 
"arch". They should test this and mark it stable if it works.

Thx Maurice.

Arches please mark 2.2.5 stable asap.

Created an attachment (id=45113) [details]
Access violation output

Hi. I'm getting an access violation with 2.2.5. I don't get this with latest
stable marked version (2.2.3).

Back to ebuild status. Maurice please look into this.

I'm unable to reproduce this, though I am using the sandbox.
Corsair, can you do some debugging yourself and/or provide more info, such as emerge --info?

The most likely candidate for a sandbox violation is the chmod a+r that I do on
the directory to which the source is extracted. I have to do that because the 
directory does not have the +r bits set in the tarball. 

If someone could contact upstream to see if they can make another tarball with the
right permissions, then we can use the same ebuild as for 2.2.3 and we shouldn't
encounter any problems.

I wasn't paying attention before; somehow I overlooked Markus' log file.

The problem is not the absence of the +r bit in the tarball, it's the 
installation of a php extension. This extension is only built if php is 
installed when ncpfs is merged.

It would help if someone familiar with php extensions (and the eclasses) could 
take a look at this. Besides, I will be away this weekend.

Stuart/php please advise.

I've committed an updated ebuild which no longer causes a sandbox violation. 
I've also added support for the php USE flag.

Best regards,
Stu

Thx Stuart.
x86, ppc64 : please retest the updated ncpfs-2.2.5...

stable on ppc64

GLSA drafted. 

x86, we are waiting for you to release... If someone else (net-fs / Stuart) can test and mark stable on x86, I'll take it :)

Marked this x86 per jaervosz's request. Been using 2.2.5 since it was added,
with no problems.

GLSA 200412-09