[1358] in linux-security and linux-alert archive
[linux-security] Re: vixie-crontab for redhat linux (Fix)
daemon@ATHENA.MIT.EDU (Christopher Oliver)
Tue Dec 17 07:41:19 1996
From: oliver@fritz.co.traverse.com (Christopher Oliver)
To: linux-security@redhat.com
Date: Mon, 16 Dec 1996 23:07:43 -0500 (EST)
Cc: jwuerfel@ptway.com
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
[Mod: Sent to linux-security instead of linux alert -- alex]
Dave G. <daveg@ESCAPE.COM> wrote:
> /* vixie crontab buffer overflow for RedHat Linux
> *
> * I dont think too many people know that redhat uses vixie crontab.
> * I didn't find this, just exploited it.
The vulnerability involves an unguarded sscanf call in env.c. Enlarging
the buffer to the largest possible input but restricting the length a
posteriori closes this particular problem:
diff -ru vixie-cron-3.0.1~/env.c vixie-cron-3.0.1/env.c
--- vixie-cron-3.0.1~/env.c Mon Dec 16 22:42:55 1996
+++ vixie-cron-3.0.1/env.c Mon Dec 16 22:55:52 1996
@@ -115,8 +115,9 @@
{
long filepos;
int fileline;
- char name[MAX_TEMPSTR], val[MAX_ENVSTR];
+ char name[MAX_ENVSTR], val[MAX_ENVSTR];
int fields;
+ int Error = 0;
filepos = ftell(f);
fileline = LineNumber;
@@ -128,8 +129,14 @@
name[0] = val[0] = '\0';
fields = sscanf(envstr, "%[^ =] = %[^\n#]", name, val);
- if (fields != 2) {
+ if (strlen(envstr) > MAX_TEMPSTR) {
+ Debug(DPARS, ("load_env, var name too long\n"))
+ Error = 1;
+ } else if (fields != 2) {
Debug(DPARS, ("load_env, not 2 fields (%d)\n", fields))
+ Error = 1;
+ }
+ if (Error != 0) {
fseek(f, filepos, 0);
Set_LineNum(fileline);
return (FALSE);
@@ -176,3 +183,4 @@
}
return (NULL);
}
+
--
Christopher Oliver Traverse Communications
Systems Coordinator 223 Grandview Pkwy, Suite 108
oliver@traverse.com Traverse City, Michigan, 49684
The loop macro: because no language is complete without a little COBOL.
