[174729] in North American Network Operators' Group
RE: update
daemon@ATHENA.MIT.EDU (Keith Medcalf)
Sun Sep 28 11:08:54 2014
X-Original-To: nanog@nanog.org
Date: Sun, 28 Sep 2014 09:08:37 -0600
In-Reply-To: <CAAAwwbUUyP_fk4+Rzg0dakCg+UJUpkMhOJdYJ-zJs6Fizk27QA@mail.gmail.com>
From: "Keith Medcalf" <kmedcalf@dessus.com>
To: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On Sunday, 28 September, 2014 06:39, Jimmy Hess <mysidia@gmail.com> said:
>On Sat, Sep 27, 2014 at 11:57 PM, Keith Medcalf <kmedcalf@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 "applicati=
on code". Whether the network connection is two tin cans and a string, twi=
sted pair or fiber is irrelevant. Whether you are located on the third flo=
or or the fourth floor is (likely) irrelevant. However, changing the netwo=
rk connection from two tin cans and a string to fiber is relevant if it aff=
ects the system. Such an effect would be a change of the network interface=
hardware and the requisite change in drivers. If the existing hardware an=
d 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 wh=
ich 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, th=
at is not entirely true. There could be an earthquake that knocks the buil=
ding 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 nee=
d 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 cann=
ot be disabled, then you either mitigate the vulnerability by filtering in =
an external firewall, or decide to accept the risk of operating with a (pos=
sible) 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 syst=
em. You have not changed the first system, you have decided to no longer m=
itigate its vulnerability. Presumably you did this based on a rational ass=
essment of the risks and benefits of doing so because you evaluated the eff=
ect 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 m=
itigation. 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 mer=
ely 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 c=
onsider the possibility that of the vulnerability, then upon learning of it=
s 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.
