update

Sun Sep 28 15:08:37 UTC 2014

On Sunday, 28 September, 2014 06:39, Jimmy Hess <mysidia at gmail.com> said:
>On Sat, Sep 27, 2014 at 11:57 PM, Keith Medcalf <kmedcalf at dessus.com>
>wrote:> This is another case where a change was made.

>> If the change had not been made (implement the new kernel) then the
>vulnerability would not have been introduced.

>> The more examples people think they find, the more it proves my
>proposition.  Vulnerabilities can only be introduced or removed through
>change.  If there is no change, then the vulnerability profile is fixed.

>I see what you did there... you expanded the boundaries of the
>"system" to include not just the application code but more and more of
>the environment, CPU, Kernel, ....

No, those are part of the system and have a direct effect on the "application code".  Whether the network connection is two tin cans and a string, twisted pair or fiber is irrelevant.  Whether you are located on the third floor or the fourth floor is (likely) irrelevant.  However, changing the network connection from two tin cans and a string to fiber is relevant if it affects the system.  Such an effect would be a change of the network interface hardware and the requisite change in drivers.  If the existing hardware and software can already handle both fiber and tin cans and string, then the change cannot affect the system since you are not changing anything upon which operation of the system is dependent.

>The problem is, before it is an entirely correct statement to assert
>that a zero entropy system never develops new vulnerabilities, you
>have to expand the boundaries of the "system"  to include the entire
>planet.

Incorrect.  The whole planet does not directly affect the system.  Well, that is not entirely true.  There could be an earthquake that knocks the building down.  Presumably you have mitigations in place for that -- usually a continuity and recovery plan.  The planet could also be struck by a meteor causing an extinction level event to occur.  There would probably be no need to mitigate that.

>Suppose you have a vulnerability that can only be exposed if port 1234
>is open.   That's no problem,  you blocked port 1234 on the external
>firewall, therefore the application cannot be considered to be
>vulnerable during testing.

The first action would be to disable the vulnerable service using port 1234, assuming that it is unnecessary.  If it is necessary for some use or cannot be disabled, then you either mitigate the vulnerability by filtering in an external firewall, or decide to accept the risk of operating with a (possible) known vulnerability.  These actions do not remove the vulnerability -- they mitigate exploit of the vulnerability.  The vulnerability is still there.

>A few years later you replace the firewall with a NAT router that
>doesn't block port 1234.

>Oops!  Now you have to consider the entire network and the Firewall to
>be part of the application  / internal part of the system.

No, they are part of the mitigation for the vulnerability in the first system.  You have not changed the first system, you have decided to no longer mitigate its vulnerability.  Presumably you did this based on a rational assessment of the risks and benefits of doing so because you evaluated the effect of the change to the firewall, noted that port 1234 would no longer be filtered, and as a result the mitigation for the vulnerability in the first system would no longer be in place and that exploit of that vulnerability was now possible.

>And it doesn't end there.   Eventually for the statement to remain
>true, the boundaries of the system which 'cannot develop a
>vulnerability unless it changes' have to expand  in order to include
>the attackers' brains.

But you did not change the fact that port 1234 in the first system contains a vulnerability.  It was vulnerable from the get-go so you implemented a mitigation.  You did not make the vulnerability "go away" you merely reduced the risk of exploit to an acceptable level.  When you changed the firewall system you did not introduce a vulnerability in the first system.  You merely decided to change the risk of exploit of a pre-existing condition.

>"If the attacker discovers a new trick or kind of attack they did not
>know before"   then a change to the system has occurred.

No.  Either you have already addressed the possibility of the vulnerability existing and how it might be exploited, or you have not.  If you did not consider the possibility that of the vulnerability, then upon learning of its existence you either need to implement a change to fix it, or implement a mitigation of some type.  Conversely, if adequate mitigation is already in place or the vulnerability is moot (for example, the vulnerable service is externally filtered or is disabled), then an increase in the knowledge of the attacker is irrelevant.