Re: [Stan Bubrouski <satan () FASTDIAL NET>: Re: rh 6.2 - gidcompromises, etc [+ MORE!!!]]

[fdc () COLUMBIA EDU (Frank da Cruz)]

> ...  If I thought that
> this was a problem with a larger scope than just Red Hat I would
> have reported it to you, but as it was the problem was not with
> your code so much as with Red Hat making them sgid uucp I
> chose not to bug you with things you had no control over.
OK, but it would still be good to know what is going on out there.
Anyway, all's well that ends well (I hope).

> Reading the C-Kermit code is in my opinion disorganized and very
> messy.
This is a combination of several factors:

 . History -- parts of it do indeed go back to to 1985.

 . Portability -- It's not a Linux-only, or even Unix-only program.
   It has to be buildable on hundreds of platforms, many of which
   do not have gcc or any form of ANSI C, or modern C libraries.

 . "Too many cooks" syndrome -- much code is contributed from elsewhere,
   and much of this code is platform-specific, sometimes to platforms we
   ourselves don't have access to, and so tends to be left as-is.

> Regardless of whether you agree with this or not, it appears
> to me the code is very old and needs alot of work.
Sure, what package of any significant size doesn't?

> I'm not saying you guys aren't trying and I'm not saying you people on the
> C-Kermit project aren't improving it, all I'm saying is that there are alot
> of problems and thus I feel that it should not be made sgid on systems where
> users could try to take advantage of bugs/problems in it.  I see a handful
> of unchecked buffers as I'm sitting here writing this...
By all means let us know whenever you find one:

  kermit-support () columbia edu

> so I'm still convinced much needs to be done before it is safe to make
> this program sgid.
It should be noted the program does not run suid or sgid except the following
places:

 1. When opening the SET LINE device.
 2. When creating the UUCP lockfile.
 3. When reading a UUCP lockfile.
 4. When deleting the UUCP lockfile.

In each case, only a few lines of code (usually just a system call) are
executed with sgid/suid active, and these don't involve writing or copying
buffers.  At all other times, it is running with the user's real ID and
groups.

> I'll try to make note of all of the ones I see when I have time and I'll
> attempt to fix the ones I can and send you diffs ok?
Absolutely.

> Oh yeah and here are some numbers regarding function use:
We've done similar inventories and believe we have included code to check
all of them except sprintf().  I agree this is a problem area.  As you know
snprintf() is not portable, and in fact is relatively uncommon across the
many platforms that C-Kermit supports.

> Now in all seriousness do you really think that most of those
> 886 sprintf calls have bounds-checking?  Anyway, I was
> wondering why do you guys use no snprintf calls in your code?
> Just curious, I can definately see some places that would benefit
> from it.
We wish we could!  Coming up with our own snprintf() replacement has been
on our list for some time.  But then, so are 1000 other things...

Thanks for you report and help.

- Frank