I'm not so sure about this. In the nasm case, a local use must run nasm
therefore requireing a local account. In my opinion, remote exploits are
holes that I can attack from the network without waiting for a local user
to execute something, i.e. services that are running or exposed protocols.

As for the other comments in this thread about telling the vendor early, I
personally feel it helps users if the vendor has a few days to look at the
hole and devise a patch BEFORE everyone on the planet knows about it. You
punish users of software in addition to vendors. All software has a
security problem of one kind or another, and its silly to think that a
perfect application will every be written.

On Mon, 20 Dec 2004, Jonathan T Rockway wrote:

> 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.
>
> 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.
>
> Regards,
> --
> Jonathan Rockway <jrockw2 (at) uic (dot) edu [email concealed]>
>

[ reply ]