Any Danger With The "Buffer Overflow Exploits" by using Assembler Language ?

From: Penang (penang_at_myrealbox.com)
Date: 11/09/04 

Date: 8 Nov 2004 20:21:39 -0800

Hi, all.

There is an interesting op-ed piece on sdtimes, by Jeff Duntemann,
where he talked about the problem that is associated with IE
phenomena.

    The article is available from :
www.sdtimes.com/opinions/guestview_113.htm

In the article, Mr. Duntemann brought up the "Buffer Overflow
Exploits" problem, where he said is linked with C and the C++
languages.

Since I am but a casual programmer, I know my limitation. Therefore, I
want to ask the gurus here for your opinion:

Is the "Buffer Overflow Exploit" uniquely presenting itself with the C
and/or C++ languages ?

What I mean is, if I use assembler language (MASM, NASM, GAS, FASM,
etc), instead of C and/or C++, do I face the same "Buffer Overflow
Exploit" problem ?

I'd appreaciate your opinion on this matter.

                                           Thank you very much !

= = = ===================================================

The Lessons of Software Monoculture
by Jeff Duntemann

November 1, 2004 —

Last summer, much was made of Slate author Paul Boutin's harangue in
his June 30, 2004 "Webhead" column. Boutin basically told his readers
to drop Microsoft's Internet Explorer like a hot rock and move to
Mozilla's Firefox, because of the increasingly nasty security holes
turning up in IE. Problem is, Slate is owned by Microsoft.

Ouch.

It really has gotten that bad, and it's easy to be left with the
impression that Microsoft creates lousy software, rotten with bugs
that allow the black hats to break into our networks and bring the
global Internet to its knees. The anti-Microsoft tomato tossers insist
that if only Microsoft cleaned up its products, we'd be rid of the
security holes and the black hats who thrive on them.

It's not that simple. Microsoft has some of the best programmers in
the world working on its products, and books like "Writing Solid Code"
from the Microsoft developer culture are seen as classics that belong
on every programmer's shelf. Nonetheless, Microsoft software has bugs;
all software has bugs, which is a crucial point that I'll return to
later.

What we have to understand is that our current problems with Internet
Explorer have less to do with bugs than with success. When a product
has 90% of a huge worldwide market, there will be problems. It doesn't
matter what the product is, and it matters only a little how good it
is. What matters is that Internet Explorer is virtually the sole
organism in an ecosystem that the world's technology industry depends
on. When IE catches a cold, the networked world gets pneumonia.

This metaphor from biology is called software monoculture. Ubiquitous
high-bandwidth communication has turned the world of computing from
countless independent islands into a single global ecosystem. The
fewer distinct organisms at work within this ecosystem, the easier it
is for a bug—any bug—to become a threat to the health of the whole.

Worms and viruses that depend on these bugs replicate and travel
automatically, and unless they can assume that the next system is
identical (bugs and all) to the one they're leaving, they can't
propagate as quickly nor do as much damage. If only one in 20 systems
allowed such worms and viruses to take hold (rather than nine out of
10) it's doubtful that they could ever achieve any kind of critical
mass, and would be exterminated before they got too far.

Software monoculture happens for a lot of reasons, only a few of them
due to Microsoft's sales and marketing practices. In the home market,
nontechnical people see safety in numbers: They want to be part of a
crowd so that when something goes wrong, help will be nearby, among
family, friends, or a local user group.

In corporate IT, monoculture happens because IT doesn't want to
support diversity in a software ecosystem. Supporting multiple
technologies costs way more than supporting only one, so IT prefers to
pick a technology and force its use everywhere. Both of these issues
are the result of free choices made for valid reasons. Monoculture is
the result of genuine needs. Technological diversity may be good, but
it costs, in dollars and in effort.

As if that weren't bad enough, there is another kind of software
monoculture haunting us, far below the level of individual
products—down, in fact, at the level of the bugs themselves.

If you give reports of recently discovered security holes in all major
products (not merely Microsoft's) a very close read, you'll find a
peculiar similarity in the bugs themselves. Most of them are "buffer
overflow exploits," and these are almost entirely due to the
shortcomings of a single programming language: C/C++. (C and C++, are
really the same language at the core, where these sorts of bugs
happen.) Virtually all software written in the United States is
written in C/C++. This includes both Windows and Linux, IE and
Firefox. A recent exploit turned up in Firefox that was almost
identical to one in IE. The standard C libraries have more market
share than even Microsoft.

This makes the obvious solution to software monoculture—switching to
something other than Microsoft—problematic. Individual consumers and
individual corporate shops can switch to a minority product, like the
Mac (for consumers) and open-source tools like Linux, Apache,
Evolution, and Mozilla for the corporate enterprise.

But then what happens if Mozilla or the Mac get too popular? They're
all written in C, and they all have those same bugs. Once a product's
market share creeps up toward 50% or so, the effects of monoculture
take hold again. You can run from IE, but if too many people run with
you (and to the same destination) you won't be hiding for long.

Putting today's security hole debacle in perspective requires this
dual understanding of software monoculture. It's not just in the apps,
but in our developer tools as well. Microsoft is almost incidental. It
sounds hopeless, and if what we want to do is fix software monoculture
itself, well, it is hopeless. Standards are good, and you'll pry C and
C++ out of our programmers' cold, dead hands.

No, the real lesson of software monoculture is that, like it or not,
we're all in this together. It's not really about bugs, nor about
Microsoft, nor about software at all. There has always been software
monoculture (am I the only one here old enough to remember when OS/360
ruled the world? Or, hey, PC DOS?) but it took ubiquitous unmanaged
high-bandwidth communication to turn an arcane sort of string buffer
overflow into a global threat. Ducking the unavoidable effects of
software monoculture really means going back to the drawing board and
managing the communications that make one app's problem everybody's
problem. Static packet filtering is clearly not enough. Even stateful
packet inspection may not be enough. The real answer may not have been
invented yet—but if we keep looking in the wrong places, or blaming
the wrong people (Microsoft or anybody else) the black hats will keep
on lighting fires, and the networked world will continue to burn.

Relevant Pages

  • Buffer Overflow Exploits
    ... Slate is owned by Microsoft. ... Nonetheless, Microsoft software has bugs; ... has 90% of a huge worldwide market, ... This metaphor from biology is called software monoculture. ...
    (comp.lang.asm.x86)
  • Re: Best scanning manager program?
    ... the Vuescan author invented after being unable to fix a bug for *two ... author to avoid facing his own bugs and incompetence. ... >> What's also ironic is that after Apple went bankrupt and the evil ... >> everything he said against Microsoft. ...
    (comp.periphs.scanners)
  • Re: Bug Triad Whacks Microsoft Browser
    ... > Bug Triad Whacks Microsoft Browser ... > combine to send a Windows system up in flames. ... > security group has stitched together two minor flaws in ... > patching security bugs that it considers minor. ...
    (microsoft.public.security)
  • Bug Triad Whacks Microsoft Browser
    ... Bug Triad Whacks Microsoft Browser ... Researchers discover that three "low risk" bugs can ... combine to send a Windows system up in flames. ... To prove that no security bug is truly harmless, ...
    (microsoft.public.security)