> Two points.
>
> Regarding local versus remote, look at it this way: You have a 100%
> secure system. Then you install NASM. Now a user FROM THE NETWORK can
> send you some tainted assembly code for you to assemble and he can
> compromise your account. That is why it is considered remote. Local
> would mean that I, the attacker, need an account on the target machine to
> compromise the target account. In this nasm case, I do not need an
> account. That is why the wording "remote" was chosen.
You still need a local account: the one used by the user coaxed into
assembling the code. The fact that the source of the code in your example
was from a network user does not make it a remote exploit; one could just as
easily write the code on a bubble gum wrapper and have the user type it in,
then assemble it. Your example simply bypasses this logic by providing
circumstances where the attacker need not possess the local account
credentials, though a local account is most certainly needed to exploit the
vulnerability.
> Now in regards to full disclosure, I think you should all be happy that we
> bothered to tell you all about these exploits. We could have selfishly
> used them to compromise machines, but instead we wrote them up and mailed
> them off to the users and the authors! That is very nice of us.
>
> If you would like notification sooner than the "public", find the exploit
> yourself. If I can find them, then surely anyone can.
I doubt seriously that many will read this statement and interpret it
magnanimously. The "you're lucky we didn't use it for criminal purposes"
position doesn't exactly leave one all warm and fuzzy. To me, there are
many other aspects of the "full-disclosure" debate that should be considered
within the context of how the community is affected before the "well, I
could have done this as an individual" statements are made.
T
> Regards,
> --
> Jonathan Rockway <jrockw2 (at) uic (dot) edu [email concealed]>
>
>
>
> Regarding local versus remote, look at it this way: You have a 100%
> secure system. Then you install NASM. Now a user FROM THE NETWORK can
> send you some tainted assembly code for you to assemble and he can
> compromise your account. That is why it is considered remote. Local
> would mean that I, the attacker, need an account on the target machine to
> compromise the target account. In this nasm case, I do not need an
> account. That is why the wording "remote" was chosen.
You still need a local account: the one used by the user coaxed into
assembling the code. The fact that the source of the code in your example
was from a network user does not make it a remote exploit; one could just as
easily write the code on a bubble gum wrapper and have the user type it in,
then assemble it. Your example simply bypasses this logic by providing
circumstances where the attacker need not possess the local account
credentials, though a local account is most certainly needed to exploit the
vulnerability.
> Now in regards to full disclosure, I think you should all be happy that we
> bothered to tell you all about these exploits. We could have selfishly
> used them to compromise machines, but instead we wrote them up and mailed
> them off to the users and the authors! That is very nice of us.
>
> If you would like notification sooner than the "public", find the exploit
> yourself. If I can find them, then surely anyone can.
I doubt seriously that many will read this statement and interpret it
magnanimously. The "you're lucky we didn't use it for criminal purposes"
position doesn't exactly leave one all warm and fuzzy. To me, there are
many other aspects of the "full-disclosure" debate that should be considered
within the context of how the community is affected before the "well, I
could have done this as an individual" statements are made.
T
> Regards,
> --
> Jonathan Rockway <jrockw2 (at) uic (dot) edu [email concealed]>
>
>
[ reply ]