Stephen Harris writes: > In your example, a local user MUST take action in order to perform > the exploit, therefore the exploit is local. Practically all UNIX security holes are ``local'' according to your criterion. A peer-to-peer server, for example, or even a DNS server, isn't started without action by a local user. If you're trying to say that the rare programs that run by default are particularly important, because they're running on so many machines, then I'll agree. But this distinction is of no use in filtering a list of security holes! Suppose there's a security hole in a program that _isn't_ running by default. Does this mean that some readers can skip the hole? Of course not. Maybe it's a security hole in a browser, or in some other program that the reader uses. In contrast, there are many security holes that apply only to multiuser machines, and not to, e.g., a typical laptop. That's what my ``local'' label is for. Many users can skip these reports. As for NASM, most of the commentators here obviously haven't read the security report, which explained the (unusual) limitations of this particular security hole in considerable detail. Relevant excerpt: You are at risk if you receive an asm file from an email message (or a web page or any other source that could be controlled by an attacker) and feed that file through NASM. Whoever provides that asm file then has complete control over your account: he can read and modify your files, watch the programs you're running, etc. Of course, if you _run_ a program, you're authorizing the programmer to take control of your account; but the NASM documentation does not say that merely _assembling_ a program can have this effect. It's easy to imagine situations in which a program is run inside a jail but assembled outside the jail; this NASM bug means that the jail is ineffective. These limitations---although quite severe---don't confine the problem to multiuser machines, so labelling this security hole as ``local'' would be wrong. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago
