Text 5292, 266 rader
Skriven 2005-06-22 09:53:04 av Rich (1:379/45)
Kommentar till text 5291 av John Cuccia (1:379/45)
Ärende: Re: Vulnerabilities vs. exploits
========================================
From: "Rich" <@>
This is a multi-part message in MIME format.
------=_NextPart_000_024B_01C57710.2FAE95C0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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_024B_01C57710.2FAE95C0
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> No.</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>"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>...</DIV>So=20
you are saying that the author of: "Microsoft Security =
Bulletin<BR>MS01-059 -=20
Unchecked Buffer in Universal Plug and Play can Lead to<BR>System =
Compromise",=20
which claims the problem to be an unchecked buffer<BR>in UPnP was =
parroting=20
what was reported to Microsoft, but was wrong<BR>about the nature of =
the=20
problem?<BR><BR>I'm confused here. What good are inaccurate =
security=20
bulletins?<BR><BR>On Wed, 22 Jun 2005 09:44:42 -0700, "Rich" <@> =
wrote:<BR><BR>> There was no overrun to=20
fix.<BR>><BR>>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 =
separate=20
patch from the patch for the race condition you mentioned however the =
patch=20
for the race condition also would have fixed the buffer overrun=20
issue?<BR>><BR>> Geo.<BR>> "Rich" =
<@>=20
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 second represent so I couldn't answer =
even if=20
I could parse it out. How about,=20
maybe.<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:42b8ad5b@w3.nls.net">news:42b8ad5b@w3.nls.net</A>...<BR>>=
=20
Oh, so then it was two different issues, one just exposed a second =
which if=20
the second was fixed could have resolved the first issue as=20
well?<BR>><BR>> =20
Geo.<BR>> "Rich" =
<@> wrote=20
in message <A=20
=
href=3D"news:42b83849@w3.nls.net">news:42b83849@w3.nls.net</A>...<BR>>=
=20
Yes, the fix in the bulletin did fix the problem reported. There =
were=20
other scenarios that exposed the race that was fixed later. It =
wasn't in=20
a UPnP =
component.<BR>><BR>> =20
=
Rich<BR>><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 possible, and I'm familiar with your technical level so =
I'll=20
give you the benefit of the doubt and believe you know the truth in =
this case=20
but it still makes no sense to me because I've seen the security =
bulletins=20
correct publicly posted vulnerability reports=20
=
before.<BR>><BR>> &n=
bsp;=20
I do have a question though, after the patch did you test to see if =
the issue=20
you were seeing was corrected? I mean I suppose any change in the code =
could=20
fix a race condition but I'm asking specifically if you tested the=20
=
fix?<BR>><BR>>  =
;=20
=
Geo.<BR>> &=
nbsp;=20
"Rich" <@> wrote in message <A=20
=
href=3D"news:42b79696@w3.nls.net">news:42b79696@w3.nls.net</A>...<BR>>=
&=
nbsp; =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=20
=
reporter.<BR>><BR>> =
=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=20
=
interesting.<BR>><BR>> &nb=
sp; =20
Rich<BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_024B_01C57710.2FAE95C0--
--- BBBS/NT v4.01 Flag-5
* Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)
|