On Aug 29, 2:54pm, Bret McDanel wrote:
} Subject: Re: [8lgm]-Advisory-22.UNIX.syslog.2-Aug-1995 (fwd)
} > Here is what I mean when I say if it is unix it is a sieve...
} >
} >
} [Entire 8lgm advisory deleted]
}
} Well, I think that the problem is that too many people arent taught proper
} programming to begin with.. Almost every hole that has come out in the last
} 2 or 3 years is because people that wrote programs assume that all data is
} good..
}
} This hole that was mentioned was a prime example of that.. All data is valid,
} so dont check for size.. If programmers start assuming that all data is
} invalid, until proven valid, then security will be a lot easier to manage..
Well you can certainly make this claim about the authors of syslog(),
but the authors of any applications that use it are in a different boat.
The buffer that's overflowing is internal to syslog(), it seems to vary
in size between different platforms, and there seems to be no way for
the application programmer to find out ahead of time how much data can
be safely shoveled into it. It's also not real easy to figure out
how much you are shoveling into it. For instance, how much buffer
space is that %m in the format string going to consume? I'd say this
is a broken interface in this if the application programmer can't safely
use the fancier features of the interface without duplicating all the
work that syslog() will do to internally just to find out how big the
string will be, and especially if there is no way to know what the limit
is on the string size.
It's sort of like the old problems we've seen with gets(), but in this
case we don't have fgets() at all, and gets() is using its own internal
buffer of some arbitrary size and it doesn't tell us what it is. It
works fine as long as you feed it a file that only contains newlines ;-)
--- Truck
|
|
