Globus Toolkit

GridFTP acts as wrong user when user doesn't exist

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 5.2.1
  • Fix Version/s: 5.2.2, Sprint 2012-05-22
  • Component/s: GridFTP
  • Labels:
    None
  • Ranking:
    Issue can not be ranked. 

Description

We're using GridFTP from GT 5.2.1 and we (Doug Strain and Neha Sharma) found an interesting bug. Normally, GridFTP maps me to the user that I am mapped to in the grid-mapfile. For instance, when I'm mapped like this:

"/DC=org/DC=doegrids/OU=People/CN=Alain Roy 424511" alainroy

I'm mapped to the alainroy user. I can easily tell which user it is with UberFTP, though the client is irrelevant:

% uberftp fermicloud084
220 fermicloud084.fnal.gov GridFTP Server 6.5 (gcc64, 1323378368-83) [unknown] ready.
230 User alainroy logged in.
UberFTP> pwd
/cloud/login/alainroy

However, if I'm mapped to a user that doesn't exist, GridFTP appears to pick the last user in /etc/passwd. For example, when alainroy is misspelled:

"/DC=org/DC=doegrids/OU=People/CN=Alain Roy 424511" alainroyy

I'm mapped to the tomcat user:

% uberftp fermicloud084
220 fermicloud084.fnal.gov GridFTP Server 6.5 (gcc64, 1323378368-83) [unknown] ready.
230 User alainroyy logged in.
UberFTP> pwd
/usr/share/tomcat5

apparently because Tomcat is the last user in the passwd file:

% tail -1 /etc/passwd
tomcat:x:91:91:Tomcat:/usr/share/tomcat5:/bin/sh

Another example:

% globus-url-copy file:///cloud/login/alainroy/shar.pl gsiftp://fermicloud084.fnal.gov/tmp/shar.pl
% ls -l /tmp/shar.pl
-rw-r--r-- 1 tomcat tomcat 55051 May 17 12:11 /tmp/shar.pl

I would think that if the user doesn't exist, something safer would happen. Probably you should deny access.

Lest this seem like a rare condition, it's pretty common for people in OSG to mistakenly authorize users that don't have accounts. People authorize whole VOs because they authorize "everyone in OSG" but regularly forget to make any of the accounts for them. So this may well be a common problem and could cause security breaches. Definitely something to fix.

If you provide us with a patch, we can ship a patched version to OSG in advance of a new release from you.

Thanks!
-alain

Activity

Hide
Stuart Martin added a comment -
Alain notes that this bug is not in 4.0
Show
Stuart Martin added a comment - Alain notes that this bug is not in 4.0
Hide
Mike Link added a comment -
I see the problem and will have a patch soon.
Show
Mike Link added a comment - I see the problem and will have a patch soon.
Hide
Mike Link added a comment -
Patch attached. The problem was that we were improperly checking the return values from our getpw* wrapper functions.
Show
Mike Link added a comment - Patch attached. The problem was that we were improperly checking the return values from our getpw* wrapper functions.
Hide
Alain Roy added a comment -
This is great, thanks! We'll try the patch and let you know how it goes.
Show
Alain Roy added a comment - This is great, thanks! We'll try the patch and let you know how it goes.
Hide
Alain Roy added a comment -
I built a new GridFTP server with the patch, and I get much better behavior now:

% uberftp fermicloud084
220 fermicloud084.fnal.gov GridFTP Server 6.5 (gcc64, 1323378368-83) [unknown] ready.
530 Login incorrect. : Mapped user 'alainroyy' is invalid.

This was an incredibly fast response time. Thank you!

Show
Alain Roy added a comment - I built a new GridFTP server with the patch, and I get much better behavior now: % uberftp fermicloud084 220 fermicloud084.fnal.gov GridFTP Server 6.5 (gcc64, 1323378368-83) [unknown] ready. 530 Login incorrect. : Mapped user 'alainroyy' is invalid. This was an incredibly fast response time. Thank you!
Hide
Mike Link added a comment -
Great. Thanks for reporting it.
Show
Mike Link added a comment - Great. Thanks for reporting it.
Hide
Mike Link added a comment -
This is not limited to the 5.2 release. Threaded builds of all earlier releases would be affected as well.
The vulnerability is related to the use of getpwnam_r() in our wrapper library. That was used when certain autoconf macros were defined, which is the case in 5.2 and only threaded builds prior to 5.2 (*thr* in the flavor name).
Show
Mike Link added a comment - This is not limited to the 5.2 release. Threaded builds of all earlier releases would be affected as well. The vulnerability is related to the use of getpwnam_r() in our wrapper library. That was used when certain autoconf macros were defined, which is the case in 5.2 and only threaded builds prior to 5.2 (*thr* in the flavor name).

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: