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@uic.edu>
