OT: Microsoft does it again.

[Sylvia Else]

Another buffer overflow in IE.

http://www.us-cert.gov/cas/techalerts/TA04-315A.html

Is there a single documented case where Microsoft have NOT implemented a
buffer overflow vulnerability where one could have been?

Cert's description says "Because IE fails to properly check the size of
the NAME and SRC attributes."

I rather suspect that this is a euphemism for "didn't bother to consider
the possibility."

There are very simple approaches that make this sort of mistake
impossible. Why can't MS get its act in order?

Put me in charge of development...

Programmer induction course. Lesson 1. This is how you avoid making
buffer overflow mistakes. Take note. MS operates a zero-tolerance
policy. One buffer overlow, and your out.

Dragging this post someway back towards being on topic, these misakes
are not "technological risk" type problems. They are negligence, pure
and simple. Anyone for a class action?

Sylvia.

[Douglas MacDonald]

Sylvia Else wrote:
> Another buffer overflow in IE.
>
> http://www.us-cert.gov/cas/techalerts/TA04-315A.html
>
> Is there a single documented case where Microsoft have NOT implemented a
> buffer overflow vulnerability where one could have been?
>
> Cert's description says "Because IE fails to properly check the size of
> the NAME and SRC attributes."
>
> I rather suspect that this is a euphemism for "didn't bother to consider
> the possibility."
>
> There are very simple approaches that make this sort of mistake
> impossible. Why can't MS get its act in order?
>
> Put me in charge of development...
>
> Programmer induction course. Lesson 1. This is how you avoid making
> buffer overflow mistakes. Take note. MS operates a zero-tolerance
> policy. One buffer overlow, and your out.
>
> Dragging this post someway back towards being on topic, these misakes
> are not "technological risk" type problems. They are negligence, pure
> and simple. Anyone for a class action?
>
> Sylvia.
>
Oh dear...
Do you have any idea at all, just how many people in the world are
capable of the level of programming skill needed to make a 30 million
lines of code monster like Windows actually work as good as it does?

Plenty of talented people out there but people with skills like Linus
Torvold (to name one popular person with those skills) are as rare as 3
headed monkeys in Antarctica. This is why Microsoft is the wealthiest
corporation in the world... And you would sack one maybe 100 people in
the world who can make it work for a buffer overflow?

Get a grip on yourself Sylvia. It's not as simple as brain surgery, you
know.

Douglas

[Sylvia Else]

Douglas MacDonald wrote:

> Sylvia Else wrote:
>
>> Another buffer overflow in IE.
>>
>> http://www.us-cert.gov/cas/techalerts/TA04-315A.html
>>
>> Is there a single documented case where Microsoft have NOT implemented
>> a buffer overflow vulnerability where one could have been?
>>
>> Cert's description says "Because IE fails to properly check the size
>> of the NAME and SRC attributes."
>>
>> I rather suspect that this is a euphemism for "didn't bother to
>> consider the possibility."
>>
>> There are very simple approaches that make this sort of mistake
>> impossible. Why can't MS get its act in order?
>>
>> Put me in charge of development...
>>
>> Programmer induction course. Lesson 1. This is how you avoid making
>> buffer overflow mistakes. Take note. MS operates a zero-tolerance
>> policy. One buffer overlow, and your out.
>>
>> Dragging this post someway back towards being on topic, these misakes
>> are not "technological risk" type problems. They are negligence, pure
>> and simple. Anyone for a class action?
>>
>> Sylvia.
>>
> Oh dear...
> Do you have any idea at all, just how many people in the world are
> capable of the level of programming skill needed to make a 30 million
> lines of code monster like Windows actually work as good as it does?

Um, actually, yes.

But the issue here is the narrower one of writing code that does not
contain buffer overlow errors. How much skill is required to do that?
Not much, provided you're shown the techniques to use, and then use them.

Sylvia.

[Jeremy Quirke]

"Sylvia Else" <sylvia@not.at.this.address> wrote in message
news:41929749$0$27450$afc38c87@news.optusnet.com.a u...
>
>
> Douglas MacDonald wrote:
>
> > Sylvia Else wrote:
> >
> >> Another buffer overflow in IE.
> >>
> >> http://www.us-cert.gov/cas/techalerts/TA04-315A.html
> >>
> >> Is there a single documented case where Microsoft have NOT implemented
> >> a buffer overflow vulnerability where one could have been?
> >>
> >> Cert's description says "Because IE fails to properly check the size
> >> of the NAME and SRC attributes."
> >>
> >> I rather suspect that this is a euphemism for "didn't bother to
> >> consider the possibility."
> >>
> >> There are very simple approaches that make this sort of mistake
> >> impossible. Why can't MS get its act in order?
> >>
> >> Put me in charge of development...
> >>
> >> Programmer induction course. Lesson 1. This is how you avoid making
> >> buffer overflow mistakes. Take note. MS operates a zero-tolerance
> >> policy. One buffer overlow, and your out.
> >>
> >> Dragging this post someway back towards being on topic, these misakes
> >> are not "technological risk" type problems. They are negligence, pure
> >> and simple. Anyone for a class action?
> >>
> >> Sylvia.
> >>
> > Oh dear...
> > Do you have any idea at all, just how many people in the world are
> > capable of the level of programming skill needed to make a 30 million
> > lines of code monster like Windows actually work as good as it does?
>
> Um, actually, yes.
>
> But the issue here is the narrower one of writing code that does not
> contain buffer overlow errors. How much skill is required to do that?
> Not much, provided you're shown the techniques to use, and then use them.
>

It can be much more complicated than that, and you would know that if you
had any programming experience.

[Sylvia Else]

Jeremy Quirke wrote:

> "Sylvia Else" <sylvia@not.at.this.address> wrote in message
> news:41929749$0$27450$afc38c87@news.optusnet.com.a u...
>
>>
>>Douglas MacDonald wrote:
>>
>>
>>>Sylvia Else wrote:
>>>
>>>
>>>>Another buffer overflow in IE.
>>>>
>>>>http://www.us-cert.gov/cas/techalerts/TA04-315A.html
>>>>
>>>>Is there a single documented case where Microsoft have NOT implemented
>>>>a buffer overflow vulnerability where one could have been?
>>>>
>>>>Cert's description says "Because IE fails to properly check the size
>>>>of the NAME and SRC attributes."
>>>>
>>>>I rather suspect that this is a euphemism for "didn't bother to
>>>>consider the possibility."
>>>>
>>>>There are very simple approaches that make this sort of mistake
>>>>impossible. Why can't MS get its act in order?
>>>>
>>>>Put me in charge of development...
>>>>
>>>>Programmer induction course. Lesson 1. This is how you avoid making
>>>>buffer overflow mistakes. Take note. MS operates a zero-tolerance
>>>>policy. One buffer overlow, and your out.
>>>>
>>>>Dragging this post someway back towards being on topic, these misakes
>>>>are not "technological risk" type problems. They are negligence, pure
>>>>and simple. Anyone for a class action?
>>>>
>>>>Sylvia.
>>>>
>>>
>>>Oh dear...
>>>Do you have any idea at all, just how many people in the world are
>>>capable of the level of programming skill needed to make a 30 million
>>>lines of code monster like Windows actually work as good as it does?
>>
>>Um, actually, yes.
>>
>>But the issue here is the narrower one of writing code that does not
>>contain buffer overlow errors. How much skill is required to do that?
>>Not much, provided you're shown the techniques to use, and then use them.
>>
>
>
> It can be much more complicated than that, and you would know that if you
> had any programming experience.

An interesting conclusion.

Sylvia.

[Tony Morris]

"Sylvia Else" <sylvia@not.at.this.address> wrote in message
news:41928adf$0$27445$afc38c87@news.optusnet.com.a u...
> Another buffer overflow in IE.
>
> http://www.us-cert.gov/cas/techalerts/TA04-315A.html
>
> Is there a single documented case where Microsoft have NOT implemented a
> buffer overflow vulnerability where one could have been?
>
> Cert's description says "Because IE fails to properly check the size of
> the NAME and SRC attributes."
>
> I rather suspect that this is a euphemism for "didn't bother to consider
> the possibility."
>
> There are very simple approaches that make this sort of mistake
> impossible. Why can't MS get its act in order?
>
> Put me in charge of development...
>
> Programmer induction course. Lesson 1. This is how you avoid making
> buffer overflow mistakes. Take note. MS operates a zero-tolerance
> policy. One buffer overlow, and your out.
>
> Dragging this post someway back towards being on topic, these misakes
> are not "technological risk" type problems. They are negligence, pure
> and simple. Anyone for a class action?
>
> Sylvia.
>

It's a sad case that our industry has been infiltrated with incompetence.
I blame the tertiary institutions, despite feeling somewhat hypocritical,
since I am a part-time lecturer on the topic.
I do try my best to rid the vulnerable student mind of misinformation - I
really do!!

It is also for this very reason that I have chosen to work (my full-time
job) in an environment where I have no dependancies on fragile software
developed by what I refer to as "the clowns in the circus".

I'm willing to bet (3 of my baked cookies) that more people in this
newsgroup know what a buffer overflow is (or at least, try to) than in those
where it is more relevant.

*shakes head* sad, but true.

A class action - hmm ... if I knew what one of those really was, you could
count me in :)

--
Tony Morris
http://xdweb.net/~dibblego/

[Sylvia Else]

Tony Morris wrote:

> "Sylvia Else" <sylvia@not.at.this.address> wrote in message
> news:41928adf$0$27445$afc38c87@news.optusnet.com.a u...
>
>>Another buffer overflow in IE.
>>
>>http://www.us-cert.gov/cas/techalerts/TA04-315A.html
>>
>>Is there a single documented case where Microsoft have NOT implemented a
>>buffer overflow vulnerability where one could have been?
>>
>>Cert's description says "Because IE fails to properly check the size of
>>the NAME and SRC attributes."
>>
>>I rather suspect that this is a euphemism for "didn't bother to consider
>>the possibility."
>>
>>There are very simple approaches that make this sort of mistake
>>impossible. Why can't MS get its act in order?
>>
>>Put me in charge of development...
>>
>>Programmer induction course. Lesson 1. This is how you avoid making
>>buffer overflow mistakes. Take note. MS operates a zero-tolerance
>>policy. One buffer overlow, and your out.
>>
>>Dragging this post someway back towards being on topic, these misakes
>>are not "technological risk" type problems. They are negligence, pure
>>and simple. Anyone for a class action?
>>
>>Sylvia.
>>
>
>
> It's a sad case that our industry has been infiltrated with incompetence.
> I blame the tertiary institutions, despite feeling somewhat hypocritical,
> since I am a part-time lecturer on the topic.

The dot.com boom didn't help. Burger flippers could get jobs as
programmers, and some of them have still not returned to their true
vocations.

>
> A class action - hmm ... if I knew what one of those really was, you could
> count me in :)

It's where those people in the world who've suffered loss because of
Microsoft incompetence get together and sue said company. Since M$ won't
have enough to pay the damages, the victims will end up owning the
enterprise, which will necessarily continue to be staffed by the same
people it's always had. Then the rest of us will look on and wonder
what, if anything, has actually been achieved.

Sylvia.

[Bertie the Bunyip]

Sylvia Else <sylvia@not.at.this.address> wrote in
news:4193387c$0$1724$afc38c87@news.optusnet.com.au :

>
>
> Tony Morris wrote:
>
>> "Sylvia Else" <sylvia@not.at.this.address> wrote in message
>> news:41928adf$0$27445$afc38c87@news.optusnet.com.a u...
>>
>>>Another buffer overflow in IE.
>>>
>>>http://www.us-cert.gov/cas/techalerts/TA04-315A.html
>>>
>>>Is there a single documented case where Microsoft have NOT
>>>implemented a buffer overflow vulnerability where one could have
>>>been?
>>>
>>>Cert's description says "Because IE fails to properly check the size
>>>of the NAME and SRC attributes."
>>>
>>>I rather suspect that this is a euphemism for "didn't bother to
>>>consider the possibility."
>>>
>>>There are very simple approaches that make this sort of mistake
>>>impossible. Why can't MS get its act in order?
>>>
>>>Put me in charge of development...
>>>
>>>Programmer induction course. Lesson 1. This is how you avoid making
>>>buffer overflow mistakes. Take note. MS operates a zero-tolerance
>>>policy. One buffer overlow, and your out.
>>>
>>>Dragging this post someway back towards being on topic, these misakes
>>>are not "technological risk" type problems. They are negligence, pure
>>>and simple. Anyone for a class action?
>>>
>>>Sylvia.
>>>
>>
>>
>> It's a sad case that our industry has been infiltrated with
>> incompetence. I blame the tertiary institutions, despite feeling
>> somewhat hypocritical, since I am a part-time lecturer on the topic.
>
> The dot.com boom didn't help. Burger flippers could get jobs as
> programmers, and some of them have still not returned to their true
> vocations.
>
>>
>> A class action - hmm ... if I knew what one of those really was, you
>> could count me in :)
>
> It's where those people in the world who've suffered loss because of
> Microsoft incompetence get together and sue said company.

what a fjukwit




Bertie

[Peter]

On Thu, 11 Nov 2004 08:40:43 +1100, Sylvia Else
<sylvia@not.at.this.address> wrote:


>Programmer induction course. Lesson 1. This is how you avoid making
>buffer overflow mistakes. Take note. MS operates a zero-tolerance
>policy. One buffer overlow, and your out.
>
Trouble is, Windows is built on sand whereas Linux is built on rock.
The pedigree of Windows was a simple system for personal computers at
a time when security was a minor concern. Linux pedigree was UNIX (it
was however a total re-write) designed with maximum security at the
core. Early UNIX systems were often in university environments and
hence had to be student proof. Interestingly, University of NSW (from
memory) was an early UNIX contributor but this was never properly
acknowledged in the UNIX code base.

[Ernest]

On Thu, 11 Nov 2004 08:40:43 +1100, Sylvia Else
<sylvia@not.at.this.address> wrote:

>Another buffer overflow in IE.
>
>http://www.us-cert.gov/cas/techalerts/TA04-315A.html
>
>Is there a single documented case where Microsoft have NOT implemented a
>buffer overflow vulnerability where one could have been?
>
>Cert's description says "Because IE fails to properly check the size of
>the NAME and SRC attributes."
>
>I rather suspect that this is a euphemism for "didn't bother to consider
>the possibility."
>
>There are very simple approaches that make this sort of mistake
>impossible. Why can't MS get its act in order?
>
>Put me in charge of development...
>
>Programmer induction course. Lesson 1. This is how you avoid making
>buffer overflow mistakes. Take note. MS operates a zero-tolerance
>policy. One buffer overlow, and your out.
>
>Dragging this post someway back towards being on topic, these misakes
>are not "technological risk" type problems. They are negligence, pure
>and simple. Anyone for a class action?
>
>Sylvia.

the frightening aspect of all this is that many
of the security flaws were not in the very first
versions of the software, but now are. It seems
that when they rewrite to add in new capabilities
they do not check that the previous security
checks work with the new capabilities or don't
bother trying.

And is it more than a coincidence that the
number of Windows security problems
found has risen greatly since MS joined
with Intel to push the hardware/software
based secured computing concept where
by your computer will only accept messages
etc from computers with encrypted tags
proving that they are part of the approved
secured computer listing and all software
on them has been proven legit and registered.

Deadly Ernest

@bywater.net.au

(my new keyboard, with small keys,
accepts full responsibility for all
typographical and spelling errors)