[4000] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Patches for 2.1.6-RELEASE locale stuff...

daemon@ATHENA.MIT.EDU (Wojtek Pilorz)
Tue Feb 4 10:42:18 1997

Date: 	Tue, 4 Feb 1997 08:49:11 +0100
Reply-To: Wojtek Pilorz <wpilorz@CELEBRIS.BDK.LUBLIN.PL>
From: Wojtek Pilorz <wpilorz@CELEBRIS.BDK.LUBLIN.PL>
X-To:         tenser@SPITFIRE.ECSEL.PSU.EDU
To: BUGTRAQ@netspace.org
In-Reply-To:  <19970204040601.1016.qmail@spitfire.ecsel.psu.edu>

Hi,

I believe that your patches have still some security problems,
as you ignore return value from snprintf.
Please find a few lines from FreeBSD snprintf man page:
     int
     snprintf(char *str, size_t size, const char *format, ...)
[...]
     Snprintf() and vsnprintf() will write at most size-1 of the
     characters printed into the output string (the size'th character then
     gets the terminating `\0'); if the return value is greater than or equal
     to the size argument, the string was too short and some of the printed
     characters were discarded.  Sprintf() and vsprintf() effectively assume
     an infinite size.

The effect might be that the attacker could prepare a long path
in PATH_LOCALE before executing a SUID program which would
cause arbitrary file on the system to be read
(e.g. export PATH_LOCALE="/home/evil/111111111/222222222/33333333\
/XXXXXX/../../../../../home/manager/.ssh/identity", where XXXXXX is similar to the
surrounding elements)
by the startup code;
If then the attacker would be able to create a core dump ...


Anyway , you might want to look at FreeBSD-current code, where
this problem seems to be solved (in a slightly different way.

Regards,

Wojtek Pilorz
Wojtek.Pilorz@bdk.lublin.pl

-----------------------------------------------------------------------

On Tue, 4 Feb 1997 tenser@SPITFIRE.ECSEL.PSU.EDU wrote:

> Date: Tue, 4 Feb 1997 04:06:01 -0000
> From: tenser@SPITFIRE.ECSEL.PSU.EDU
> To: BUGTRAQ@NETSPACE.ORG
> Subject: Patches for 2.1.6-RELEASE locale stuff...
>
> I took another look at the locale code for 2.1.6-RELEASE (availible in
> /usr/src/lib/libc/locale), and tried to go though everything and look
> for buffer overrun type stuff.  Here is a set of patches for the four
> files I modified.  I don't guarantee that this takes care of all possible
> locale security problems, but it's a start for the folks who are going
> to presumably issue an advisory and official patch at some point in the
> future.  These patched source files at least compile on my 386 running
> 2.1.6.  Any errors I might have made, I attribute to lack of sleep over
> the last few days.  :-)
>
> (Note, just to clarify: My first patch should have thwarted the startup
> locale processing bug.  These patches are for other buffer overrun problems
> in the locale stuff in the C library.  That first patch is also included
> here for convenience.)
>
>         - Dan C.
>
> ----- Begin 2.1.6-locale.diff
> *** collate.c   1997/02/04 02:49:05     1.1
> --- collate.c   1997/02/04 02:54:58
> ***************
> *** 66,75 ****
>                 return -1;
>         if (!path_locale && !(path_locale = getenv("PATH_LOCALE")))
>                 path_locale = _PATH_LOCALE;
> !       strcpy(buf, path_locale);
> !       strcat(buf, "/");
> !       strcat(buf, encoding);
> !       strcat(buf, "/LC_COLLATE");
>         if ((fp = fopen(buf, "r")) == NULL)
>                 return -1;
>         FREAD(__collate_charmap_table, sizeof(__collate_charmap_table), 1, fp);
> --- 66,73 ----
>                 return -1;
>         if (!path_locale && !(path_locale = getenv("PATH_LOCALE")))
>                 path_locale = _PATH_LOCALE;
> !       (void)snprintf(buf,
> !               PATH_MAX, "%s/%s/LC_COLLATE", path_locale, encoding);
>         if ((fp = fopen(buf, "r")) == NULL)
>                 return -1;
>         FREAD(__collate_charmap_table, sizeof(__collate_charmap_table), 1, fp);
[patches to other files have been removed ...]

home help back first fref pref prev next nref lref last post