Re: Endless Buffer Overruns

From: Duane (
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.


"Joe Richards [MVP]" <> wrote in message
> I sort of agree with you but it isn't something that can be implemented
> night. At a guess, you could look through all of your code that you have
> written and especially what you currently maintain in less than 6 months.
> 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
> some of it written by people long gone. No one is familiar with all of the
> and there are probably sections that haven't been seriously touched in so
> that no one is really familiar with it. It is a completely different case
> you or I looking over what we have written and having MS look over
> 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
> 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
> 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
> 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
> 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
> emphasis is such that to ignore the issue now will have fiscal impact so
> force changes and correctes. But again, don't ever expect your old MS
> to ever be patched to perfection. It isn't a realistic expectation nor
> joe
> --
> Joe Richards Microsoft MVP Windows Server Directory Services
> Duane wrote:
> > I see yet another update (JPEG) involving the same type of ongoing
> > 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
> > and overlooked errors in my code. However, when I am made aware of a
> > of error, I go back and fix ALL of those types of errors. At least as
> > as I know about. Why doesn't Microsoft? If they don't know about all
> > 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
> > when some programmer makes a mistake in address pointers and his program
> > writes outside of allocated memory. Since this is a big (there's
> > updates on such) and repeating security issue, why not at the very
> > 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?
> > if there is some reason that's necessary under such-and-such
> > I would think Microsoft's programs shouldn't do that and therefore
> > 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
> >