[8455] in bugtraq

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

Re: xlock mishandles malformed .signature/.plan

daemon@ATHENA.MIT.EDU (Aaron Campbell)
Mon Nov 9 13:24:47 1998

Date: 	Sat, 7 Nov 1998 12:17:54 -0400
Reply-To: aaron@UG.CS.DAL.CA
From: Aaron Campbell <aaron@UG.CS.DAL.CA>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  <Pine.LNX.4.02A.9811061742020.20287-100000@luna.theo2.physik.uni-stuttgart.de>

On Fri, 6 Nov 1998, Jochen Thomas Bauer wrote:

> The local variable "char *home", that will be filled with a pointer to a string
> containing the path to the user's home directory, is declared right after the
> local varibale "char buf[121]", so this pointer will be located right above the
> space left for "char buf[121]" on the stack (remember, the stack grows to

You've made a pretty bold assumption here on what order the compiler will
decide the local variables should live on the stack. In particular, any
optimization options passed to gcc will often rearrange the positions of
the automatic variables. At any rate, this was pointed out in a Bugtraq
posting from gut@cdc.net dated May 31st, 1998:

http://geek-girl.com/bugtraq/1998_2/0446.html

>                             cr = strlen(buf) - 1;
>                                 if (buf[cr] == '\n') {
>                                         buf[cr] = '\0';
>                                 }
> So buf[-1] must have a value of buf[-1]=10 in order to get overwritten by NULL.

Wrong. Look further down the code; there is another buf[cr] = '\0';
statement that most certainly will be executed regardless.

> The pointer "char *home" has at this point already been used to construct the
> full path to the .plan, .signature or .xlocktext file, and the result has already
> been written to a buffer pointed to by "char *buffer".

And if the author adds code at a later time which uses the *home pointer,
he may have blindly created a way to modify data at God-knows-where in
memory.

> So, IMHO, there is no security hole created by this bug.

Either way, this really isn't an issue. One bug might not look harmful,
but often multiple bugs together can be. Programming flaws appearing
innocent now may turn out to help create gaping security holes later.

  .  _  _  _ _ . .   _ _ .  . _  _  _ . .
 :  |-||-||<|_||\|  |_|-||\/||-'|->|_-|_|_  DalTech, Halifax, NS, Canada
  `---------------------------------------- [http://www.biodome.org/~fx] -

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