Re: [irsg] Meetecho for interims?

Leif Johansson <leifj@sunet.se> Sat, 01 August 2020 14:48 UTC

Return-Path: <leifj@sunet.se>
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A57D3A0B33 for <wgchairs@ietfa.amsl.com>; Sat, 1 Aug 2020 07:48:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet.se
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 EqMHbOeUGD5P for <wgchairs@ietfa.amsl.com>; Sat, 1 Aug 2020 07:48:31 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A36FA3A0B3C for <wgchairs@ietf.org>; Sat, 1 Aug 2020 07:48:29 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id x9so35313732ljc.5 for <wgchairs@ietf.org>; Sat, 01 Aug 2020 07:48:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet.se; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=EsHw2mz9pcQQvLR/QXYBKA1yl3kF51QT4tXJYqlqxd4=; b=VxVVPF4M8z5FRznGnSIeul1pm6lgOnVkwI94DT0w9kIk/N0SJ9UkVkALFOzza/mTF8 3NVIkrqvpHyl06uQHnwrJVFGlRyuVqGOi5B6IWlPQToYXIpJCdESySsL1NQ0HTp6qvjY YX1c+1UaE2uH0qtKIxOGbGVrzmcBnBMGOd1PKqMx7B4mMmj/e2MHlMl03K2rmWyax84g 1zjyJmZVfVhcbsRHLGuU71hm0zoCiKbx9lw8T11MXyXTpezQhYFF3pQPk4dyxtKZJG8d hKKwamwXhNtjZe+6lzM95l4iSqRxBDg5OPRM//UjHaICA+LoXJratycXEBjUlZZfOfp9 mGeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=EsHw2mz9pcQQvLR/QXYBKA1yl3kF51QT4tXJYqlqxd4=; b=qCfqjrgOfGmjBu2ZFxc+l8YSXkl0F+nIaSUbvlngnUXHbtXRN7yKQhtcXa4K3pWFxU T1YPDOzcK7C22LGtNAk9Xtn3Ebk5qGkoc+CXszfUYnRiAvLm+LArT356XN/TReA0/j1D 9SlYL3ZbIcSgyN6e+zNtPJ5KE+/+sPy9wlke5Lpyli94Jk3ejmkubryvu9bXyn80q08k 9n9M4Ova8ia1JgGScoo5928K+gfou42Ib5yvAYRZGXzSdif0fao1egb+0M68nQzacr26 62YOZJDhe6KEVtc0ZM6BHuVHVxLpHDSpTCwFNfSePR3BRHwo1+TwJ1APXGTsh+7TlbI0 R6vg==
X-Gm-Message-State: AOAM5301zOzf9KSDVHbOaONZOOCd6hpaY4DxSmuDfMQTtaFjZVNSxjg7 fljj+Kbs4d0+fukYV6JZJj0oA76m++HdYg==
X-Google-Smtp-Source: ABdhPJwFflIXZQ4k+SsuW+DOwN1D4r7UrpDnMmnnsw1nmRKef1fN74Kx8rNGIDw9TcOXNMgqeWYZtw==
X-Received: by 2002:a2e:908a:: with SMTP id l10mr3867702ljg.409.1596293307049; Sat, 01 Aug 2020 07:48:27 -0700 (PDT)
Received: from [10.0.0.193] (h-98-128-228-179.NA.cust.bahnhof.se. [98.128.228.179]) by smtp.gmail.com with ESMTPSA id j144sm3279958lfj.54.2020.08.01.07.48.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 01 Aug 2020 07:48:26 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Leif Johansson <leifj@sunet.se>
Mime-Version: 1.0 (1.0)
Subject: Re: [irsg] Meetecho for interims?
Date: Sat, 01 Aug 2020 16:48:24 +0200
Message-Id: <C0FD0348-93CD-417E-93E2-F8FA987C0A93@sunet.se>
References: <B3C59EE7-67C5-44F1-9A1B-6453267B8B58@tzi.org>
Cc: Jim Fenton <fenton@bluepopcorn.net>, WG Chairs <wgchairs@ietf.org>
In-Reply-To: <B3C59EE7-67C5-44F1-9A1B-6453267B8B58@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: iPhone Mail (17F80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/yHMKlCtUP1QG28WJ1w9ubMdg5N8>
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Working Group Chairs <wgchairs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wgchairs/>
List-Post: <mailto:wgchairs@ietf.org>
List-Help: <mailto:wgchairs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Aug 2020 14:48:34 -0000


Skickat från min iPhone

> 1 aug. 2020 kl. 15:31 skrev Carsten Bormann <cabo@tzi.org>:
> 
> On 2020-08-01, at 09:47, Leif Johansson <leifj@sunet.se> wrote:
>> 
>> 
>> 
>> Skickat från min iPhone
>> 
>>>> 31 juli 2020 kl. 23:57 skrev Jim Fenton <fenton@bluepopcorn.net>:
>>> 
>>> On 7/31/20 2:53 PM, Carsten Bormann wrote:
>>>> Yes, but you should be wary of the security issues that you haven’t heard of.
>>>> (Zoombombing is a ridiculous “security issue”.)
>>>> At least, with Webex, I can be reasonably sure about the absence of criminal intent of the operator.
>>> 
>>> That is a very serious allegation that you are making without evidence.
>>> 
>>> -Jim
>>> 
>> 
>> I was just thinking the same thing.
> 
> Actually, it is a statement of fact: I feel way more secure with software from Cisco than with software from Zoom Video Communications (ZVC), because I have good reason not to be certain about ZVC’s corporate intent.  I didn’t know there would be an expectation that I would embellish this simple fact with formal indictment papers.

Thats not what you wrote and I think you know the difference (hence the rest of the email)!

> 
> 
> 
> Feel free to skip the rest of the message if you are not interested in the evidence that makes me so uncertain.  Other people keep asking me why I don’t use ZVC products, so maybe it’s worth writing this up in more detail.
> 
> Mid-2019 a vulnerability became known.  That of course happens every day with something, and a prudent response for me was to uninstall the (rarely used) ZVC software until it is fixed.  Sounded uncomplicated.
> 
> What we didn’t know at first: ZVC had installed a backdoor that, even after deinstallation, allowed them to re-install the software under the covers.  This backdoor could be activated from any website, not just by ZVC.
> 
> OK, this is getting quite serious, but it still might have been an intern doing things that escaped quality control.
> 
> Confronted with the situation, ZVC made a statement essentially saying that this was company policy and all was well.  This is the place where they committed corporate suicide, and I was sure no decent person would ever talk to them again.  Interestingly, nothing happened on the legal side, nobody seemed to have a copy of the CFAA (or § 303b StGB in Germany) handy.
> 
> Finally, this was “resolved” when Apple put pointers to the ZVC backdoor into an emergency malware detector update to get rid of the issue.  That hasn’t happened often, and I would expect Apple to have exhausted all means to fix this amicably before taking out the cudgel (of course they never made any statement about this apart from sending out the malware remover).  Only when it became clear that they wouldn’t get to keep their backdoor, they finally played nice to its removal (“we’re happy to have worked with Apple on testing this update.”).
> 

Incompetent sure,  but how does this show criminal intent?

Srsly if I had a € for every ass-backwards handling of a vulnerability I’ve come across ... but to each her own , thx for the details!

Cheers Leif 

> 
> 
> What happened after that incident did not give any reason to believe something has changed with their corporate policies (sorry, no references, there are too many further incidents, both on the security and privacy sides).
> 
> Of course, 9 months later, when they noticed their stance on security issues might be damaging their COVID-boosted stock price, they started to pay lip service.  I haven’t noticed any consequences of the July incident in their personnel lineup, so I am assuming it is still run by the same people that ran ZVC in mid-2019.  Will they do something like this again?  Seriously, I don’t know.
> 
> All of this has happened in public; there isn’t any news in this message.
> 
> 
> 
> I am not part of the culture that shrugs away persistent, egregious behavior.
> 
> (Yes, Zoom is sooo convenient, so you'll find a lot of apologists.  Also, the sheer number of security issues that pop up and eventually are resolved by ZVC can make it seem they are doing a lot of good recently.  And, those background images…  More seriously, sometimes you have to make tough choices, so I don’t blame the users either.)
> 
> Now you know what makes me feel infinitely safer with Cisco software than with ZVC software, and (in case you wonder why I even care about this) why I feel seriously unhappy about my university deciding to impose the use of ZVC software on its 20000 students (administrative meetings tend to be run on platforms where we have better assurance levels).
> 
> I didn’t set out to write a piece disparaging ZVC, but you (*) asked for information, and the information about the July incident itself unfortunately simply is nothing less then disparaging. I could go on citing more analysis (**), because I had to research the subject seriously when my university started preparing for COVID, but I’ll stop here.
> 
> Grüße, Carsten
> 
> 
> A few refs:
> https://medium.com/bugbountywriteup/zoom-zero-day-4-million-webcams-maybe-an-rce-just-get-them-to-visit-your-website-ac75c83f4ef5
> https://www.schneier.com/blog/archives/2019/07/zoom_vulnerabil.html
> https://www.theverge.com/2019/7/10/20689644/apple-zoom-web-server-automatic-removal-silent-update-webcam-vulnerability
> https://techcrunch.com/2019/07/10/apple-silent-update-zoom-app/
> 
> (*) Actually Jim, but his message never reached me.
> 
> (**) If you need a more in-depth discussion of ZVC's communication security that does not touch corporate responsibility (or even the July incident), I recommend http://www.circleid.com/posts/20200406-rusting-zoom/ [sic] by Steven Bellovin.
> 
> A recent analysis by the German Data Protection Officer may come to the conclusion that no global vendor offers perfect contractual assurances, but for ZVC specifically it is pointing out "Zweifel an der Zuverlässigkeit des Anbieters” (doubts about the reliability of the vendor, p. 14), which is about as far as a German state officer will go in a formal document before starting legal proceedings.
> https://www.datenschutz-berlin.de/fileadmin/user_upload/pdf/orientierungshilfen/2020-BlnBDI-Hinweise_Berliner_Verantwortliche_zu_Anbietern_Videokonferenz-Dienste.pdf
>