Re: incredible

From: Frank Bemelman (f.bemelmanx_at_xs4all.invalid.nl)
Date: 09/16/04 

Date: Thu, 16 Sep 2004 10:46:43 +0200

"John Larkin" <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> schreef in
bericht news:4fshk09nb1psnf6jf03g607g81r6dr17vb@4ax.com...
> On Thu, 16 Sep 2004 02:25:21 +0200, "Frank Bemelman"
> <f.bemelmanx@xs4all.invalid.nl> wrote:
>
> >"John Larkin" <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> schreef in
> >bericht news:0fehk0pu2lnsvefnus0i6neroqnie39j5a@4ax.com...
> >> On Thu, 16 Sep 2004 07:41:27 +1000, "Adam. Seychell"
> >> <invald@invalid.com> wrote:
> >>
> >> >Dirk Bruere at Neopax wrote:
> >> >
> >> >> John Larkin wrote:
> >> >>
> >> >>> http://www.securityfocus.com/news/9508
> >> >>>
> >> >>
> >> >> "The old bromide that promises you can't get a computer virus by
> >looking
> >> >> at an image file crumbled a bit further Tuesday when Microsoft
> >announced
> >> >> a critical vulnerability in its software's handling of the
ubiquitous
> >> >> JPEG graphics format.
> >> >>
> >> >> The security hole is a buffer overflow that potentially allows an
> >> >> attacker to craft a special JPEG file that would take control of a
> >> >> victim's machine when the user views it through Internet Explorer,
> >> >> Outlook, Word, and other programs. The poisoned picture could be
> >> >> displayed on a website, sent in e-mail, or circulated on a P2P
network.
> >"
> >> >>
> >> >> Utter incompetence - it really is unbelievable.
> >> >>
> >> >
> >> >I'd like to know the relationship between the buffer overflows and a
how
> >> >its possible to exploit the this bug to create malicious code. Is
there
> >> >some functions in the Microsoft image decoding routines that say if a
> >> >buffer overflow then execute a undocumented and secret language format
> >> >imbeded inside JPEG files ? !!!
> >> >
> >> >Can someone please explain what possible like exists between buffer
> >> >overflows and computer viruses ? A buffer overflow is nothing more
than
> >> > an pointer going outside its intended range.
> >> >Has anyone seen proof of this vulnerability yet ?
> >> >
> >> >Adam
> >> >
> >>
> >> It's been done many times. Far too may times.
> >>
> >> Just google "buffer overflow." Or maybe "Microsoft stupidity."
> >
> >Just google for "buffer overflow linux" and "buffer overflow windows".
> >522.000 hits versus 397.000 ;)
> >
> >It's not so much MS stupidity, but more a C problem. Functions like
> >strcpy, scanf, gets, they are all too much relying on decent input
> >that isn't any larger than the reserved buffer. In C++ it is easier
> >to protect yourself, but there is enourmous amount of plain C, even
> >embedded in C++ classes. The leaks are all over the place ;) Each and
> >every classic array declaration is a potential problem.
>
>
> It wouldn't be if the operating system enforced I/D space separation,
> as was an established practice 30 years ago.

30 years ago we were less demanding. No complex user interface and/or
extensive multitasking. Code is data, and data is code. When you type
your message, you create instructions in your undo-redo buffer. What
is is important is integrity.

> I wonder if OOP makes things worse by mixing code and data so
> intimately.

It's the only way to build and maintain the complex software
we are so used to. Without it, software would either be much
simpler, or it would contain even more bugs. Seperating code
and data is not a problem, just allocate everything from the
heap and not locally. This is often too much work for the
programmer, and when not done automagically through well tested
OOP constructors and destructors, it leads to another problem,
such as memory leaks, where you run out of heap memory, which
was a very common problem under WIN3.x etc. And when it is
properly implemented it often leads to memory fragmentation
which is another snack you get for free using malloc() and free().
Large applications do their own memory management, use the
systems malloc() once to get a large chunk of memory, and manage
it themselves from there.

The bottom line is that everything sucks, but the status quo is
a reasonable balance between totally unacceptable and utopia.

It's good to realize that even a lead pencil crashes from time to
time. (snap). Admitted, they recover faster (click-click). 

-- 
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)

Relevant Pages

  • Re: Is this a good idea?
    ... in memory - induces lazyness in the programmers. ... Lazyness leads to more complex code, more complex code leads to more bugs, more bugs leads to more wasted QA time when something breaks down. ...
    (comp.lang.php)
  • Re: Is this a good idea?
    ... > in memory - induces lazyness in the programmers. ... Lazyness leads to more ... A typical database query will return 10K ... To say that reading the data into an array would somehow have ...
    (comp.lang.php)
  • Re: seperate code and : dictionaries?
    ... comma "," having an abiguity in which dictionary to compile within. ... p or machine code memory space. ... but this leads to a problem of accesing ...
    (comp.lang.forth)
  • Re: Devfs question
    ... as devfs is maintained in memory and all files are created ... Bluescreen leads to downtime. ... Downtime leads to suffering. ...
    (freebsd-questions)
  • Re: Pointer and Its memory
    ... I dereference the pointer A using free. ... That is deallocating the memory it points at. ... Note that heap memory is an implementation detail, and not all systems even have a heap. ...
    (comp.lang.c)
Quantcast