IETF Logo Mail Archive

Re: [secdir] Secdir review of draft-ietf-opsawg-vmm-mib-02

Michael MacFaden <mrm@vmware.com> Mon, 25 May 2015 15:07 UTC

Return-Path: <mrm@vmware.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B7A1A905B; Mon, 25 May 2015 08:07:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.012
X-Spam-Level:
X-Spam-Status: No, score=-5.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rUgfpAXaLOS; Mon, 25 May 2015 08:07:08 -0700 (PDT)
Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB4771A9061; Mon, 25 May 2015 08:07:07 -0700 (PDT)
Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id DD08728175; Mon, 25 May 2015 08:07:06 -0700 (PDT)
Received: from EX13-CAS-009.vmware.com (EX13-CAS-009.vmware.com [10.113.191.61]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id D7D2418245; Mon, 25 May 2015 08:07:06 -0700 (PDT)
Received: from EX13-MBX-020.vmware.com (10.113.191.40) by EX13-MBX-010.vmware.com (10.113.191.30) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 25 May 2015 08:07:06 -0700
Received: from EX13-MBX-020.vmware.com ([fe80::8489:873c:5a56:44a7]) by EX13-MBX-020.vmware.com ([fe80::8489:873c:5a56:44a7%15]) with mapi id 15.00.0913.011; Mon, 25 May 2015 08:06:48 -0700
From: Michael MacFaden <mrm@vmware.com>
To: Christian Huitema <huitema@huitema.net>, 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de>
Thread-Topic: Secdir review of draft-ietf-opsawg-vmm-mib-02
Thread-Index: AdCN7doYjrDBgdzuTDO0+ECXL1vNSAHbGwKAAFjFUAAAD7fNgQ==
Date: Mon, 25 May 2015 15:06:48 +0000
Message-ID: <bd898b6525cb4401aa8921c120eca6ad@EX13-MBX-020.vmware.com>
References: <00bb01d08df0$8d92f3f0$a8b8dbd0$@huitema.net> <20150523061335.GA58453@elstar.local>, <019f01d09682$b04a7950$10df6bf0$@huitema.net>
In-Reply-To: <019f01d09682$b04a7950$10df6bf0$@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.113.160.246]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/cy9lAIkF87WBP6tV39aJ3JzOZGg>
X-Mailman-Approved-At: Mon, 25 May 2015 08:09:44 -0700
Cc: "draft-ietf-opsawg-vmm-mib.all@tools.ietf.org" <draft-ietf-opsawg-vmm-mib.all@tools.ietf.org>, 'The IESG' <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-opsawg-vmm-mib-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 May 2015 15:07:13 -0000

Christian writes:
>I would also mention the specific problem of software running in a virtual
>machine and accessing the hypervisor's variable

Yes we could describe this configuration and point out SNMPv3 would be required
to mitigate it. And in regards to this issue:

>There is an aggravating factor not mentioned in the security section. In
>many large data centers, some virtual machines will not be under the direct
>control of the data center manager. They may have been rented to third
>parties, or they may have been subverted. These potentially hostile virtual
>machines will have direct network connectivity with the hypervisor, and
>potentially with other hypervisors in the same subnet. Attackers in control
>of these machines can gain advantage of even read-only access to hypervisor
>state variables. One wonders whether even GET access should be allowed in
>the absence of authentication through SNMPv3. Attempting to support even GET
>operations with prior versions of SNMP appears risky.

I note it is not just SNMP service that could be vulnerable in such a network configuration.
But direct network connectivity is not typical for commercial systems however.
What normally done in industry at least with VMware products, is to isolate these
VMs networking into separate layer 2 networks. The snmp service is in a separate management
network using either different virtual switches at layer 2 or separate IP stack. 

Mike

v2.23.0 | Report a Bug | By Email