Text 6757, 257 rader
Skriven 2005-08-27 18:22:14 av Rich (1:379/45)
Kommentar till text 6754 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_0231_01C5AB34.407B2AF0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
According to you his interest is asking other people to do the work =
for which he is not doing something to make it easy. Seems like a = copout to
me. Not that any of this will change your claimed opinions.
Rich
"Mike '/m'" <mike@barkto.com> wrote in message =
news:qdj1h1tmqmpl5fop0km2s8g4jhl6sbqfso@4ax.com...
Yup, Mr. Deraadt is keen on improving software quality.
Unlike Bill Gates who said, "If you can't make it good, make it look
good."
/m
On Sat, 27 Aug 2005 11:38:03 -0700, "Rich" <@> wrote:
> 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_0231_01C5AB34.407B2AF0
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> According to you his =
interest is=20
asking other people to do the work for which he is not doing something = to
make=20
it easy. Seems like a copout to me. Not that any of this = will
change=20
your claimed opinions.</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>
<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:qdj1h1tmqmpl5fop0km2s8g4jhl6sbqfso@4ax.com">news:qdj1h1tmqmp=
l5fop0km2s8g4jhl6sbqfso@4ax.com</A>...</DIV><BR>Yup,=20
Mr. Deraadt is keen on improving software quality.<BR><BR>Unlike Bill =
Gates=20
who said, "If you can't make it good, make it =
look<BR>good."<BR><BR><BR> =20
/m<BR><BR>On Sat, 27 Aug 2005 11:38:03 -0700, "Rich" <@>=20
wrote:<BR><BR>> What I found significant about your =
quote is=20
that it ends with the following appeal. It is clear he wants =
such=20
problems found. It is silly to expect this but not to make an =
effort to=20
make this easy.<BR>><BR>> We ask our users to help us =
uncover and=20
fix more of these bugs in<BR>> applications. Some will =
even be=20
exploitable. Instead of saying that<BR>> OpenBSD is =
busted in=20
this regard, please realize that the software<BR>> which is =
crashing=20
is showing how shoddily it was written. Then help<BR>> =
us fix=20
it. For everyone.. not just OpenBSD users<BR>><BR>>You=20
misunderstand if you believe buffer overflows and underflows won't run =
into=20
other data. First, this is for the heap not for the stack. =
Both=20
are dangerous but stack overflows are probably still more =
common. =20
Second, memory is allocated in units of at least a page and probably =
larger=20
units. Most allocations are preceeded and followed by other=20
allocations.<BR>><BR>>Rich<BR>><BR>><BR>> "Mike =
'/m'"=20
<<A href=3D"mailto:mike@barkto.com">mike@barkto.com</A>> wrote =
in message=20
<A=20
=
href=3D"news:3l61h19q3gjomo2jtvs3td7cri8ajgs95i@4ax.com">news:3l61h19q3gj=
omo2jtvs3td7cri8ajgs95i@4ax.com</A>...<BR>> =20
I see the malloc/free improvements as more for runtime benefit,=20
i.e.,<BR>> buffer overflow exploits and such. Exploits =
won't be=20
able to use memory<BR>> addresses as easily as before, =
because malloc=20
randomizes them at<BR>> runtime, buffer underflow/overflow =
exploits=20
run into out-of-process<BR>> memory and not the next =
variable,=20
etc. Mr. DeRaadt's message explains<BR>> quite a bit =
about the=20
runtime aspect of the enhancements.<BR>><BR>> There are =
other open=20
source tools for developers that do what you<BR>> =
suggest. The=20
paragraph you quote indicates that more developers =
should<BR>> use=20
those tools, and that the new runtime enhancements will make=20
such<BR>> errors easier to track =
down.<BR>><BR>> =20
/m<BR>><BR>><BR>> On Sat, 27 Aug 2005 09:05:34 -0700, =
"Rich"=20
<@> wrote:<BR>><BR>> > OK. They =
can=20
continue to find issues with luck at random. Why make any effort =
to=20
increase quality?<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:50q0h1tf5m86ehvd13p849uq42pdsqu45v@4ax.com">news:50q0h1tf5m8=
6ehvd13p849uq42pdsqu45v@4ax.com</A>...<BR>> =20
><BR>> > MRD<BR>> ><BR>> =
> =20
On Fri, 26 Aug 2005 22:09:56 -0700, "Rich" <@> =
wrote:<BR>> =20
><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>> > =20
>Rich<BR>> > ><BR>> > =
> =20
"Mike '/m'" <<A =
href=3D"mailto:mike@barkto.com">mike@barkto.com</A>> wrote=20
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 will find more bugs in software, =
and=20
this<BR>> > > might hurt our user community =
in the=20
short term. We know that what<BR>> > =
> this=20
new malloc is doing is perfectly legal, but that =
realistically<BR>> =20
> > some open source software is of such low quality =
that it=20
is just not<BR>> > > ready for these things =
to=20
happen.<BR>> > ><BR>> > =
> =20
=3D=3D=3D<BR>> > ><BR>> > =20
> /m</BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0231_01C5AB34.407B2AF0--
--- BBBS/NT v4.01 Flag-5
* Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)
|