-----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 attachment 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
