IETF Logo Mail Archive

Re: Scripting attacks [was Next step for draft-ietf-6man-rfc6874bis]

Simon <linux@thehobsons.co.uk> Fri, 01 July 2022 13:36 UTC

Return-Path: <linux@thehobsons.co.uk>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652C0C15A74C for <ipv6@ietfa.amsl.com>; Fri, 1 Jul 2022 06:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZioTrzfZXi15 for <ipv6@ietfa.amsl.com>; Fri, 1 Jul 2022 06:36:54 -0700 (PDT)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47E6FC159486 for <ipv6@ietf.org>; Fri, 1 Jul 2022 06:36:52 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from smtpclient.apple (Simons-Mac.thehobsons.co.uk [192.168.137.120]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id A491E1A021 for <ipv6@ietf.org>; Fri, 1 Jul 2022 13:36:46 +0000 (UTC)
From: Simon <linux@thehobsons.co.uk>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: Scripting attacks [was Next step for draft-ietf-6man-rfc6874bis]
Date: Fri, 01 Jul 2022 14:36:46 +0100
References: <164938402532.17740.11717866110301931501@ietfa.amsl.com> <b1780128-2069-b32e-7ca5-86977c119f0c@gmail.com> <11d4e419-11a9-8768-abf2-1335e5f1c3d8@gmail.com> <149924f9-da30-fa79-0509-c01c439d1796@gmail.com> <5BEFA97B-CF09-44D7-8C10-017FEAE4C3A8@tiesel.net> <e6ff75e7-b6c6-ea03-2e10-b1ad95d650f0@gmail.com> <98D15BD9-A631-4D09-AE9E-9D4C750714C9@tiesel.net> <95c82ad3-2138-ab2a-7ba5-57ad80472964@gmail.com> <E5C368C5-9DAE-4C61-ADDE-B881EA11EDA0@tiesel.net> <6968ca7b-dac3-b192-41ed-a193adab7eb4@gmail.com> <529B863C-BCC9-40C1-A5B8-B0598E7DF17C@tzi.org> <bf8c5c54-d548-a40a-0381-0583ef946f26@gmail.com> <CAPt1N1=4wbqrrzvwdr4FD7awa6pkyffhwRZC3zAWLs7uzY3BJQ@mail.gmail.com> <86509E47-77CE-4210-A1B7-C1E9955D9672@tzi.org> <CAPt1N1kYBMSA5Y7BZLMd9o96tBxFY7SrRUxb9jxfBNvBiA_OJQ@mail.gmail.com> <d3d9d68a-adff-b29b-4d1b-78f82e6bf282@gmail.com> <A2DD6902-EF02-4EA4-80D3-18820B912DF1@tzi.org> <fac9959a-5675-fb7f-7f00-3542e260d6a9@gmail.com>
To: 6man <ipv6@ietf.org>
In-Reply-To: <fac9959a-5675-fb7f-7f00-3542e260d6a9@gmail.com>
Message-Id: <A1CFB9CF-28F3-4292-AF4E-B1167E40E14B@thehobsons.co.uk>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/x4PgF2P9FHDQt4oFDnofMWquCtw>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2022 13:36:58 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 30-Jun-22 16:45, Carsten Bormann wrote:
>> On 30. Jun 2022, at 06:40, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>> 
>>> For the present draft, one thing my small experiment shows is that we won't make things worse by adding zone identifiers to URLs. They too have to be guessed by the attacker, and in modern Linux they are things like "enxb813ebc170a4" out of the box. That makes the attacker's job significantly harder.
>> Do you know how enxb813ebc170a4 is generated?  (I.e., is the 48-bit thing in there guessable?)
> 
> No, I don't and it seems to be a complicated issue and very dependent on the exact Linux version:
> https://wiki.debian.org/NetworkInterfaceNames
> 
> It doesn't seem to be a function of the relevant MAC address. Maybe someone with Linux kernel expertise can answer.

On that page there’s a link to https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html

It seems that it is indeed the MAC address of the interface.

> ID_NET_NAME_MAC=prefixxAABBCCDDEEFF
> This name consists of the prefix, letter x, and 12 hexadecimal digits of the MAC address. It is available if the device has a fixed MAC address. Because this name is based on an attribute of the card itself, it remains "stable" when the device is moved (even between machines), but will change when the hardware is replaced.



This whole “make the interface names as complicated, unintuitive, and error prone to type as possible” malarky is just one of many reason I have nothing to do with systemd. Though I also generally give my interfaces custom names anyway (e.g. ethext, ethint, etc.) so that firewall rules and so on are easier to follow.

Simon

v2.23.0 | Report a Bug | By Email