NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: bin/38327: uu{en,de}code - any reason to use non-portable [sg]etprogname?



The following reply was made to PR bin/38327; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: Aleksey Cheusov <cheusov%tut.by@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost, 
netbsd-bugs%netbsd.org@localhost
Subject: Re: bin/38327: uu{en,de}code - any reason to use non-portable 
[sg]etprogname?
Date: Sun, 6 Apr 2008 03:18:00 +0000

 On Sat, Mar 29, 2008 at 07:42:55PM +0200, Aleksey Cheusov wrote:
  > >>  Using setprogname(argv [0]) may be dangerous for SUID programs.
  > >>  Invalid argv [0] may be passed through execv(2).
  > >  
  > >  More to the point, using getprogname() may be dangerous in setugid
  > >  programs. The information comes from argv[0] in any event. Have you
  > >  found any problematic uses?
  > 
  > No. I'm not security Wizard.
  > 
  > For paranoids
  > void setprogname (const char *name)
  > {
  >    if (i_am_paranoid){
  >       if (geteuid () == 0 && getuid () != 0 ||
  >           getegid () == 0 && getgid () != 0)
  >       {
  >          generate error message;
  >          exit (1);
  >       }
  >    }
  > 
  >    ...
  > }
 
 That won't work right - you need to use issetugid(), or it won't catch
 wrong code like this:
 
    seteuid(getuid());
    setprogname(argv[0]);
       ...
    seteuid(0);
    strcpy(insecure_buffer, getprogname());
 
 However, it's not the right thing anyway. In NetBSD, setprogname is
 always called from the startup code (crt0) and it's the obligation of
 setugid programs to not misuse the string returned from getprogname().
 
 Since in general it's only used for printing error messages, it
 doesn't allow an attacker to do anything they can't do more easily
 with /bin/echo.
 
 If it's used for much of anything else, with the possible exception of
 a few programs that treat magic values of argv[0] as command-line
 options, it's probably a bug anyhow.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost
 


Home | Main Index | Thread Index | Old Index