[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Universal vs. Environmental Policy, and the "vulnerability" term

I disagree with the assertion that the vulnerability lies with the wide
knowledge of telnet or anything else.  A vulnerability exists whether you
know it or not.  A secure algorithm is secure no matter how well you
understand it.  With regards to telnet using TCP,  I find that the omission
of "and in no other way" in your statement "That is, suppose that telnet
behaves precisely the way it is supposed to" is an admission that telnet
has vulnerabilities -- whether it has inherited them from TCP/IP is
irrelevant.

	Of course, you could say that running anything with vulnerabilities
creates a "vulnerability"  -- but I think this is abusing the term (see
below).

Dave Mann wrote:

>Pascal Meunier wrote:
>> Let me define macrovulnerabilities as
>> vulnerabilities that arise from the assembly of services, hardware and
>> software in a specific environment, while each of those individually does
>> what it is supposed to do and nothing else.
>[snip...]
>> Are services unsecure because they contain vulnerabilities, or because they
>> are ill-designed services for which no implementation can ever be secure?
>> In the first case, there should be a CVE entry for those vulnerabilities
>> but not the service.  If having the latter kind running allows someone to
>> circumvent other common policies, then the service is a macrovulnerability.
>> I think that services falling in this category deserve a CVE entry.  In
>> such a case I believe that there can be a one-to-one mapping between a
>> macrovulnerability and low-level policy.
>
>I think the case can be made that the pressence of certain
>services or applications represent what you are calling
>a macrovulnerability.

Yes, this is close to what I meant in a very narrow sense.  However, I
believe that the example you gave is outside the scope of what I meant (see
below...).

Allow me to present an example
>suggested by a collegue.
>
>Suppose we have a system that is running telnet (or
>finger or some other well-known service) and further
>suppose that the version of telnet does not have any
>vulnerabilities under the strict understanding of the
>word.  That is, suppose that telnet behaves precisely
>the way it is supposed to.   In this case, telnet still
>presents a vulnerability -- Since it is so well understood
>and since TCP itself has inherent weaknesses, telnet is
>subject to attacks such as hijacking.
>
>Note, the vulnerability here resides in large measure
>with the fact that telnet is so well known.  Consider,
>in contrast, a custom built data exchange protocol to
>support a database application.  Provided that the
>specifications for this custom built protocol are not
>known,

I don't believe in security through obscurity...


there is very little chance that a hacker could
>hijack the session.

Obscurity and information control do reduce risks, but they are not secure
(see below).

>
>Again, we see that the vulnerability of the service running
>on TCP/IP resides in the knowledge of how the service
>works.  I think we can agree that decisions about vulnerabilities
>should be based on facts about the systems involved.  Despite
>the fact that this may move us into an uncomfortable "best
>practices" definition of vulnerability, I note that the
>consideration of the relative knowledge of a service and it's
>relative popularity with hackers are still facts about
>the service.  This is what leads me to consider telnet
>to be a (potential) vulnerability (relative to policy).

What you mean is that you consider telnet risky -- that's like a policy
recommendation, not the definition of a vulnerability.  In my mind
something is either vulnerable to something or isn't, whereas risk is all
shades.  I think that risk evaluation and the policy recommendations that
follow from it are too high level and variable for the CVE...

Pascal


Microsoft Windows is also a way of thinking - or not thinking, to be more
exact.
-- RA Downes  Radsoft Laboratories
Page Last Updated or Reviewed: May 22, 2007