Text 5290, 251 rader
Skriven 2005-06-22 09:44:42 av Rich (1:379/45)
Kommentar till text 5278 av Geo (1:379/45)
Ärende: Re: Vulnerabilities vs. exploits
========================================
From: "Rich" <@>
This is a multi-part message in MIME format.
------=_NextPart_000_0237_01C5770F.03FCEF90
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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_0237_01C5770F.03FCEF90
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> There was no overrun to=20
fix.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Rich</FONT></DIV>
<DIV> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Geo" <<A =
href=3D"mailto:georger@nls.net">georger@nls.net</A>> wrote=20
in message <A=20
=
href=3D"news:42b9383a@w3.nls.net">news:42b9383a@w3.nls.net</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Translation, the issue of buffer =
overrun in the=20
MS bulletin was a separate patch from the patch for the race condition =
you=20
mentioned however the patch for the race condition also would have =
fixed the=20
buffer overrun issue?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Geo.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Rich" <@> wrote in message <A=20
=
href=3D"news:42b8c753$1@w3.nls.net">news:42b8c753$1@w3.nls.net</A>...</DI=
V>
<DIV><FONT face=3DArial size=3D2> I'm not sure what your =
first and=20
second represent so I couldn't answer even if I could parse it =
out. =20
How about, maybe.</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 dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Geo" <<A =
href=3D"mailto:georger@nls.net">georger@nls.net</A>>=20
wrote in message <A=20
=
href=3D"news:42b8ad5b@w3.nls.net">news:42b8ad5b@w3.nls.net</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Oh, so then it was two different =
issues, one=20
just exposed a second which if the second was fixed could have =
resolved=20
the first issue as well?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Geo.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Rich" <@> wrote in message <A=20
=
href=3D"news:42b83849@w3.nls.net">news:42b83849@w3.nls.net</A>...</DIV>
<DIV><FONT face=3DArial size=3D2> Yes, the fix in =
the bulletin=20
did fix the problem reported. There were other scenarios =
that=20
exposed the race that was fixed later. It wasn't in a UPnP =
component.</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 dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: =
5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Geo" <<A=20
href=3D"mailto:georger@nls.net">georger@nls.net</A>> wrote =
in message=20
<A=20
=
href=3D"news:42b7e6d9$1@w3.nls.net">news:42b7e6d9$1@w3.nls.net</A>...</DI=
V>
<DIV><FONT face=3DArial size=3D2>I suppose it's possible, and =
I'm familiar=20
with your technical level so I'll give you the benefit of the =
doubt=20
and believe you know the truth in this case but it still makes =
no=20
sense to me because I've seen the security bulletins correct =
publicly=20
posted vulnerability reports before.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I do have a question though, =
after the=20
patch did you test to see if the issue you were seeing was =
corrected?=20
I mean I suppose any change in the code could fix a race =
condition but=20
I'm asking specifically if you tested the fix?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Geo.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: =
5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Rich" <@> wrote in message <A=20
=
href=3D"news:42b79696@w3.nls.net">news:42b79696@w3.nls.net</A>...</DIV>
<DIV><FONT face=3DArial size=3D2> I disagree and =
this is an=20
example. The reporter claimed there were overflows =
even though=20
the repro he provided and the one he describes in his PR=20
demonstrates none. Who knows, maybe he knows a way to =
exploit=20
the bug that he is keeping to himself to gain some =
advantage. =20
I disagree about a correction too. There is no =
proof that=20
he was not keeping something to himself for personal=20
advantage. I very much doubt it but then I have (or at =
least=20
had at the time I looked at it) an very good understanding =
of=20
exactly what was going on and that understanding is 100% =
consistent=20
with the facts from the reporter.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2> Really, this =
is nothing=20
remarkable. The cause of a bug and the behavior that =
can be=20
triggered by exploitation of a bug need have little to =
nothing to do=20
with one another. If you really paid attention to the=20
vulnerablities that are reported on the lists as you =
suggest, the=20
symptoms of those vulnerabilities, and the exploits that can =
sometimes be made of them you would see that each of these =
can be=20
very different. In this example I think the reporter =
did not=20
understand what he saw (i.e. the first two) and asserted =
that he can=20
exploit the corrupted state to trigger an overflow elsewhere =
unrelated to the original bug and quite likely not a bug at=20
all. It doesn't matter. This may seem weird to =
someone=20
that doesn't understand code in general or even the specific =
code=20
but it's not remarkable or in most cases even=20
interesting.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Rich</FONT></DIV>
<DIV><FONT face=3DArial=20
=
size=3D2></FONT> </DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOC=
KQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0237_01C5770F.03FCEF90--
--- BBBS/NT v4.01 Flag-5
* Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)
|