Text 5266, 180 rader
Skriven 2005-06-21 20:13:30 av Geo (1:379/45)
Kommentar till text 5239 av Rich (1:379/45)
Ärende: Re: Vulnerabilities vs. exploits
========================================
From: "Geo" <georger@nls.net>
This is a multi-part message in MIME format.
------=_NextPart_000_0070_01C5769D.B1409570
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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_0070_01C5769D.B1409570
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.2800.1505" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Oh, so then it was two different =
issues, one just=20
exposed a second which if the second was fixed could have resolved the =
first=20
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 did fix=20
the problem reported. There were other scenarios that exposed =
the race=20
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 =
href=3D"mailto:georger@nls.net">georger@nls.net</A>>=20
wrote in message <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 with=20
your technical level so I'll give you the benefit of the doubt and =
believe=20
you know the truth in this case but it still makes no sense to me =
because=20
I've seen the security bulletins correct publicly posted =
vulnerability=20
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 patch=20
did you test to see if the issue you were seeing was corrected? I =
mean I=20
suppose any change in the code could fix a race condition but I'm =
asking=20
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 the=20
repro he provided and the one he describes in his PR demonstrates=20
none. Who knows, maybe he knows a way to exploit the bug =
that he is=20
keeping to himself to gain some advantage. I disagree about =
a=20
correction too. There is no proof that he was not =
keeping=20
something to himself for personal advantage. I very much =
doubt it=20
but then I have (or at least had at the time I looked at it) an =
very good=20
understanding of exactly what was going on and that understanding =
is 100%=20
consistent 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 with=20
one another. If you really paid attention to the =
vulnerablities that=20
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=20
would see that each of these can be very different. In this =
example=20
I think the reporter did not understand what he saw (i.e. the =
first two)=20
and asserted that he can exploit the corrupted state to trigger an =
overflow elsewhere unrelated to the original bug and quite likely =
not a=20
bug at all. It doesn't matter. This may seem weird to =
someone=20
that doesn't understand code in general or even the specific code =
but it's=20
not remarkable or in most cases even 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></BODY=
></HTML>
------=_NextPart_000_0070_01C5769D.B1409570--
--- BBBS/NT v4.01 Flag-5
* Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)
|