Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 77414 - net-fs/ncpfs CAN-2005-001{3,4}: Multiple issues
Summary: net-fs/ncpfs CAN-2005-001{3,4}: Multiple issues
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B2 [glsa] jaervosz
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-10 13:36 UTC by Sune Kloppenborg Jeppesen
Modified: 2005-01-30 10:58 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
CAN-2005-0013+4.patch (CAN-2005-0013+4.patch,25.16 KB, patch)
2005-01-15 10:57 UTC, Sune Kloppenborg Jeppesen
no flags Details | Diff
CAN-2005-0013.patch (CAN-2005-0013.patch,450 bytes, patch)
2005-01-16 14:27 UTC, Sune Kloppenborg Jeppesen
no flags Details | Diff
CAN-2005-0014.patch (CAN-2005-0014.patch,899 bytes, patch)
2005-01-16 14:28 UTC, Sune Kloppenborg Jeppesen
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sune Kloppenborg Jeppesen gentoo-dev 2005-01-10 13:36:01 UTC
Erik Sj
Comment 1 Sune Kloppenborg Jeppesen gentoo-dev 2005-01-10 13:36:01 UTC
Erik Sjölund discovered two vulnerabilities in programs contained in ncpfs:

CAN-2005-0013 Unauthorised file access in ncpfs 2.2.x
CAN-2005-0014 Buffer overflow in ncpfs 2.2.5.

I've also contacted the upstream maintainer.

Erik Sjölund wrote:
> On debian stable,
> as root do the following
> 
> # apt-get install ncpfs
> # touch /tmp/foo
> # chmod 600 /tmp/foo
> # ls -l --full-time --time=atime /tmp/foo
> -rw-------    1 root     root            0 Fri Jan 07 10:51:55 2005
> /tmp/foo
> 
> then as a user do the following
> 
> $ cd ~
> $ mkdir foodir
> $ ln -s /tmp/foo .nwclient
> $ ncpmount foodir
> ncpmount: Connection to specified server does not exist (0x880F) in
> find_conn_spec
> 
> Then check if the access time of the file has changed. As root do,
> 
> # ls -l --full-time --time=atime /tmp/foo
> -rw-------    1 root     root            0 Fri Jan 07 10:54:45 2005
> /tmp/foo

I couldn't confirm this in a chroot environment but other factors may
have mitigated the problem.

> The file /tmp/foo was read and thus its file permissions were violated. 
> Now what happens if a user links to an interesting device file instead?
> ( I didn't test this though )
> 
> Instead of a soft symlink the same can be achieved with a hard symlink.

(symlink || hardlink)

> the relevant code piece is in the function ncp_fopen_nwc() in the
> file ncpfs-2.2.0.18/lib/ncplib.c
> 
> The problem is that it doesn't check that the file ownership matches
> getuid().

This is CAN-2005-0013.

This patch should be sufficient:

--- ncpfs-2.2.0.18.orig/lib/ncplib.c
+++ ncpfs-2.2.0.18/lib/ncplib.c
@@ -2210,6 +2210,10 @@
                *err = errno;
                return NULL;
        }
+        if (st.st_uid != getuid()) {
+                *err = EACCES;
+                return NULL;
+        }
        if ((st.st_mode & (S_IRWXO | S_IRWXG)) != 0) {
                *err = NCPLIB_INVALID_MODE;
                return NULL;

> Then to make it safer: Maybe ncpfs shouldn't allow ~/.nwclient to be a
> link either. And maybe ncpfs should not trust the HOME variable because
> it is a setuid program.

Yes.

It would also be a good idea to drop privileges, read the file, regain
privileges to fulfil the task that requires root, and maybe drop them
again when they are not needed anymore.  (--> Hint for Petr as upstream)

I'm not sure disallowing ~/.nw* being a symlink would buy us any
security.  (I'm rather sure that it doesn't, but it's always good
to discuss the possibilities)

> Now a look at the situation with ncpfs 2.2.5 ( not in debian stable )
> ------------------------------------------------
> 
> The source code has been restructured, new file names and new function
> names but the exploit still exist there.
> 
> First as root create a file:
> 
> # touch /tmp/foo
> # chmod 600 /tmp/foo
> 
> Then as a user
> 
> $ export HOME=/tmp
> $ ln /tmp/foo $HOME/.nwinfos
> $ ls -l --full-time --time=atime /tmp/foo
> -rw-------  2 root root 0 2005-01-05 20:13:09.822116800 +0100 /tmp/foo
> $ ncplogin
> failed:Cannot attach to tree e:. Err:Server not found (0x8847)
> $ ls -l --full-time --time=atime /tmp/foo
> -rw-------  2 root root 0 2005-01-05 20:13:55.147983129 +0100 /tmp/foo
> 
> readnwinfosfile() in lib/nwclient.c
> does trust $HOME blindly and opens $HOME/.nwinfos and reads lines with
> fgets()

This is also CAN-2005-0013.

Similar patch:

--- ncpfs-2.2.5.orig/lib/nwclient.c
+++ ncpfs-2.2.5/lib/nwclient.c
@@ -482,6 +482,10 @@
                 *err = errno;
                 return NULL;
         }
+        if (st.st_uid != getuid()) {
+                *err = EACCES;
+                return NULL;
+        }
         if ((st.st_mode & (S_IRWXO | S_IRWXG)) != 0) {
                 *err = NCPLIB_INVALID_MODE;
                 return NULL;

> And now another thing present in ncpfs-2.2.5 but not in ncpfs-2.2.0
> --------------------------------------------------------------------
> 
> In the file: ncpfs-2.2.5/sutil/ncplogin.c
> 
> static int opt_set_volume_after_parsing_all_options(struct
> ncp_mount_info* info) {
> char tmpNWPath[1024];
> int e;
> 
> /* we DID check in main that -V has been specified !*/
> strcpy(tmpNWPath,info->remote_path);
> if (info->root_path) {
>    strcat(tmpNWPath,"/");
>    strcat(tmpNWPath,info->root_path);
> }
> 
> It seems root_path comes from the command line with no length check
> done. Potential buffer overflow. But this function is called some way
> into the program so I think without having any Novell NetWare servers it
> is hard to try this buffer overflow out.

This is CAN-2005-0014.

Proposed patch:

--- ncpfs-2.2.5.orig/sutil/ncplogin.c
+++ ncpfs-2.2.5/sutil/ncplogin.c
@@ -166,10 +166,11 @@
                int e;
 
                 /* we DID check in main that -V has been specified !*/
-                strcpy(tmpNWPath,info->remote_path);
+                memset(tmpNWPath,0,sizeof(tmpNWPath));
+                strncpy(tmpNWPath,sizeof(tmpNWPath)-1,info->remote_path);
                 if (info->root_path) {
-                        strcat(tmpNWPath,"/");
-                        strcat(tmpNWPath,info->root_path);
+                        strncat(tmpNWPath,"/",sizeof(tmpNWPath)-strlen(tmpNWPath)-1);
+                        strncat(tmpNWPath,info->root_path,sizeof(tmpNWPath)-strlen(tmpNWPath)-1);
                 }
                 /* I keep forgeting typing it in uppercase so let's do it here */
                 str_upper(tmpNWPath);
Comment 2 Sune Kloppenborg Jeppesen gentoo-dev 2005-01-15 10:57:54 UTC
Created attachment 48563 [details, diff]
CAN-2005-0013+4.patch

Upstream patch for the 2.2.6 release of ncpfs.
Comment 3 Thierry Carrez (RETIRED) gentoo-dev 2005-01-15 12:50:41 UTC
Maurice: this is confidential. Could you please test the patches and prepare an ebuild ? We can't commit it to portage until disclosure date, so please attach it here if it's ready. We'll call arch testing on the bug.
Comment 4 Maurice van der Pot (RETIRED) gentoo-dev 2005-01-16 12:00:01 UTC
A couple of questions: 
- where is 2.2.6?
- what do you want me to test? (I never used ncpfs)
- jaervosz made the patch and seems to have tested it. Isn't he the right person
to fix the ebuild?
Comment 5 Sune Kloppenborg Jeppesen gentoo-dev 2005-01-16 12:43:29 UTC
Maurice,
- probably going to be released soon
- you committed the last security fix for ncpfs (anyone from net-fs using this?)
- patch is from upstream, I only passed it on

Patches in the initial description is for the Debian.



Comment 6 Maurice van der Pot (RETIRED) gentoo-dev 2005-01-16 13:32:07 UTC
1 & 3) So does this mean: 
a) 2.2.6 will already include this fix and we just need to prepare a fixed 2.2.5 
   ebuild right away
 or
b) 2.2.6 will not include the fix for some reason and we need to patch it when it
   comes out

2) I'm not aware of anyone using it. Currently net-fs has 3 people listed: 
rphillips (don't know about him), vapier (only helps with nfs-related stuff) and 
latexer (don't know anything about him either). I am not part of net-fs myself.
Comment 7 Sune Kloppenborg Jeppesen gentoo-dev 2005-01-16 14:27:59 UTC
Created attachment 48689 [details, diff]
CAN-2005-0013.patch

Patch for 2.2.5 from initial bug report above.
Comment 8 Sune Kloppenborg Jeppesen gentoo-dev 2005-01-16 14:28:39 UTC
Created attachment 48690 [details, diff]
CAN-2005-0014.patch
Comment 9 Thierry Carrez (RETIRED) gentoo-dev 2005-01-17 05:25:56 UTC
If nobody uses this better wait for disclosure so that we can handle it in the open.
Comment 10 Sune Kloppenborg Jeppesen gentoo-dev 2005-01-27 12:07:23 UTC
Maurice, upstream has a fixed version. Please bump.
Comment 11 Maurice van der Pot (RETIRED) gentoo-dev 2005-01-28 09:42:58 UTC
I'll be unable to test beyond just emerging it, so I'll just check in as stable
if it merges successfully. Please respond with any objections before I get to 
repoman commit ;)
Comment 12 Thierry Carrez (RETIRED) gentoo-dev 2005-01-28 12:00:37 UTC
Maurice: if in doubt you can commit it as ~* or -*, and we'll ask for arches to test.
Comment 13 Maurice van der Pot (RETIRED) gentoo-dev 2005-01-28 17:20:35 UTC
ppc64 arch people, please test 2.2.6 as far as possible and then mark it stable for your arch.
Comment 14 Markus Rothe (RETIRED) gentoo-dev 2005-01-29 00:42:38 UTC
I have the same problem as in comment #10. But as this package merges fine and
the given programms "run" fine, I've marked it stable on ppc64.
Comment 15 Thierry Carrez (RETIRED) gentoo-dev 2005-01-30 10:58:22 UTC
GLSA 200501-44