Text 6751, 204 rader
Skriven 2005-08-27 11:38:02 av Rich (1:379/45)
Kommentar till text 6746 av Mike '/m' (1:379/45)
Ärende: Re: malloc() and free() redux
=====================================
From: "Rich" <@>
This is a multi-part message in MIME format.
------=_NextPart_000_0207_01C5AAFB.C8FB9010
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
What I found significant about your quote is that it ends with the =
following appeal. It is clear he wants such problems found. It is = silly to
expect this but not to make an effort to make this easy.
We ask our users to help us uncover and fix more of these bugs in
applications. Some will even be exploitable. Instead of saying that
OpenBSD is busted in this regard, please realize that the software
which is crashing is showing how shoddily it was written. Then help
us fix it. For everyone.. not just OpenBSD users
You misunderstand if you believe buffer overflows and underflows won't = run
into other data. First, this is for the heap not for the stack. = Both are
dangerous but stack overflows are probably still more common. = Second, memory
is allocated in units of at least a page and probably = larger units. Most
allocations are preceeded and followed by other = allocations.
Rich
"Mike '/m'" <mike@barkto.com> wrote in message =
news:3l61h19q3gjomo2jtvs3td7cri8ajgs95i@4ax.com...
I see the malloc/free improvements as more for runtime benefit, i.e.,
buffer overflow exploits and such. Exploits won't be able to use =
memory
addresses as easily as before, because malloc randomizes them at
runtime, buffer underflow/overflow exploits run into out-of-process
memory and not the next variable, etc. Mr. DeRaadt's message explains
quite a bit about the runtime aspect of the enhancements.
There are other open source tools for developers that do what you
suggest. The paragraph you quote indicates that more developers =
should
use those tools, and that the new runtime enhancements will make such
errors easier to track down.
/m
On Sat, 27 Aug 2005 09:05:34 -0700, "Rich" <@> wrote:
> OK. They can continue to find issues with luck at random. Why =
make any effort to increase quality?
>
>Rich
>
> "Mike '/m'" <mike@barkto.com> wrote in message =
news:50q0h1tf5m86ehvd13p849uq42pdsqu45v@4ax.com...
>
> MRD
>
> On Fri, 26 Aug 2005 22:09:56 -0700, "Rich" <@> wrote:
>
> > For many years Windows has had mechanisms to force unmap after =
free, guard pages, and the like to make it easier for developers to = catch
heap overruns, use after free, double free, etc. If the openbsd = folks were
smart they would do the same.
> >
> >Rich
> >
> > "Mike '/m'" <mike@barkto.com> wrote in message =
news:5ldvg1tlt8qietjcqrt0jakcnukm5sp7it@4ax.com...
> >
> >
> > We expect that our malloc will find more bugs in software, and =
this
> > might hurt our user community in the short term. We know that =
what
> > this new malloc is doing is perfectly legal, but that =
realistically
> > some open source software is of such low quality that it is just =
not
> > ready for these things to happen.
> >
> > =3D=3D=3D
> >
> > /m
------=_NextPart_000_0207_01C5AAFB.C8FB9010
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2722" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2> What I found significant =
about your=20
quote is that it ends with the following appeal. It is = clear
he=20
wants such problems found. It is silly to expect this but not to = make
an=20
effort to make this easy.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV><FONT color=3D#008000>We ask our users to help us uncover and fix =
more of=20
these bugs in<BR>applications. Some will even be =
exploitable. =20
Instead of saying that<BR>OpenBSD is busted in this regard, please =
realize=20
that the software<BR>which is crashing is showing how shoddily it was=20
written. Then help<BR>us fix it. For everyone.. not just =
OpenBSD=20
users</FONT></DIV></BLOCKQUOTE>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>You misunderstand if you believe buffer =
overflows=20
and underflows won't run into other data. First, this is for the = heap
not=20
for the stack. Both are dangerous but stack overflows are probably =
still=20
more common. Second, memory is allocated in units of at least a = page
and=20
probably larger units. Most allocations are preceeded and followed =
by=20
other allocations.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Rich</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Mike '/m'" <<A =
href=3D"mailto:mike@barkto.com">mike@barkto.com</A>>=20
wrote in message <A=20
=
href=3D"news:3l61h19q3gjomo2jtvs3td7cri8ajgs95i@4ax.com">news:3l61h19q3gj=
omo2jtvs3td7cri8ajgs95i@4ax.com</A>...</DIV>I=20
see the malloc/free improvements as more for runtime benefit, =
i.e.,<BR>buffer=20
overflow exploits and such. Exploits won't be able to use=20
memory<BR>addresses as easily as before, because malloc randomizes =
them=20
at<BR>runtime, buffer underflow/overflow exploits run into=20
out-of-process<BR>memory and not the next variable, etc. Mr. =
DeRaadt's=20
message explains<BR>quite a bit about the runtime aspect of the=20
enhancements.<BR><BR>There are other open source tools for developers =
that do=20
what you<BR>suggest. The paragraph you quote indicates that more =
developers should<BR>use those tools, and that the new runtime =
enhancements=20
will make such<BR>errors easier to track =
down.<BR><BR> /m<BR><BR><BR>On=20
Sat, 27 Aug 2005 09:05:34 -0700, "Rich" <@>=20
wrote:<BR><BR>> OK. They can continue to find =
issues with=20
luck at random. Why make any effort to increase=20
quality?<BR>><BR>>Rich<BR>><BR>> "Mike '/m'" <<A=20
href=3D"mailto:mike@barkto.com">mike@barkto.com</A>> wrote in =
message <A=20
=
href=3D"news:50q0h1tf5m86ehvd13p849uq42pdsqu45v@4ax.com">news:50q0h1tf5m8=
6ehvd13p849uq42pdsqu45v@4ax.com</A>...<BR>><BR>> =20
MRD<BR>><BR>> On Fri, 26 Aug 2005 22:09:56 -0700, "Rich" =
<@>=20
wrote:<BR>><BR>> > For many years Windows =
has had=20
mechanisms to force unmap after free, guard pages, and the like to =
make it=20
easier for developers to catch heap overruns, use after free, double =
free,=20
etc. If the openbsd folks were smart they would do the=20
same.<BR>> ><BR>> >Rich<BR>> =20
><BR>> > "Mike '/m'" <<A=20
href=3D"mailto:mike@barkto.com">mike@barkto.com</A>> wrote in =
message <A=20
=
href=3D"news:5ldvg1tlt8qietjcqrt0jakcnukm5sp7it@4ax.com">news:5ldvg1tlt8q=
ietjcqrt0jakcnukm5sp7it@4ax.com</A>...<BR>> =20
><BR>> ><BR>> > We expect that our =
malloc=20
will find more bugs in software, and this<BR>> > =
might hurt=20
our user community in the short term. We know that =
what<BR>> =20
> this new malloc is doing is perfectly legal, but that=20
realistically<BR>> > some open source software is of =
such=20
low quality that it is just not<BR>> > ready for =
these=20
things to happen.<BR>> ><BR>> > =20
=3D=3D=3D<BR>> ><BR>> > =20
/m</BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0207_01C5AAFB.C8FB9010--
--- BBBS/NT v4.01 Flag-5
* Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)
|