Endless Buffer Overruns

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

PA
Thu Sep 16 20:07:17 CDT 2004

I suggest you apply for employment at Microsoft, Duane.
--
~PA Bear

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

Roger
Thu Sep 16 22:41:40 CDT 2004

I am pretty much in the same camp.
However, I do know that MS developed tools that have been used
to search the code for overrun coding patterns, and has kept this
practice going and provided access to fruits from developing these
tools in the VS release.
However, I also have written compilers and can recognize how very
many ways there are in which these overruns might arise, and how
a static code analysis is simply not able to recognize all situations.
The further solution, recoding all so that it only uses buffering that
is safely encapsulated, is a monumental task. Do you remember
how long it took for safe pointers to come into wide use in c++ ?

--
Roger Abell
Microsoft MVP (Windows Server System: Security)
MCDBA, MCSE W2k3+W2k+Nt4
"Duane" <nospam@aol.com> wrote in message
news:Oy9%23qgDnEHA.1672@TK2MSFTNGP09.phx.gbl...
>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
>

Joe
Thu Sep 16 23:00:32 CDT 2004

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
>

levinson_k
Fri Sep 17 09:56:17 CDT 2004

The fact that even www.OpenBSD.org and Linux have been vulnerable to
both local and remote buffer overflows and requires frequent patching,
despite the fact that OpenBSD contains way fewer lines of code, the
code is open source and has been reviewed by many, has no GUI, little
interoperability and almost all functionality is disabled by default
proves that preventing buffer overflows is way harder than you would
expect.

Windows and MS software, by comparison, is programmed by large teams
of people, each team working on different sub-sub-components.
Communication between teams working on the same software, let alone
between sub-teams working on different software like Windows, Office
and IE, has to be a huge challenge.

You might ask why so many buffer overflow vulnerabilities for Linux,
Mozilla, SSH, BIND, etc. continue to be found and released.


"Duane" <nospam@aol.com> wrote in message news:<Oy9#qgDnEHA.1672@TK2MSFTNGP09.phx.gbl>...
> 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

Duane
Fri Sep 17 12:40:21 CDT 2004

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
> >

Roger
Fri Sep 17 13:57:41 CDT 2004

I believe the older Win98 is not impacted as it only supports
gdi.dll, not the gdiplus.dll
Just keep in mind, as I tried to indicate in prior response, the
limits used, such as in pointer addition, etc. can be expressed
not as constants but as variables, in fact as variables with values
that are not simply derived. This are not capable of automated
linting techniques based on static code analysis. I believe that
therein lies the reason that overruns are still being found. When
the security push started and all new development stood down
for months of code review, the automated code review tool did
find many flaws, including statically detectable overflow-vulnerable
code. The more (in)eligantly coded cases probably will wait
until the module is modified and so handled by the newly (re)trained
devs and then reviewed according to the new practices that have
been implaced for code checkin.

--
Roger Abell
Microsoft MVP (Windows Server System: Security)
MCDBA, MCSE W2k3+W2k+Nt4
"Duane" <nospam@aol.com> wrote in message
news:eYlES2NnEHA.2680@TK2MSFTNGP15.phx.gbl...
> 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
>> >
>

Hamlet
Fri Sep 17 14:15:18 CDT 2004

Dude,
Why do you always insist on working the fact that the Open Source folks
have problems into your posts? Didn't we leave the "I know you are, but what
am I?" stuff on the playground?

H


"Karl Levinson [x y] mvp" <levinson_k@despammed.com> wrote in message
news:e51f18d1.0409170656.5cfe967a@posting.google.com...
> The fact that even www.OpenBSD.org and Linux have been vulnerable to
> both local and remote buffer overflows and requires frequent patching,
> despite the fact that OpenBSD contains way fewer lines of code, the
> code is open source and has been reviewed by many, has no GUI, little
> interoperability and almost all functionality is disabled by default
> proves that preventing buffer overflows is way harder than you would
> expect.
>
> Windows and MS software, by comparison, is programmed by large teams
> of people, each team working on different sub-sub-components.
> Communication between teams working on the same software, let alone
> between sub-teams working on different software like Windows, Office
> and IE, has to be a huge challenge.
>
> You might ask why so many buffer overflow vulnerabilities for Linux,
> Mozilla, SSH, BIND, etc. continue to be found and released.
>
>
> "Duane" <nospam@aol.com> wrote in message
news:<Oy9#qgDnEHA.1672@TK2MSFTNGP09.phx.gbl>...
> > 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

Karl
Fri Sep 17 18:51:45 CDT 2004


"Hamlet" <Elsinore> wrote in message
news:uF7j2qOnEHA.3756@TK2MSFTNGP11.phx.gbl...
> Dude,
> Why do you always insist on working the fact that the Open Source folks
> have problems into your posts? Didn't we leave the "I know you are, but
what
> am I?" stuff on the playground?

It's completely relevant. The question was, shouldn't buffer overflows be
gone by now? The answer is, it's not that simple. You completely misread
what I said. I made no statement attacking open source software, in fact
I'm constantly directing people to it.

Joe
Thu Sep 23 00:36:43 CDT 2004

XP isn't really new code in terms of the turnaround at MS for security purposes.
Windows Server 2003 really isn't even new as the turnaround occurred at the
tail end of the 2K3 development work. I think XP came out in like Oct 2001. Code
freeze was probably some time in July 2001 or so. Also if you think that XP is
an entirely new OS, it isn't, it is building on what was in 2000 and NT and even
some stuff from Win9x. There are some newer pieces like the GDIPLUS piece but
that doesn't mean they are perfect.

If I need an update of my immensely popular ADFIND or OldCmp tools I can sit
down in a night and crank it out in a couple of hours tops including publishing
to the web site. I could probably rewrite them from scratch over a weekend. That
doesn't describe these OSes and yes, it is amazing they work at all with all of
the complexity involved. A simpler OS would be nicer but being simpler doesn't
mean no bugs, it simply means less bugs. A simpler OS means people having to buy
more and more third party tools to get functionality they expect out of an OS.
Go look at the OSS solutions, how much is base OS, how much is add-ons? I would
also recommend signing up for the patch bulletins for a few of the vendors. I
think I updated one of my favorite OSS apps about 4 times in the last 5-6 months
due to various bugs including security issues. This isn't an MS only issue. It
is a state of programming issue. It is harder to code for every possibility and
then test for it versus code and test for the most likely things. Most people
writing code don't think, what if someone puts a complete garbage value into
this spot right here. If they did that for every single possible location, the
code gets huge and it takes forever to release. Throwing an exception that there
is a bad value is rarely the right answer, people want it to also be handled
automatically and as under the covers as possible. That takes a lot of logic to
be put into the code.

Once again, the software will never be perfect. There is no way to test every
piece of functionality with every possible bad value that could be sent into
code. Yes, I agree there could be better bounds checking and exception handling,
but it won't happen immediately.

There are several descriptions floating around of exactly what that jpeg issue
is about. If you are into coding it is worth reading, if you aren't, the
specifics of the issue will probably be lost on you.




--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net



Duane wrote:
> 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
>>>
>
>

Joe
Thu Sep 23 00:39:27 CDT 2004

He isn't attacking open source, he is saying that they are in the same boat as
everyone else or that MS is in the same boat as everyone else. A further point
is that even with lots of people not within a company looking at the code
doesn't make it error free either.

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net



Hamlet wrote:
> Dude,
> Why do you always insist on working the fact that the Open Source folks
> have problems into your posts? Didn't we leave the "I know you are, but what
> am I?" stuff on the playground?
>
> H
>
>
> "Karl Levinson [x y] mvp" <levinson_k@despammed.com> wrote in message
> news:e51f18d1.0409170656.5cfe967a@posting.google.com...
>
>>The fact that even www.OpenBSD.org and Linux have been vulnerable to
>>both local and remote buffer overflows and requires frequent patching,
>>despite the fact that OpenBSD contains way fewer lines of code, the
>>code is open source and has been reviewed by many, has no GUI, little
>>interoperability and almost all functionality is disabled by default
>>proves that preventing buffer overflows is way harder than you would
>>expect.
>>
>>Windows and MS software, by comparison, is programmed by large teams
>>of people, each team working on different sub-sub-components.
>>Communication between teams working on the same software, let alone
>>between sub-teams working on different software like Windows, Office
>>and IE, has to be a huge challenge.
>>
>>You might ask why so many buffer overflow vulnerabilities for Linux,
>>Mozilla, SSH, BIND, etc. continue to be found and released.
>>
>>
>>"Duane" <nospam@aol.com> wrote in message
>
> news:<Oy9#qgDnEHA.1672@TK2MSFTNGP09.phx.gbl>...
>
>>>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
>
>
>

Steve
Fri Sep 24 14:24:31 CDT 2004


"Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
news:%23VxfQ9SoEHA.3460@tk2msftngp13.phx.gbl...

<Snip>

>A simpler OS would be nicer but being simpler doesn't
> mean no bugs, it simply means less bugs. A simpler OS means people having
to buy
> more and more third party tools to get functionality they expect out of an
OS.
> Go look at the OSS solutions, how much is base OS, how much is add-ons?


<Snip, Snip, Snip - a whole bunch>

However, wouldn't a simpler OS cost correspondingly less? Thus offsetting
the cost of the additional third party tools.
A Swiss Army knife does a lot of different things, but not necessarily all
that well. Is having the web browser so hooked into the OS that the two are
indistinguishable a good thing from a security perspective? What about being
able to uninstall IE, OE, Media Player, and Messenger? Or better yet install
them if wanted, not have them there by default?

Steve

Joe
Fri Sep 24 20:33:30 CDT 2004

I wasn't talking about how much as in cost.

The issue (and true cost) with adding more and more third party is integration
and coexistence issues as well as patch management.

I don't disagree that IE shouldn't be integrated or at least not be as feature
rich in the default integrated model.

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net



Steve wrote:
> "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
> news:%23VxfQ9SoEHA.3460@tk2msftngp13.phx.gbl...
>
> <Snip>
>
>>A simpler OS would be nicer but being simpler doesn't
>>mean no bugs, it simply means less bugs. A simpler OS means people having
>
> to buy
>
>>more and more third party tools to get functionality they expect out of an
>
> OS.
>
>>Go look at the OSS solutions, how much is base OS, how much is add-ons?
>
>
>
> <Snip, Snip, Snip - a whole bunch>
>
> However, wouldn't a simpler OS cost correspondingly less? Thus offsetting
> the cost of the additional third party tools.
> A Swiss Army knife does a lot of different things, but not necessarily all
> that well. Is having the web browser so hooked into the OS that the two are
> indistinguishable a good thing from a security perspective? What about being
> able to uninstall IE, OE, Media Player, and Messenger? Or better yet install
> them if wanted, not have them there by default?
>
> Steve
>
>