[174723] in North American Network Operators' Group
RE: update
daemon@ATHENA.MIT.EDU (Keith Medcalf)
Sun Sep 28 00:50:47 2014
X-Original-To: nanog@nanog.org
Date: Sat, 27 Sep 2014 22:50:31 -0600
In-Reply-To: <CAAAwwbVc0qJTU0oWEJWjsrU3ELi5_W53G=xwC7M_6CJHHUgaeA@mail.gmail.com>
From: "Keith Medcalf" <kmedcalf@dessus.com>
To: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On Saturday, 27 September, 2014 20:49, Jimmy Hess said:
>On Sat, Sep 27, 2014 at 8:10 PM, Jay Ashworth <jra@baylink.com> wrote:
>> I haven't an example case, but it is theoretically possible.
>Qmail-smtpd has a buffer overflow vulnerability related to integer
>overflow which can only be reached when compiled on a 64-bit platform.
>x86_64 did not exist when the code was originally written.
>If memory serves, the author never acknowledged the vulnerability and
>declined to pay bounty or fix the bug stating that nobody allows
>gigabytes of RAM per smtp process.
>However.... you see, there you have a lingering bug that can be
>exposed under the right environment.... (Year 2030... computers
>have Petabytes of RAM... why would you seriously limit any one
>process to less than a terabyte....?)
>-> http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html
** the person making the change in this instance is referred to as "you". =
This is not to imply that it is any of you personally, but simply because i=
t is easier to write using that pronoun rather than figuring out an appropr=
iate third-person descriptive. I personally think "the retard" is most app=
ropriate, but then that is just me :)
In this case however, you have implemented a change and it has changed the =
vulnerability profile. Presumably at one point you were running Qmail-smtp=
d on x86 (32-bit). You introduced a change (x86 -> x64) which changed the =
vulnerability profile. Perhaps you implemented two changes -- one to an x6=
4 kernel, and second to an x64 userland. Whatever the case, there was stil=
l a change, and it was only because of the change that the vulnerability ma=
nifested.
If you had not made the change, you would not have introduced the vulnerabi=
lity.
That your assessment of the change in vulnerability profile resulting from =
your change was defective is the whole point of this discussion.
If you had been rational about the change to from x86 -> x64 and 32-bit use=
rland to 64-bit userland, you would have limited all processes to the same =
per-process address space as they had in the x86 model in order to prevent =
the introduction of vulnerabilities such as this, and only permitted larger=
address spaces for processes that required them (ie, were part of the just=
ification for making the change). If the change was "thrust upon you" with=
no justification, then the "thruster" should be terminated (with extreme p=
rejudice, if possible). Notwithstanding, if you are responsible for the Sa=
fety and Security of the system changed, you should go stand in the corner =
for failing to perform your job adequately, or perhaps be promoted to manag=
ement where you will no longer be a threat.
And the assumption about "(Year 2030... computers have Petabytes of RAM...=
why would you seriously limit any one process to less than a terabyte....=
?)" implies that there is an intent to implement further change.
Before you make the change to "computers having petabytes of RAM" and "not =
limiting any process to less than a terabyte of per process address space",=
I would hope that you would assess the impact of that change. Especially =
since you now have additional information on which to generate a more accur=
ate assessment of the impact of making that change, and what mitigations yo=
u should put in place when you make that change to prevent yourself from be=
ing either terminated with extreme prejudice or promotion to management (un=
less, of course, those are your goals).
One of the reasons for "limiting a process to less than a terabyte of proce=
ss address space" is that it may lead to the manifestation of vulnerabiliti=
es such as the one discussed here.
My original proposition still holds perfectly:
(1) The vulnerability profile of a system is fixed at system commissioning.
(2) Vulnerabilities do not get created nor destroyed except through impleme=
ntation of change.
(3) If there is no change to a system, then there can be no change in its v=
ulnerabilities.
Of course, you must set the boundaries of "system" correctly. Choosing the=
wrong boundary may cause you to mislead yourself as to what a particular c=
hange may impact.
