Re: Endless Buffer Overruns

From: Duane (nospam_at_aol.com)
Date: 09/17/04


Date: Fri, 17 Sep 2004 12:40:21 -0500

Ok, thanks all, that helps me understand it a little better. Too big, too
complex, with too many people. I guess we should be thankful it works as
well as it does. And, I didn't know that open source operating systems are
also having similar problems.

Joe, I don't expect MS to go back and fix all past problems, but these last
few issues are new problems - at least the release is new (Internet Explorer
and XP for JPEG). Maybe old components of the code reused? But, I find it
interesting that XP has the problems, but they said Windows 98 does not.
That to me appears as if they went to extra work to put the problem in (not
saying intentionally) - or didn't check new code or old module very well for
new software. Having a JPEG create a buffer overrun seems like hard to do.
But, maybe there is some new "feature" that causes it. JPEGs with code?

They want people to update and no longer support '98, but there keeps coming
up problems with only XP.

Duane

"Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
news:%239sthrGnEHA.2708@TK2MSFTNGP10.phx.gbl...
> I sort of agree with you but it isn't something that can be implemented
over
> night. At a guess, you could look through all of your code that you have
ever
> written and especially what you currently maintain in less than 6 months.
You
> have the further benefit of being the person who wrote all of it.
>
> Microsoft has millions upon millions of lines of code, some of it
purchased,
> some of it written by people long gone. No one is familiar with all of the
code
> and there are probably sections that haven't been seriously touched in so
long
> that no one is really familiar with it. It is a completely different case
from
> you or I looking over what we have written and having MS look over
everything
> they have. Additionally as Roger indicated, there are several different
ways the
> overflows can get generated so it isn't always something that can be
easily
> located programmatically.
>
> All that being said, MS is working on it and slowly correcting it.
However, I
> don't ever expect all of the code for anything currently out to ever be
free
> from possible holes. If you expect this, you are living in a dream world.
It is
> not possible to produce a huge complex software project like Windows and
have
> perfect code. Even open source has found that to be the case as I get the
> notifications for patches for those right alongside the MS notifications.
>
> The goal should be for MS to keep refining processes and procedures so
> everything new gets better and better and less likely to have the holes
that
> have plagued us in the past. Should that have started a long time ago,
yes. But
> it never had the visibility it has now and quite frankly, MS is a
business, they
> aren't there to make perfect software, they are there to make money. The
current
> emphasis is such that to ignore the issue now will have fiscal impact so
will
> force changes and correctes. But again, don't ever expect your old MS
software
> to ever be patched to perfection. It isn't a realistic expectation nor
goal.
>
> joe
>
> --
> Joe Richards Microsoft MVP Windows Server Directory Services
> www.joeware.net
>
>
>
> Duane wrote:
> > I see yet another update (JPEG) involving the same type of ongoing
buffer
> > overrun vulnerability. Could someone please help me understand why this
> > situation has not been corrected?
> >
> > I'm approaching this from a programmer point of view. I have made
mistakes
> > and overlooked errors in my code. However, when I am made aware of a
type
> > of error, I go back and fix ALL of those types of errors. At least as
many
> > as I know about. Why doesn't Microsoft? If they don't know about all
the
> > buffer overrun areas, shouldn't they have a team that verifies the code?
> >
> > Maybe I don't understand what buffer overrun is/does. I would think it
is
> > when some programmer makes a mistake in address pointers and his program
> > writes outside of allocated memory. Since this is a big (there's
endless
> > updates on such) and repeating security issue, why not at the very
minimum
> > check, double check, and triple check all areas where there could even
be a
> > potential of buffer overrun? Or, even better, design the system so that
> > programs cannot even possibly write outside of their allocated memory?
Or,
> > if there is some reason that's necessary under such-and-such
circumstances,
> > I would think Microsoft's programs shouldn't do that and therefore
should
> > have a flag that prohibits them from writing outside allocated memory.
> >
> > Maybe someone can explain why this is an ongoing issue that cannot be
> > corrected, but otherwise I see no excuse for it.
> >
> > Duane
> >