Text 5278, 226 rader
Skriven 2005-06-22 06:08:50 av Geo (1:379/45)
Kommentar till text 5270 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_00AA_01C576F0.DC4894E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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_00AA_01C576F0.DC4894E0
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>Translation, the issue of buffer =
overrun in the MS=20
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. How=20
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 the=20
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 did=20
fix the problem reported. There were other scenarios that =
exposed=20
the race that was fixed later. It wasn't in a UPnP=20
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=20
with your technical level so I'll give you the benefit of the =
doubt and=20
believe you know the truth in this case but it still makes no =
sense to=20
me because I've seen the security bulletins correct publicly =
posted=20
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? I=20
mean I suppose any change in the code could fix a race condition =
but I'm=20
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 =
demonstrates=20
none. Who knows, maybe he knows a way to exploit the bug =
that he=20
is 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=20
it but then I have (or at least had at the time I looked at =
it) an=20
very good understanding of exactly what was going on and that=20
understanding is 100% consistent with the facts from the=20
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=20
be made of them you would see that each of these can be very=20
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=20
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=20
understand code in general or even the specific code but it's =
not=20
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></BLOC=
KQUOTE></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_00AA_01C576F0.DC4894E0--
--- BBBS/NT v4.01 Flag-5
* Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)
|