Onderwerp: Update: Web browsers - a mini-farce (MSIE gives in)

Firstly, a brief update on the status of reported sample vulnerabilities:

- mozilla_die1.html: confirmed, fixed in snapshots (DoS most of the time)
- mozilla_die2.html: confirmed, being worked on (likely exploitable)
- opera_die1.html: confirmed, being worked on (likely exploitable)
- lynx_die1.html: confirmed, independent fixes from OpenBSD team (DoS)
- links_die1.html: no official confirmation, no data (DoS)

I have no data on whether any of the vendors bothered to run my scripts to
find any further problems that are bound to surface.

I have also received reports of crashes caused by mangeme.cgi with the
following browsers:

- Safari / Konqueror (KHTML engine)
- elvis
- elinks (links engine)
- w3m

Last but not least, MSIE gives in:

> Only MSIE appears to be able to consistently handle[*] malformed
> input well, suggesting this is the only program that underwent
> rudimentary security QA testing with a similar fuzz utility.

To all those who considered my original post to be a great propaganda
ammunition for praising MSIE, bad news - although it did take a longer
while for it to give up - three hours - (impressive by comparison to
competitors), it eventually did:

http://lcamtuf.coredump.cx/mangleme/...y/ie_die1.html

Tested on 6.0.2800.1106, dies in mshtml.dll. This is a NULL pointer
dereference, so merely a DoS condition, but still an evident flaw in
basic HTML parsing.

************************************************** ****************
* This means that VIRTUALLY EVERY BROWSER IN USE TODAY is unable *
* to securely render HTML. Keeping in mind that not only web *
* browsing, but also integrated e-mail is at risk, it is a grim *
* thought. *
************************************************** ****************

Because I did not ask CERT or NIPC for patronage, did not get 20 CVE
numbers for each variant of each of the issues, nor do I have a
black-on-white webpage with stock graphics, this will likely not generate
any media splash, but I for one consider my findings to be far more
chilling that a wave of tabbed browsing URL spoofing flaws and similar
recent browser issues.

For those interested in doing some of my homework, I've updated the tool,
incorporating several minor changes to its semantics to make it somewhat
more powerful: download http://lcamtuf.coredump.cx/soft/mangleme.tgz for
version 1.2.

--
------------------------- bash$ ){ :|:&};: --
Michal Zalewski * [http://lcamtuf.coredump.cx]
Did you know that clones never use mirrors?
--------------------------- 2004-10-23 00:11 --

http://lcamtuf.coredump.cx/photo/current/

> -----Original Message-----
> From: Michal Zalewski [mailto:lcamtuf@ghettot.org]

> ************************************************** ****************
> * This means that VIRTUALLY EVERY BROWSER IN USE TODAY is unable *
> * to securely render HTML. Keeping in mind that not only web *
> * browsing, but also integrated e-mail is at risk, it is a grim *
> * thought. *
> ************************************************** ****************

This has been a basic pet peeve of mine for years -- even before web
browsers came on the scene. How many times have you seen a word processor
crash due to an unfortunate sequence of commands or opening a corrupted
file, for example? I think that kind of behavior is just unacceptable.
Software should be able to deal with any input that's thrown at it.

In-Reply-To: <20041023001154.F23256@dekadens.coredump.cx>

>
>Last but not least, MSIE gives in:
>
>> Only MSIE appears to be able to consistently handle[*] malformed
>> input well, suggesting this is the only program that underwent
>> rudimentary security QA testing with a similar fuzz utility.
>
>To all those who considered my original post to be a great propaganda
>ammunition for praising MSIE, bad news - although it did take a longer
>while for it to give up - three hours - (impressive by comparison to
>competitors), it eventually did:
>
> http://lcamtuf.coredump.cx/mangleme/...y/ie_die1.html
>
>Tested on 6.0.2800.1106, dies in mshtml.dll. This is a NULL pointer
>dereference, so merely a DoS condition, but still an evident flaw in
>basic HTML parsing.
>

Testing on Windows 98 running IE 6.0.2800.1106. Nothing happens. IE does not crash. Can anyone else confirm this?

--==_Exmh_702140408P
Content-Type: text/plain; charset=us-ascii

On Mon, 25 Oct 2004 09:03:20 EDT, David Brodbeck said:

> This has been a basic pet peeve of mine for years -- even before web
> browsers came on the scene. How many times have you seen a word processor
> crash due to an unfortunate sequence of commands or opening a corrupted
> file, for example? I think that kind of behavior is just unacceptable.
> Software should be able to deal with any input that's thrown at it.

Two quotes come to mind:

"A program designed for inputs from people is usually stressed beyond
breaking point by computer-generated inputs. -- Dennis Ritchie

Yes, "should be able to deal with anything" *is* a laudable goal. On the
other hand, there's a (presumed) requirement that the software actually *SHIP*
sometime before the thermal death of the universe - which means that the person
who has to make the decision on when/whether to ship has to decide whether
the ship date should be slipped *another* 3 months just because some automated
test program found that the package will crash if it gets requests from
a prime number of dolphins (the ceteans, not the football players) in the same
4-second interval.

Tough call - since *you* only know about it because some pseudo-random tester
found it, it's probably not easily found - and you *do* need to ship this quarter
or not make payroll. *NOW* what do you do?

And if *that* judgment call was too easy, here's the second quote:

"Testing can prove the presence of bugs, but not their absence"
-- E. Dijkstra

How do you actually prove a program bug-free? Remember - the automated tester
might not catch the prime-of-ceteans bug because *that* software's designer
never thought to cover that case (which is in itself a bug in THAT program),
so now you need to cover *all* the corner cases you can think of: Prime
numbers of ceteans, prime numbers of octopi, composite numbers of each,
and attacks by chipmunks armed with RFI wands that corrupt packet checksums.

Oh, and you're not allowed to forget to test for a case.

(If you think this is easy - read the entire end-user and administrator
documentation for a recent release of Apache. Try to itemize *all* the things
that could possibly go wrong. Then, once your brain turns to mush and you
can't think of any new ones, look over all the security-critical bugs that
Apache *has* had, and see if your list would have caught *every* *single* *one*.)



--==_Exmh_702140408P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFBfadZcC3lWbTT17ARAm0eAJ4qIxpblHuyNcHa1Sta+D SZxEJKCQCfc3jq
56lv2mYGkt4h8EAT1JgSP4w=
=O41T
-----END PGP SIGNATURE-----

--==_Exmh_702140408P--

> From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu]
> Sent: Monday, 25 October, 2004 21:25
>
> On Mon, 25 Oct 2004 09:03:20 EDT, David Brodbeck said:
>
> > Software should be able to deal with any input that's thrown at it.
>
> Two quotes come to mind:
>
> "A program designed for inputs from people is usually stressed beyond
> breaking point by computer-generated inputs. -- Dennis Ritchie

Moot. Since HTML is frequently computer-generated, HTML renderers shouldn't
be designed for human-generated input.

> Yes, "should be able to deal with anything" *is* a laudable goal. On
> the other hand, there's a (presumed) requirement that the software
> actually *SHIP* sometime before the thermal death of the universe -
> which means that the person who has to make the decision on
> when/whether to ship has to decide whether the ship date should be
> slipped *another* 3 months just because some automated test program
> found that the package will crash if it gets requests from a prime
> number of dolphins (the ceteans, not the football players) in the same
> 4-second interval.

I think that's a straw man, Valdis. HTML renderers should expect malformed
HTML input, and dealing with it is not difficult. There's simply no excuse
for buffer overflows and null pointer dereferences when processing HTML.
It's just not that hard a problem. It's not a matter of exhaustive testing;
the kinds of bugs found by Mangleme are basic ones that any code review
should have caught - if the code was written properly in the first place.

Basic input validation and sanitization isn't that difficult.

I write comms code - client- and server-side middleware. I wouldn't dream
of implementing a protocol with code that didn't sanity-check the data it
gets off the wire. I don't see any reason why browser writers shouldn't be
held to the same standard. Avoiding unsafe assumptions when processing
input should not add significantly to develompment time; if it does, you
need to retrain your developers.

--
Michael Wojcik
Principal Software Systems Developer, Micro Focus

--==_Exmh_929087164P
Content-Type: text/plain; charset=us-ascii

On Wed, 27 Oct 2004 06:32:07 PDT, Michael Wojcik said:

> > "A program designed for inputs from people is usually stressed beyond
> > breaking point by computer-generated inputs. -- Dennis Ritchie
>
> Moot. Since HTML is frequently computer-generated, HTML renderers shouldn't
> be designed for human-generated input.

Not moot at all. Remember that an array of test cases is human-generated
inputs - and the renderer is usually mostly tested against said inputs.

And even more to the point - automated testing isn't a panacea either.
Just because you've "fixed" the browser so it doesn't crash when you
point it at file:///dev/urandom (or moral equivalent) doesn't mean that
you've achieved good coverage.

Somebody else mentioned a "1 million random events" test for Palm programs.
The problem is that although a test like that *will* shake out a lot of bugs,
and is probably useful for that, it is *NOT*, repeat *NOT* likely to trip over
the same bugs as somebody who looks carefully at the application, and realizes
that if they feed it a string '../../../../../..' (256 levels deep), and then
hit control-Z while it's evaluating that path, they get it into a state that
you didn't want them getting it into.

Remember - if you're not feeding it raw /dev/urandom, you're probably feeding
it something "similar to html, but malformed" - and at that point you have a
problem, because the program is restricted to testing the sorts of
malformations you've taught it to generate, and it *won't* in general generate
any malformed html that you've not conceived of (in other words, it almost
certainly won't create a test case for one of the Unicode directory traversal
attacks unless you've taught it about Unicode....)

> I think that's a straw man, Valdis. HTML renderers should expect malformed
> HTML input, and dealing with it is not difficult. There's simply no excuse
> for buffer overflows and null pointer dereferences when processing HTML.
> It's just not that hard a problem. It's not a matter of exhaustive testing;
> the kinds of bugs found by Mangleme are basic ones that any code review
> should have caught - if the code was written properly in the first place.

I was speaking more in general - although it's *true* that there should be
basic sanity checking, the *general* problem is that the programmer can't, in
general, write code to protect against bugs he hasn't conceived of.

> Basic input validation and sanitization isn't that difficult.

Yes, *basic* validation isn't that hard. It's the corner cases that end up
biting you most of the time.

> I write comms code - client- and server-side middleware. I wouldn't dream
> of implementing a protocol with code that didn't sanity-check the data it
> gets off the wire.

And you've *never* shipped a release that had a bug reported against it, and
when you looked at it, you did a Homer Simpson and said "D'Oh!"?

> I don't see any reason why browser writers shouldn't be
> held to the same standard. Avoiding unsafe assumptions when processing
> input should not add significantly to develompment time; if it does, you
> need to retrain your developers.

How much would it have added to development time to have closed *all* the holes
*up front* (including *thinking* of them) to stop Liu Die Yu's "Six Step IE
Remote Compromise Cache Attack"?

Remember what David Brodbeck said, which is what I was replying to:

> How many times have you seen a word processor
> crash due to an unfortunate sequence of commands or opening a corrupted
> file, for example?

The point people are missing is that covering all (or even anywhere *near*
"all") the "unfortunate sequences" or "corrupted files" is *really really*
hard, Quite often, "unfortunate sequence" means something like "issue the
command to open a file" followed by "hit 'cancel' while the program is waiting
for the next block from the disk to feed to a decompressor routine, causing the
program to fail to clean up all memory allocated during the decompression,
because the decompressor routine thought keyboard events were blocked, but
somebody else changed code so they weren't blocked, which doesn't do anything
immediately fatal, but results in a double-free error the next time you try to
print a file".

Let me know when an automated test event generator manages to trigger *THAT*
case.

(And if you think it's a totally spurious made up condition, go look at
why zlib 1.1.4 was released - I've not exaggerated *that* much...)




--==_Exmh_929087164P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFBf8uDcC3lWbTT17ARAgB1AKCJsOG8eso50nDye+BbEF +wCRu7HwCfSB+I
CiE39Njmk3Q9AW2MNEw1qOc=
=e7S+
-----END PGP SIGNATURE-----

--==_Exmh_929087164P--

> From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu]
> Sent: Wednesday, 27 October, 2004 12:24
>
> On Wed, 27 Oct 2004 06:32:07 PDT, Michael Wojcik said:
>
> > > "A program designed for inputs from people is usually
> > > stressed beyond breaking point by computer-generated inputs.
> > > -- Dennis Ritchie
> >
> > Moot. Since HTML is frequently computer-generated, HTML
> > renderers shouldn't be designed for human-generated input.
>
> Not moot at all. Remember that an array of test cases is
> human-generated inputs - and the renderer is usually mostly
> tested against said inputs.

So what? Ritchie wrote "a program designed for inputs from people". My
point is that an HTML renderer should not be designed for inputs from
people. If it is, it's misdesigned.

(And test cases can obviously include machine-generated input. Nothing
about a test case mandates that the input be human-generated.)

> And even more to the point - automated testing isn't a panacea
> either.

I never claimed it was. In fact, my point was precisely the opposite.

> Just because you've "fixed" the browser so it doesn't crash when
> you point it at file:///dev/urandom (or moral equivalent) doesn't
> mean that you've achieved good coverage.

More straw men. Where did I ever argue otherwise? Where did anyone in this
thread argue otherwise?

> > I think that's a straw man, Valdis. HTML renderers should
> > expect malformed HTML input, and dealing with it is not
> > difficult.
>
> I was speaking more in general - although it's *true* that
> there should be basic sanity checking, the *general* problem is
> that the programmer can't, in general, write code to protect
> against bugs he hasn't conceived of.

I don't believe that's correct. In general, programmers can protect against
classes of bugs without prior understanding of those bugs.

You don't have to understand how to exploit a buffer overflow in order to
avoid overflowing buffers. You don't have to understand SQL code-injection
attacks to restrict SQL input fields to valid characters. You don't have to
understand cross-site scripting by embedded HTML to strip or sanitize HTML
tags from user-supplied input that shouldn't have them. You don't need to
understand how signed-integer overflow could cause a problem to check for
it. And so on.

*In general*, if programmers enforce contracts rather than assuming them (by
validating input, checking sizes, checking for error returns, and so forth),
they eliminate entire categories of bugs without having to know anything at
all about them.

> > Basic input validation and sanitization isn't that difficult.
>
> Yes, *basic* validation isn't that hard. It's the corner
> cases that end up biting you most of the time.

I don't believe this is true, statistically. Most of the bugs I see come
through Bugtraq aren't corner cases at all. They're basic errors, like not
checking that input doesn't overflow a buffer. I suspect careful analysis
of the archives would bear that out: few of the prominent bugs, or indeed
all the reported bugs, represent unusual conditions. They just represent
conditions that the programmers were too lazy to check for.

> > I write comms code - client- and server-side middleware. I
> > wouldn't dream of implementing a protocol with code that didn't
> > sanity-check the data it gets off the wire.
>
> And you've *never* shipped a release that had a bug reported
> against it, and when you looked at it, you did a Homer Simpson
> and said "D'Oh!"?

What a large pile of straw you have at your disposal. That's a mighty
conceptual leap, from "my protocol implementations sanity-check their input"
to "there are never dumb bugs in the products that include them".

I always put on my seat belt when I drive my car. That doesn't mean I've
never been in an accident.

I stand by what I wrote: when I implement a protocol, the data off the wire
is sanity-checked. It doesn't overflow input buffers, and the parser
doesn't read past the end of the input. Parameters are examined for sane
values. Return codes are checked.

And if I were writing an HTML renderer, the same would be true there. It's
very little additional effort, amortized over the product lifetime.

> > I don't see any reason why browser writers shouldn't be
> > held to the same standard. Avoiding unsafe assumptions
> > when processing input should not add significantly to
> > develompment time; if it does, you need to retrain your
> > developers.
>
> How much would it have added to development time to have
> closed *all* the holes *up front* (including *thinking* of them)

"thinking of them" isn't a prerequisite.

> to stop Liu Die Yu's "Six Step IE Remote Compromise Cache
> Attack"?

Another straw man. My argument was "avoiding unsafe assumptions when
processing input should not add significantly to development time". (From
context it should be clear that this refers specifically to *direct*
processing of the input, such as receiving and parsing it. Obviously, a
sufficiently broad definition of "processing input" could include everything
a program does.) That is in no way equivalent to "clos[ing] all the holes"
in Six-Step, particularly since several of the steps have nothing to do with
unsafe assumptions in input processing; they're cases of IE (and Windows)
being broken as designed.

> Remember what David Brodbeck said, which is what I was replying
> to:
>
> > How many times have you seen a word processor crash due to an
> > unfortunate sequence of commands or opening a corrupted
> > file, for example?
>
> The point people are missing is that covering all (or even
> anywhere *near* "all") the "unfortunate sequences" or "corrupted
> files" is *really really* hard,

And unnecessary, in the latter case. What I'm talking about doesn't require
exhaustive testing. There is no excuse - none - for a word processor
crashing when trying to open a file. Every step in that process, from
performing I/O to parsing the file format to building the internal
representation, can be done safely for arbitrary input.

I'll grant that arbitrary command sequences are certainly more difficult,
since they exercise the entire code base. But that's not what I'm concerned
with here.

--
Michael Wojcik
Principal Software Systems Developer, Micro Focus

6.0.2800.1106 on Win 2k Pro (5.00.2195 SP4) does not crash.

-mike


<gabrield89@hotmail.com> wrote on 10/25/2004 08:00:44 AM:

> In-Reply-To: <20041023001154.F23256@dekadens.coredump.cx>
>
> >
>
> >Last but not least, MSIE gives in:
>
> >
>
> >> Only MSIE appears to be able to consistently handle[*] malformed
>
> >> input well, suggesting this is the only program that underwent
>
> >> rudimentary security QA testing with a similar fuzz utility.
>
> >
>
> >To all those who considered my original post to be a great propaganda
>
> >ammunition for praising MSIE, bad news - although it did take a longer
>
> >while for it to give up - three hours - (impressive by comparison to
>
> >competitors), it eventually did:
>
> >
>
> > http://lcamtuf.coredump.cx/mangleme/...y/ie_die1.html
>
> >
>
> >Tested on 6.0.2800.1106, dies in mshtml.dll. This is a NULL pointer
>
> >dereference, so merely a DoS condition, but still an evident flaw in
>
> >basic HTML parsing.
>
> >
>
>
>
> Testing on Windows 98 running IE 6.0.2800.1106. Nothing happens. IE
> does not crash. Can anyone else confirm this?

> -----Original Message-----
> From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu]

> The point people are missing is that covering all (or even
> anywhere *near* "all") the "unfortunate sequences" or "corrupted files" is

> *really really* hard, Quite often, "unfortunate sequence" means something

> like "issue the command to open a file" followed by "hit 'cancel' while
the
> program is waiting for the next block from the disk to feed to a
decompressor
> routine...

If the *only* bugs we saw in software nowadays were that esoteric, I'd agree
with you. But I'd wager that a good 80-90% of the bugs aren't in this
category; they're "someone typed 'supercalafragalisticexpialadocious' where
the programmer expected them to type 'foo'" bugs. Basic buffer overrun or
input validation cases that could have been caught by automated testing.
But unfortunately people use excuses like the "we can't catch every bug"
argument you're making to excuse themselves from looking very hard for *any*
bugs.

For another example, consider the recent post about a back door in Hawking
routers. Apparently no one at Hawking ever thought to run 'nmap' against
their router before shipping it. Should we excuse them for that because
they "had to ship before the heat death of the universe", as you put it
earlier?

> How much would it have added to development time to have closed *all* the
holes
> *up front* (including *thinking* of them) to stop Liu Die Yu's "Six Step
IE
> Remote Compromise Cache Attack"?

Multi-step IE exploits are another category altogether. A lot of them stem
from one basic design decision -- the "security zone" model. I'm
increasingly of the opinion that the zone model is basically flawed and
there is no way to make it completely secure. But that's another topic.

> From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu]
> Sent: Thursday, 28 October, 2004 14:23
>
> On Wed, 27 Oct 2004 10:42:41 PDT, Michael Wojcik said:
>
> > You don't have to understand how to exploit a buffer overflow in
> > order to avoid overflowing buffers.
>
> But you have to think of a buffer being overflowed to check for
> it.

Anyone who doesn't understand that a finite-size container cannot hold more
than what it can hold is unlikely to manage to write software.

> > You don't have to understand SQL code-injection
> > attacks to restrict SQL input fields to valid characters.
>
> But you have to realize that SQL can be fed invalid
> characters to check for it.

No, you don't. It's enough to have a specification (that is, a contract)
which says that input X must contain data that meets certain criteria. From
that, the careful programmer will write a validation routine that rejects
input which fails to meet that criteria. It doesn't matter whether the
programmer has any understanding of SQL at all, much less what it may do
with its input. It suffices to know that the program specification imposes
requirements on the input.

> > You don't have to understand cross-site scripting by embedded
> > HTML to strip or sanitize HTML tags from user-supplied input
> > that shouldn't have them.
>
> But you need to know which tags are safe and why, in order to
> strip or sanitize it correctly.

No you don't. You just have to sanitize the input. The HTML specification
says that certain characters have special meaning and must be replaced with
character entities in ordinary text. If the program is producing output
that's supposed to be ordinary text, for consumption by an HTML agent, it
must perform those replacements. End of story. There's no need whatsoever
for the person writing that code to know anything more about HTML than which
characters need to be replaced, and with what. In fact, even that's
unnecessary, because the specification for the program should note that
those characters need to be replaced; the programmer can remain entirely
ignorant of HTML.

> > You don't need to understand how signed-integer overflow could
> > cause a problem to check for it.
>
> But you need to understand it *can* be a problem to check for it..

See "finite-size container" above. I prefer to use code not written by
idiots.

> But you need to understand at least the basics of THAT one to
> check for it, too...
>
> Puzzled by what goes there? Good. So am I - *neither* of us
> thought of it.

Now it's *invisible* straw men.

> And that's the point - whatever goes in that blank space was
> certainly just as big a problem as SQL injection or integer
> overflows or double-frees.

Really? I find it hard to be certain about imaginary entities, myself.

> But we're both only human, and we'll look silly when the advisory
> hits BugTraq or Full-Disclosure, and everybody will say "Look at
> that, yet another dumb-ass programmer that didn't know enough to
> check for *THAT*".

Ah, so this really boils down to "if we can't expect programmers to
anticipate all bugs, we can't expect them to anticipate any".

If you can't see where the fallacy is in *that*, then I don't see much point
in continuing this discussion.

I'm really not interested in excuses for programmers who fail to demonstrate
even a little discipline in their work. And that's precisely what Mangleme
has shown.

--
Michael Wojcik
Principal Software Systems Developer, Micro Focus

--==_Exmh_1694389092P
Content-Type: text/plain; charset=us-ascii

On Wed, 27 Oct 2004 10:42:41 PDT, Michael Wojcik said:

(Quoting two blocks in reverse order to make the point more obvious..)
> > How much would it have added to development time to have
> > closed *all* the holes *up front* (including *thinking* of them)
>
> "thinking of them" isn't a prerequisite.

Actually, it is... see below..

> You don't have to understand how to exploit a buffer overflow in order to
> avoid overflowing buffers.

But you have to think of a buffer being overflowed to check for it.

> You don't have to understand SQL code-injection
> attacks to restrict SQL input fields to valid characters.

But you have to realize that SQL can be fed invalid characters to check for it.

> You don't have to
> understand cross-site scripting by embedded HTML to strip or sanitize HTML
> tags from user-supplied input that shouldn't have them.

But you need to know which tags are safe and why, in order to strip or sanitize
it correctly.

> You don't need to
> understand how signed-integer overflow could cause a problem to check for
> it.

But you need to understand it *can* be a problem to check for it..

>
>
>

But you need to understand at least the basics of THAT one to check for it, too...

Puzzled by what goes there? Good. So am I - *neither* of us thought of it.

And that's the point - whatever goes in that blank space was certainly just as
big a problem as SQL injection or integer overflows or double-frees. But we're
both only human, and we'll look silly when the advisory hits BugTraq or
Full-Disclosure, and everybody will say "Look at that, yet another dumb-ass
programmer that didn't know enough to check for *THAT*". But what probably
happened was the phone rang at the wrong time, and the lines of code that
checked for it evaporated just as surely as the tail end of Samuel Coleridge's
poem 'Xanadu'......


--==_Exmh_1694389092P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFBgTj8cC3lWbTT17ARAvjoAKCJYydVPMF03iivkryGqU 2fj11v2ACeIaC7
2GP/9A44U2W6sOLzMhIYSOY=
=S4wz
-----END PGP SIGNATURE-----

--==_Exmh_1694389092P--

--==_Exmh_-1439548546P
Content-Type: text/plain; charset=us-ascii

On Fri, 29 Oct 2004 15:25:26 EDT, David Brodbeck said:

> This suggests that it's reasonable for a program to segfault because the
> user made a mistake, instead of having some non-fatal form of error
> handling. I don't think that should be acceptable at all, though I agree
> it's very common. If I had a dollar for every time I've lost work because a
> segfault or GPF happened before I saved my document...

The problem is that if you say "it isn't acceptable at all", then you *VERY*
quickly end up with almost *NO* software that's "acceptable".

All software is buggy. *ALL* of it. Learn to accept it. Making a "this is not
acceptable" declaration about something that in general is not totally
preventable is just doomed to failure.

Also, remember that programmer time is *FINITE*. Would you have been willing
to not have the last 3 "this is indispensable" features in your favorite
software in order that the programmers track down every single possible
failure mode? Would you give up 2? 1?

Most software projects could probably fairly easily eliminate (rough guess)
some 75-90% of the really bonehead errors via better programming methodology
and automated software testers/verifiers - but after that, it's going to be
*really* hard to get much further improvement.

There are no silver bullets....


--==_Exmh_-1439548546P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFBgpxKcC3lWbTT17ARAmcJAKC2UCA2XB1VPjeBPlP3IC VYRMnGjACgi0Ci
BGvxLJI9x1vfN1om6d3eiWQ=
=ZpHq
-----END PGP SIGNATURE-----

--==_Exmh_-1439548546P--

--qcTtWMBd/uZDG7+Y
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 28, 2004 at 12:09:22PM -0700, Michael Wojcik wrote:
> It's enough to have a specification

Then you end up shifting the problem to the person to write it.

Writing a spec with *that* detail level is nothing else but
programming in pseudocode.

The net result is that at some level people who do the job loose
control over the situation -- either due to the "plain" problem
being just overly broad, or due to the *neccessary* depth of
non-abstraction (as an effect of code coupling) to overflow
finite-sized human mind. Even though "they should/must".

So you are both right -- maybe it's worth a step off the opposite
corners of the very same soapbox?

Just my UAH.02

--=20
---- WBR, Michael Shigorin <mike@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/

--qcTtWMBd/uZDG7+Y
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBgoTobsPDprYMm3IRAnXuAKDGb82VLqU6lIdeDa+Ljw BVQLvXFgCg01CT
pvSf+yO4LDRXcEiI6Y30iTc=
=3NX7
-----END PGP SIGNATURE-----

--qcTtWMBd/uZDG7+Y--

> > From: Tim Newsham [mailto:newsham@lava.net]
>
> > But lets assume that a good programmer is writing software and
> > it comes to his attention that there is a buffer overflow, or
> > that user input is not being filtered, or that user input is being
> > passed to a printf type function. What happens next? Well, it
> > depends on how many bugs there are, how much other work needs
> > to be done, and very importantly, what the perceived impact of
> > that bug is. You cannot imagine how many times a bug is pointed
> > out and the author of the software says "ok, that bug can only
> > happen if the user does something stupid, and it is not exploitable.
> > Lets defer that one."
>
> This suggests that it's reasonable for a program to segfault because the
> user made a mistake, instead of having some non-fatal form of error
> handling. I don't think that should be acceptable at all, though I agree
> it's very common. If I had a dollar for every time I've lost work because a
> segfault or GPF happened before I saved my document...

A "defer" means "we'll fix it, but we have more important things to
do first." I wouldn't say its an acceptance that its "reasonable"
behavior.

Tim N.

> > > You don't have to understand how to exploit a buffer overflow in
> > > order to avoid overflowing buffers.
> >
> > But you have to think of a buffer being overflowed to check for
> > it.
>
> Anyone who doesn't understand that a finite-size container cannot hold more
> than what it can hold is unlikely to manage to write software.

Michael, the entire premise of your posting is that a programmer
can write secure code without knowing what constitutes exploitable
code. I'm going to have to strongly disagree.

It might be the case that a programmer recognizes that there is
a bug present when there is a fixed sized container and its possible
to put more into it than it should be able to contain. Even this
is not always the case. Heck, I write software and sometimes
there are buffer overflows in my own code that I dont recognize
at first, and I get paid to analyze software looking for problems
like this.

But lets assume that a good programmer is writing software and
it comes to his attention that there is a buffer overflow, or
that user input is not being filtered, or that user input is being
passed to a printf type function. What happens next? Well, it
depends on how many bugs there are, how much other work needs
to be done, and very importantly, what the perceived impact of
that bug is. You cannot imagine how many times a bug is pointed
out and the author of the software says "ok, that bug can only
happen if the user does something stupid, and it is not exploitable.
Lets defer that one." It turns out that these bugs are exploitable
a lot more often than most non-security people know. It can even
be hard for people who do this for a living to make the proper
determination without lots and lots of analysis and head banging,
but that's another discussion...

In summary, I think its very important that software writers understand,
at least in some minimal way, what constitutes an exploitable security
vulnerability. You cannot expect to write code that is free of
security defects without understanding the principles. (Ok, in fairness
you can't really expect to write code that is free of security
defects even when you understand the principles, but at least it
helps).

> Michael Wojcik
> Principal Software Systems Developer, Micro Focus

Tim N.