-
Notifications
You must be signed in to change notification settings - Fork 467
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CUPS 1.1.22 lppasswd ignores write #1023
Comments
CUPS.org User: twaugh.redhat How about the attached patch? |
CUPS.org User: mike SIGXFSZ isn't portable... Anyways, I think simple checks on the open, write, and close calls should be enough to fix things - new patch coming up... |
CUPS.org User: mike OK, try str1023esp.patch, which checks that fd's 0, 1, and 2 are open, ignores many signals (including SIGXFSZ if it is defined), and does a lot better error handling along the way to ensure that passwd.new is never left behind. |
CUPS.org User: twaugh.redhat If it just ignores the signal won't it truncate the password file? |
CUPS.org User: mike No, by ignoring the signals we prevent interruption and possible truncation. If we hit the filesize limit, we get an error back from fputs() and abort cleanly. An alternate implementation would be to provide a signal handler which removes the passwd.new file, however you'd still have the open files and renaming to deal with... |
"str1023.patch": |
"cups-str1023.patch": --- cups-1.1.22/systemv/lppasswd.c.str1023 2004-02-25 20:14:54.000000000 +0000 #include <cups/cups.h> static void usage(FILE *fp); +static int must_exit;
/*
/*
/*
/*
|
"str1023esp.patch": Index: lppasswd.cRCS file: /development/cvs/cups/systemv/lppasswd.c,v +#ifndef WIN32 /*
/*
/*
+#ifndef WIN32
@@ -275,6 +334,8 @@
/*
fclose(outfile); @@ -297,6 +358,11 @@
if (infile)
if (op == CHANGE &&
- fclose(infile);- fclose(outfile);- unlink(passwdnew);
/*
unlink(passwdold);
/*
if (rename(passwdnew, passwdmd5) < 0)
|
Version: 1.1.22
CUPS.org User: d.j.bernstein
Bartlomiej Sieka, a student in my Fall 2004 UNIX Security Holes course,
has discovered several security problems in how lppasswd, version 1.1.22
(current), edits /usr/local/etc/cups/passwd. I'm publishing this notice,
but all the discovery credits should be assigned to Sieka.
First, lppasswd blithely ignores write errors in fputs(line,outfile) at
lines 311 and 315 of lppasswd.c, and in fprintf(...) at line 346. An
attacker who fills up the disk at the right moment can arrange for
/usr/local/etc/cups/passwd to be truncated.
Second, if lppasswd bumps into a file-size resource limit while writing
passwd.new, it leaves passwd.new in place, disabling all subsequent
invocations of lppasswd. Any local user can thus disable lppasswd by
running the attached program 63.c.
Third, line 306 of lppasswd.c prints an error message to stderr but
does not exit. This is not a problem on systems that ensure that file
descriptors 0, 1, and 2 are open for setuid programs, but it is a
problem on other systems; lppasswd does not check that passwd.new is
different from stderr, so it ends up writing a user-controlled error
message to passwd if the user closes file descriptor 2.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
The text was updated successfully, but these errors were encountered: