KSR[T] (ksrt@DEC.NET) Thu, 29 Jan 1998 05:29:22 -0800 Messages sorted by: [ date ][ thread ][ subject ][ author ] Next message: RHS Linux User: "Bug in IMail's pop3d32.exe" Previous message: Solar Designer: "Secure Linux patch" Next in thread: hurtta+zz@ozone.FMI.FI: "Re: KSR[T] Advisory #7: filter" KSR[T] Advisory #007 Date: Jan 29, 1998 ID #: filt-bof-007 Operating System(s): Any UNIX system running elm/filter Affected Program: filter ( part of the elm-2.4 package ) Problem Description: This advisory covers two vulnerabilities in the filter program. The first is in the function save_embedded_address(), filter will use a while() loop to copy a 5120 byte into a 512 byte automatic variable. This is the From: or in the Reply-To: line in an email message. The second is in the function get_filter_rules(), there is a stack overrun when the function blindly strcpy()s the variable filterfile( which is obtained via the command line parameter '-f' ), into an automatic variable. Compromise: The first problem could potentially be exploited remotely depending upon how the victim's machine's Mail Transfer Agent handles From: or Reply-To: headers that are larger than 512 bytes. This would allow a remote attacker to run arbitrary commands as the user running filter, and possibly additional privileges that will allow the attacker to write to the mail spool directory. Both attacks can be performed locally, however they will only increase privileges if filter is running set-uid or set-gid (most notably Linux machines). This could allow a local user to read other users' mail spools and allows write access to the mail spool directory. The latter could potentially be used to interfere with the mail subsystem. Notes: This was not a full audit on the elm2.4 package, or filter for that matter. At a glance, there appear to be numerous security problems. The filter included in elm-2.4ME+37 also appears to be vulnerable to the "save_embedded_address()" attack, but not to the "get_filter_rules()" attack. Filter will not be a part of elm 2.5, and is not supported in any way at this time. It is the Elm group's recommendation that filter not be used. Patch/Fix: -*- Begin elm 2.4 filter patch -*- diff -u filter/filter.c filter.new/filter.c --- filter/filter.c Tue Feb 4 09:13:02 1997 +++ filter.new/filter.c Tue Feb 4 09:17:38 1997 @@ -429,7 +429,7 @@ **/ static int processed_a_reply_to = 0; - char address[LONG_STRING]; + char address[MAX_LINE_LEN + 1]; register int i, j = 0; /** first let's extract the address from this line.. **/ diff -u filter/parse.c filter.new/parse.c --- filter/parse.c Tue Feb 4 09:13:33 1997 +++ filter.new/parse.c Tue Feb 4 09:17:38 1997 @@ -172,7 +172,8 @@ struct condition_rec *cond, *newcond; - strcpy(filename,filterfile); + memset(filename, 0x0, SLEN ); + strncpy(filename,filterfile,( SLEN - 1 )); if ((fd = fopen(filename,"r")) == NULL) { if (outfd != NULL) -*- end elm 2.4 filter patch -*- -*- begin elm2.4+ME filter patch -*- --- filter/filter.c Tue Feb 4 09:13:02 1997 +++ filter.new/filter.c Tue Feb 4 09:17:38 1997 @@ -429,7 +429,7 @@ **/ static int processed_a_reply_to = 0; - char address[LONG_STRING]; + char address[MAX_LINE_LEN + 1]; register int i, j = 0; /** first let's extract the address from this line.. **/ -*- end elm2.4+ME filter patch -*-