Re: Linux SPLITVT bug (again)

[Gilles.Soulet () cst cnes fr (Gilles Soulet)]

At 19:21 04/01/1996 +0100, ALEXANDER SCHUETZ wrote:

--8<--- [snipped text] --8<---

> The point I cannot figure is: How is "splitvt" being forced to EXECUTE
> this little program? After all, it just sits in the environment variable.
> I dont get it how a HOME environment variable can force "splitvt" to
> execute a jump into that environment string?!?!
>
> If someone can explain, I shall be very glad indeed.
>
> Yours,
>
>        Alex.

I'm not an Intel architecture specialist, and never used a Linux Box.
But let's have a quick look at the egg C and ASM code :

- 0x90 is the NOP OpCode of Intel 386s
- The small ASM routine doesn't contains any zero : the required
  zero-long words of the system call are poked dynamically during execution
  of the egg (as you noticed)

This can lead to an obvious conclusion :
----------------------------------------

I don't have the splitvt source code, but I can bet $100 that
there's a strcpy() call that copy the content of the HOME variable
in a dynamic (local) array of char.

Using strcpy() is bad, cos it doesn't make any effort to detect
the end of the string, and it's not limited in the amount of bytes
to copy (better use strncpy(). After eggplant, HOME contains ASM code
without zero. The strcpy() will copy this code on the local array, and
since there's only limited place for that, it will overflow the array
and put datas on the stack (admiting that Linux's local vars are
allocated on the stack).

The calling function's return address is damaged and replaced by
another one : the one which permits the egg code execution.

The get_esp() call is probably used to obtain the stack address.
Assuming Linux process have a contiguous-linear address space, it's
possible that every process has always the same local stack address.
So, the first call to get_esp() (during implantation) give the
stack address, then the bad guy has only to put in HOME this
address + a specific delta calculated by "breakpointing" the poor
Splitvt and looking at the stack delta during execution of the strcpy().


This must leads to another conclusion for all of us : is it a
good thing to tolerate the ability to "poke" anything in variables ?
We have lot of problems with that (remember IFS + Loadmodule ?)

What about placing env variables in a protected memory space, where
the only way to modify datas is to use a "protected" putenv() call,
which, at least :

 1) looks at the datas and checks that there're only Alphanums chars
 2) doucle check that there isn't twice defined vars
 3) etc...


   Gillus