bugtraq - RE: Local versus remote security holes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <C823AC1DB499D511BB7C00B0D0F0574CC40D14@serverdell2200.interclean.com>
Date: Wed, 22 Dec 2004 15:59:12 -0500
From: David Brodbeck <DavidB@...l.interclean.com>
To: 'Adam Shostack' <adam@...eport.org>,
	"D. J. Bernstein" <djb@...yp.to>
Cc: bugtraq@...urityfocus.com
Subject: RE: Local versus remote security holes

> -----Original Message-----
> From: Adam Shostack [mailto:adam@...eport.org]

> There is a rough standard for what local and remote mean.  The
> standard may not be as precise as you'd like.  Using old terms with
> new definitions doesn't advance the debate, it generates confusion.
> This is especially the case when you haven't rigorously defined the
> proposed new meanings of the terms.

I think all this conversation is doing is showing that the terms 'local' and
'remote' are vague and maybe not terribly useful anymore.

> I've long advocated 'credentialed' to refer to attacks where a user of
> the system can execute the attack, and 'anonymous' or
> 'non-credentialed' to refer to refer to attacks on servers, such as
> httpd, ftpd, or named.  These attacks can be launched by anyone, from
> anywhere (barring interference from firewalls or the like).

That'd be a good start.  In most cases what people really want to know when
they look at 'remote' or 'local' attacks is whether any random person on the
Internet can execute the attack, or whether they only have to worry about
their own users.  This is especially true at small sites where if a local
user acts up, the sysadmin can just go dope slap them. ;)  I take it under
your system, the NASM vulnerability would be considered "credentialed"?