Text 5301, 321 rader
Skriven 2005-06-22 16:40:38 av Rich (1:379/45)
Kommentar till text 5294 av John Cuccia (1:379/45)
Ärende: Re: Vulnerabilities vs. exploits
========================================
From: "Rich" <@>
This is a multi-part message in MIME format.
------=_NextPart_000_0257_01C57749.1F6BE5D0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Let me give an example that might help. Someone comes to you and =
tells you that your home has a vulnerability that may collapses the = supports
holding up the second floor. He goes on to describe the = exploit which
involves starting an water leak near the supports. You = fix the problem
exposed the potential water leak. You may or may not = see any risk to the
supports though the guy reporting the water leak = claims that he has collapsed
his supports. When you tell people about = the leak and the fix do you or do
you not report a risk to the supports?
Rich
"John Cuccia" <jcuccia@bigfoot.com> wrote in message =
news:u1djb1dkjvvqk9j4clgajl86tuhtsott6j@4ax.com...
Well, I've read the thread between you and Geo and I am confused.
Would you mind explaining again, please?
On Wed, 22 Jun 2005 09:53:05 -0700, "Rich" <@> wrote:
> No.
>
>Rich
>
> "John Cuccia" <jcuccia@bigfoot.com> wrote in message =
news:7b5jb11hl045bp0bvldldmbc27ltp5jusv@4ax.com...
> So you are saying that the author of: "Microsoft Security Bulletin
> MS01-059 - Unchecked Buffer in Universal Plug and Play can Lead to
> System Compromise", which claims the problem to be an unchecked =
buffer
> in UPnP was parroting what was reported to Microsoft, but was wrong
> about the nature of the problem?
>
> I'm confused here. What good are inaccurate security bulletins?
>
> On Wed, 22 Jun 2005 09:44:42 -0700, "Rich" <@> wrote:
>
> > There was no overrun to fix.
> >
> >Rich
> >
> > "Geo" <georger@nls.net> wrote in message =
news:42b9383a@w3.nls.net...
> > Translation, the issue of buffer overrun in the MS bulletin was =
a separate patch from the patch for the race condition you mentioned = however
the patch for the race condition also would have fixed the = buffer overrun
issue?
> >
> > Geo.
> > "Rich" <@> wrote in message news:42b8c753$1@w3.nls.net...
> > I'm not sure what your first and second represent so I =
couldn't answer even if I could parse it out. How about, maybe.
> >
> > Rich
> >
> > "Geo" <georger@nls.net> wrote in message =
news:42b8ad5b@w3.nls.net...
> > Oh, so then it was two different issues, one just exposed a =
second which if the second was fixed could have resolved the first issue = as
well?
> >
> > Geo.
> > "Rich" <@> wrote in message news:42b83849@w3.nls.net...
> > Yes, the fix in the bulletin did fix the problem =
reported. There were other scenarios that exposed the race that was = fixed
later. It wasn't in a UPnP component.
> >
> > Rich
> >
> > "Geo" <georger@nls.net> wrote in message =
news:42b7e6d9$1@w3.nls.net...
> > I suppose it's possible, and I'm familiar with your =
technical level so I'll give you the benefit of the doubt and believe = you
know the truth in this case but it still makes no sense to me = because I've
seen the security bulletins correct publicly posted = vulnerability reports
before.
> >
> > I do have a question though, after the patch did you =
test to see if the issue you were seeing was corrected? I mean I suppose = any
change in the code could fix a race condition but I'm asking = specifically if
you tested the fix?
> >
> > Geo.
> > "Rich" <@> wrote in message =
news:42b79696@w3.nls.net...
> > I disagree and this is an example. The reporter =
claimed there were overflows even though the repro he provided and the = one he
describes in his PR demonstrates none. Who knows, maybe he knows = a way to
exploit the bug that he is keeping to himself to gain some = advantage. I
disagree about a correction too. There is no proof that = he was not keeping
something to himself for personal advantage. I very = much doubt it but then I
have (or at least had at the time I looked at = it) an very good understanding
of exactly what was going on and that = understanding is 100% consistent with
the facts from the reporter.
> >
> > Really, this is nothing remarkable. The cause of a =
bug and the behavior that can be triggered by exploitation of a bug need = have
little to nothing to do with one another. If you really paid = attention to
the vulnerablities that are reported on the lists as you = suggest, the
symptoms of those vulnerabilities, and the exploits that = can sometimes be
made of them you would see that each of these can be = very different. In this
example I think the reporter did not understand = what he saw (i.e. the first
two) and asserted that he can exploit the = corrupted state to trigger an
overflow elsewhere unrelated to the = original bug and quite likely not a bug
at all. It doesn't matter. = This may seem weird to someone that doesn't
understand code in general = or even the specific code but it's not remarkable
or in most cases even = interesting.
> >
> > Rich
------=_NextPart_000_0257_01C57749.1F6BE5D0
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.2668" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2> Let me give an example =
that might=20
help. Someone comes to you and tells you that your home has a=20
vulnerability that may collapses the supports holding up the second =
floor. =20
He goes on to describe the exploit which involves starting an water leak =
near=20
the supports. You fix the problem exposed the potential water =
leak. =20
You may or may not see any risk to the supports though the guy reporting =
the=20
water leak claims that he has collapsed his supports. When you = tell
people=20
about the leak and the fix do you or do you not report a risk to the=20
supports?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Rich</FONT></DIV>
<DIV> </DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"John Cuccia" <<A=20
href=3D"mailto:jcuccia@bigfoot.com">jcuccia@bigfoot.com</A>> wrote =
in message=20
<A=20
=
href=3D"news:u1djb1dkjvvqk9j4clgajl86tuhtsott6j@4ax.com">news:u1djb1dkjvv=
qk9j4clgajl86tuhtsott6j@4ax.com</A>...</DIV>Well,=20
I've read the thread between you and Geo and I am =
confused.<BR><BR>Would you=20
mind explaining again, please?<BR><BR><BR>On Wed, 22 Jun 2005 09:53:05 =
-0700,=20
"Rich" <@> wrote:<BR><BR>> =20
No.<BR>><BR>>Rich<BR>><BR>> "John Cuccia" <<A=20
href=3D"mailto:jcuccia@bigfoot.com">jcuccia@bigfoot.com</A>> wrote =
in message=20
<A=20
=
href=3D"news:7b5jb11hl045bp0bvldldmbc27ltp5jusv@4ax.com">news:7b5jb11hl04=
5bp0bvldldmbc27ltp5jusv@4ax.com</A>...<BR>> =20
So you are saying that the author of: "Microsoft Security=20
Bulletin<BR>> MS01-059 - Unchecked Buffer in Universal Plug =
and Play=20
can Lead to<BR>> System Compromise", which claims the problem =
to be=20
an unchecked buffer<BR>> in UPnP was parroting what was =
reported to=20
Microsoft, but was wrong<BR>> about the nature of the=20
problem?<BR>><BR>> I'm confused here. What good are=20
inaccurate security bulletins?<BR>><BR>> On Wed, 22 Jun =
2005=20
09:44:42 -0700, "Rich" <@> wrote:<BR>><BR>> =
> =20
There was no overrun to fix.<BR>> ><BR>> =20
>Rich<BR>> ><BR>> > "Geo" <<A=20
href=3D"mailto:georger@nls.net">georger@nls.net</A>> wrote in =
message <A=20
=
href=3D"news:42b9383a@w3.nls.net">news:42b9383a@w3.nls.net</A>...<BR>>=
=20
> Translation, the issue of buffer overrun in the MS bulletin =
was a=20
separate patch from the patch for the race condition you mentioned =
however the=20
patch for the race condition also would have fixed the buffer overrun=20
issue?<BR>> ><BR>> > Geo.<BR>> =20
> "Rich" <@> wrote in message <A=20
=
href=3D"news:42b8c753$1@w3.nls.net">news:42b8c753$1@w3.nls.net</A>...<BR>=
> =20
> I'm not sure what your first =
and=20
second represent so I couldn't answer even if I could parse it =
out. How=20
about, maybe.<BR>> ><BR>> > =20
Rich<BR>> ><BR>> =
> "Geo"=20
<<A href=3D"mailto:georger@nls.net">georger@nls.net</A>> wrote =
in message=20
<A=20
=
href=3D"news:42b8ad5b@w3.nls.net">news:42b8ad5b@w3.nls.net</A>...<BR>>=
=20
> Oh, so then it was two different =
issues,=20
one just exposed a second which if the second was fixed could have =
resolved=20
the first issue as well?<BR>> ><BR>> =20
> Geo.<BR>> =20
> "Rich" <@> wrote =
in=20
message <A=20
=
href=3D"news:42b83849@w3.nls.net">news:42b83849@w3.nls.net</A>...<BR>>=
=20
> Yes, =
the fix=20
in the bulletin did fix the problem reported. There were other =
scenarios=20
that exposed the race that was fixed later. It wasn't in a UPnP=20
component.<BR>> ><BR>> =20
> Rich<BR>> =20
><BR>> =
> =20
"Geo" <<A href=3D"mailto:georger@nls.net">georger@nls.net</A>> =
wrote in=20
message <A=20
=
href=3D"news:42b7e6d9$1@w3.nls.net">news:42b7e6d9$1@w3.nls.net</A>...<BR>=
> =20
> I suppose =
it's=20
possible, and I'm familiar with your technical level so I'll give you =
the=20
benefit of the doubt and believe you know the truth in this case but =
it still=20
makes no sense to me because I've seen the security bulletins correct =
publicly=20
posted vulnerability reports before.<BR>> ><BR>> =20
> I do have a =
question though, after the patch did you test to see if the issue you =
were=20
seeing was corrected? I mean I suppose any change in the code could =
fix a race=20
condition but I'm asking specifically if you tested the =
fix?<BR>> =20
><BR>> =
> =20
Geo.<BR>> =20
> =
"Rich"=20
<@> wrote in message <A=20
=
href=3D"news:42b79696@w3.nls.net">news:42b79696@w3.nls.net</A>...<BR>>=
=20
=
> &nb=
sp; =20
I disagree and this is an example. The reporter claimed there =
were=20
overflows even though the repro he provided and the one he describes =
in his PR=20
demonstrates none. Who knows, maybe he knows a way to exploit =
the bug=20
that he is keeping to himself to gain some advantage. I disagree =
about a=20
correction too. There is no proof that he was not keeping =
something to=20
himself for personal advantage. I very much doubt it but then I =
have (or=20
at least had at the time I looked at it) an very good understanding of =
exactly=20
what was going on and that understanding is 100% consistent with the =
facts=20
from the reporter.<BR>> ><BR>> =20
=
> &nb=
sp; =20
Really, this is nothing remarkable. The cause of a bug and the =
behavior=20
that can be triggered by exploitation of a bug need have little to =
nothing to=20
do with one another. If you really paid attention to the =
vulnerablities=20
that are reported on the lists as you suggest, the symptoms of those=20
vulnerabilities, and the exploits that can sometimes be made of them =
you would=20
see that each of these can be very different. In this example I =
think=20
the reporter did not understand what he saw (i.e. the first two) and =
asserted=20
that he can exploit the corrupted state to trigger an overflow =
elsewhere=20
unrelated to the original bug and quite likely not a bug at all. =
It=20
doesn't matter. This may seem weird to someone that doesn't =
understand=20
code in general or even the specific code but it's not remarkable or =
in most=20
cases even interesting.<BR>> ><BR>> =20
> =
Rich<BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0257_01C57749.1F6BE5D0--
--- BBBS/NT v4.01 Flag-5
* Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)
|