[174721] in North American Network Operators' Group
RE: update
daemon@ATHENA.MIT.EDU (Keith Medcalf)
Sun Sep 28 00:24:31 2014
X-Original-To: nanog@nanog.org
Date: Sat, 27 Sep 2014 22:07:07 -0600
In-Reply-To: <14859081.3320.1411866628033.JavaMail.root@benjamin.baylink.com>
From: "Keith Medcalf" <kmedcalf@dessus.com>
To: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
>> Unfortunately, that page contains near the top the ludicrous and
>> impossible assertion:
>> ""Familiarity Breeds Contempt: The Honeymoon Effect and the Role of
>> Legacy Code in Zero-Day Vulnerabilities", by Clark, Fry, Blaze and
>> Smith makes clear that ignoring these devices is foolhardy;
>> unmaintained systems become more vulnerable, with time."
>> It is impossible for unchanged/unmaintained systems to develop more
>> vulnerabilities with time. Perhaps what these folks mean is that
>> "vulnerabilities which existed from the time the system was first
>> developed become more well known over time".
>That's not actually true. A running process, instantiated from a file
>of object code, derives its behavior from a number of interfaces; to the
>kernel, the libc, the filesystem of the machine it's run on, and even
>network interfaces off the machine.
>While the device itself may be -- or seem to be -- immutable, unless
>you're
>certain that *nothing around it changed either*, then you cannot assume
>that things became vulnerabilities *as deployed* which were not so
>previously.
>Ok, yes, that's partially equivalent to what you said, at least in the
>case of, say, consumer routers, booting from flash. But for code running
>on real OSs, it's possible for a vulnerability to "appear" because
>something
>under or beside the code got updated, turning something which could not
>be attacked into something which could.
>I haven't an example case, but it is theoretically possible.
No, it is not. If you have "changed something" then the system is not unch=
anged. For example, if you have updated libc, applied a patch to something=
, changed the network adapter and therefore the drivers, you have changed t=
he "vulnerability profile" of the box (or, more correctly everything in the=
path of direct connection to the change). This is why there is change con=
trol. So that when you "make a change" you can assess the impact of the ch=
ange on *everything* it affects. A running process on a commodity OS on a =
given box will not spontaneously have vulnerabilities created or destroyed =
save and except by a change made within the "sphere of influence" (meaning,=
in that case, anything inside "the box").
By very definition an "unmaintained" system is not subjected to change, and=
therefore the vulnerability profile cannot change.
For example, if I build a Linux machine running Slackware 1.0 (I had one of=
those running for many years) that is performing a specific task, and that=
"box" is not maintained (that is, no changes are made to any part of the s=
oftware or hardware comprising the box), then the vulnerability profile doe=
s not change despite the passage of 15 years of time. It cannot spontaneou=
sly have a new vulnerability created five years after commissioning that di=
d not exist at the time it was commissioned, nor can one that existed at co=
mmissioning go away. By the same token, external change -- for example inc=
reasing the network transit of the network to which "the box" is connected =
from an ISDN connection to a DS3 -- does not change the "vulnerability prof=
ile" of the box itself; and, cannot cause a new vulnerability to be created=
or destroyed within that box. Such an "external change" may affect the l=
ikelihood of exploitation of a pre-existing vulnerability, but cannot creat=
e a new vulnerability nor cause one that exists to go away.
This is why XP (for example) becomes *more* secure when Microsoft support e=
nds, not *less*. It is no longer subject to change and therefore its vulne=
rability profile has become fixed, rather than a perpetually moving target.=
From the time the box becomes "no longer subject to change" it will have =
its vulnerability profile fixed at that point right up until it is decommis=
sioned (or decommissions itself by, for example, having the magic smoke esc=
ape).
This then leads to the assessment of the value of "vendor support". "Vendo=
r Support" that is predicated on a perpetual requirement to make change for=
change sake (such as Microsoft updates) is a negative value proposition an=
d is unmaintainable. It is impossible to perform the required re-assessmen=
ts at the fantastic rate of change imposed by such systems. On the other h=
and, "Vendor Support" which does not require perpetual change, has a value =
and that value is the difference between the future value of the series of =
recurring "support" fee's and the cost of "replacement" of the affected com=
ponent when a "change" has been assessed to be necessary, either to remove =
a pre-existing vulnerability (which may no longer be able to be mitigated, =
or may be excessively expensive to mitigate) or for new features (or hardwa=
re warranty services, for example, in the specific case of SmartNet contrac=
ts). The decision to implement the change (and thus an evaluable shift in =
the vulnerability profile, which becomes fixed at the time the change is ma=
de and continues unchanged, right up until the next change occurs) is subje=
ct to rational management of change processes and rational analysis.
For systems predicated on massive continual change the impact of which cann=
ot be assessed (such as most "Microsoft" products, or Adobe Flash, or, <the=
re are several others>) leads to a complacent dependence on the vendor due =
to a complete inability to rationally assess the vulnerabilities contained =
in such systems or anything "within the sphere of direct influence" of them=
. This then has the effect of imposing "dependence" and "lock in" to the v=
endor. Commodity computing hardware vendors (Dell is an example) do the sa=
me thing as well, deliberately imposing uncontrollable change with delibera=
te requirements for implementation of non-consequent change (ie, deliberate=
ly removing compatibility in order to force upgrades to new versions of Mic=
rosoft Windows), in order to "lock" their customers into their products and=
institute dependent behaviour. Interestingly the behaviour of vendors and=
the customers of vendors with such practices is remarkably similar to the =
behavioural traits displayed by crack addicts and their dealers.
