Subject: Re: Meetecho for interims?

From: Leif Johansson <[email-masked]>
Date: Sat, 1 Aug 2020 09:47:43 +0200

Skickat från min iPhone

> 31 juli 2020 kl. 23:57 skrev Jim Fenton <[email-masked]>:
> 
> 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.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 1 Aug 2020 15:31:03 +0200

> 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.

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.”).

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 Zuverlä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

---

From: Leif Johansson <[email-masked]>
Date: Sat, 1 Aug 2020 16:48:24 +0200

Skickat från min iPhone

> 1 aug. 2020 kl. 15:31 skrev Carsten Bormann <[email-masked]>:
> 

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

> 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…

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

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 1 Aug 2020 18:09:59 +0200

OK, this is getting a bit off-topic…  Apologies.

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

Right, I wrote that *with Webex* I can be reasonably sure of the absence of criminal intent of the operator.

> Incompetent sure,  but how does this show criminal intent?

I’m not a lawyer, so I cannot answer that question.

But declaring that intentionally installing malware on my computer (that makes it vulnerable to first and third party attacks) is exactly what this company does, is *something*.
I can report that it (and the time I now had to waste cleaning up my computer) destroyed any trust I might have had in this company to heed basic corporate responsibility — this incident was no longer grossly negligent, this was intentional.  Hence my statement of uncertainty about what they will do in the future.

> 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!

I continue to see a difference between badly handling a wide open backdoor and a statement that installing such backdoors is just the way the company intends to do business.

We have grown such a deep distrust of software vendors that we may think the behavior we have seen here may be just the way it is.  Not so.  And we have to stop simply ignoring such behavior, or worse, becoming apologetic of it.

Grüße, Carsten

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 2 Aug 2020 04:53:03 +0200

Carsten:

What specifically are the technical risks for which you would not have joined
a ZVC meeting, such as one of the IETF108 side meetings that used zoom ?
(or for that matter of course future interims, which this thread is about)

If the reason is fear of unknown undetected security risk due to lack of
trust into the security diligence of ZVC, would using the RTCweb browser
client instead of the native client resolve this issue ?

IMHO:

If we want future interims like past interims to be publically announced
without participant auhentication, i think zoombombing would be a risk
for any platform we choose: meetecho, webex, zoom, BBB, whatever.

Given how an interim is meant to be public and i hope recorded, there
is no risk of undesired recording by third party either (as in: please go ahaead).

Leaves as the biggest risk AFAIK the problem of clients creating backdoors,
and i would hope that w3c/ietf work on browser client platform security
would be sufficient.

Of course, we could argue that we would like authentication for all IETF
activities to also overcome zoombombing risks, but then it would be really
nice to extend the cover of authentication if not also tooling to what
is currently called inofficial side meetings.

Cheers
    Toerless

P.S.: This is not meant to imply preference for any specific platform.

On Sat, Aug 01, 2020 at 06:09:59PM +0200, Carsten Bormann wrote:
> OK, this is getting a bit off-topic???  Apologies.
> 
> >>>>> 
> >> 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.
> > 
> I???m not a lawyer, so I cannot answer that question.
> 
> I can report that it (and the time I now had to waste cleaning up my computer) destroyed any trust I might have had in this company to heed basic corporate responsibility ??? this incident was no longer grossly negligent, this was intentional.  Hence my statement of uncertainty about what they will do in the future.
> 
> > 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!
> 

-- 
---
[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 2 Aug 2020 21:28:20 +0200

Hi Toerless,

I really didn’t want to further extend this part of the thread.
But it seems my position can easily be misunderstood.

> (or for that matter of course future interims, which this thread is about)

The technical risks, and ZVC’s moves to appear getting them covered, are well documented.  I cited Steven Bellovin’s piece that came to the conclusion that these are manageable for the kinds of communication that are similar to what we do in open meetings.
(I don’t agree with respect to system security.)

However, the reason I’m not going to join conferences based on ZVC products is mainly Ethical, with the technical issues playing second fiddle.

> client instead of the native client resolve this issue ?

Certainly not the Ethical issues.  On the technical side, I do believe that I should prefer browser access over installing vendor-supplied apps with wide access to my system.  But, again, see Steve’s counterpoint on this specific issue.

As a general observation, it is enlightening to which level of criminal energy (technical term here, not the legal one) the ZVC developers have risen to circumvent CORS for their backdoor; it does not seem far-fetched to assume there will be other attacks on browser security when the browser security features happen to get in the way of ZVC corporate policy.

> for any platform we choose: meetecho, webex, zoom, BBB, whatever.

Even discussing Zooombombing as a security issue makes me question whether you have started to consider the real issues.  However, let me point out that conferencing systems based on authorization, such as meetecho or BBB (if correctly configured) only have the problem as far as the authorization can be gamed.

> and i would hope that w3c/ietf work on browser client platform security

(See above.)

Fool me once, shame on you; fool me twice, shame on me.

Grüße, Carsten

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 3 Aug 2020 15:58:03 +0200

On Sun, Aug 02, 2020 at 09:28:20PM +0200, Carsten Bormann wrote:
> Hi Toerless,
> 
> I really didn???t want to further extend this part of the thread.

I actually find it quite important that we had more of this type of discussion about actually
system-level security considerations instead of just the end-to-end transport channel crypto.
Of course, this may not be the right thread, and its also unclear what type of draft document
couldn/should be created from this, but it would be a pity of this wasn't something that
ended up in a place where it could be educational to more IETF'ler'. Especially with all
the interesting references you've collected already.

> The technical risks, and ZVC???s moves to appear getting them covered, are well documented.  I cited Steven Bellovin???s piece that came to the conclusion that these are manageable for the kinds of communication that are similar to what we do in open meetings. (I don???t agree with respect to system security.)

I saw a range of discuss worthy aspects in Steven's document:

a) unless i overlooked something, he just said that he mistrusts browsers more...because of they multi-application/CORS atack surface (i guess). Sounds to me like a reasonable argument, but one that might be possible to overcome if we had a model by which you could start instances of browser (such as in a container model) constrained to a specific (set of) URLs it can access. Many Android Apps AFAIK are just those type of shims on top of browser rendering too. Just no well established model on desktops AFAIK.

b) He rightfully points out that malicious client code is the weakest link, especially when it is written by entities that could be extorted by governments. Unfortunately he then still goes on to claim Zoom is less to be trusted than Cisco given how Zoom has Chinese based development. The same of course is true for Webex. And the extend to which USA lawful intercept can be applied not only to SP but also to software vendors seem to be quite unclear and unknown. Especially given how few such vendors even have warrant canaries to indicate when they had a run in with the US security agencies. 

> However, the reason I???m not going to join conferences based on ZVC products is mainly Ethical, with the technical issues playing second fiddle.

> Certainly not the Ethical issues.  On the technical side, I do believe that I should prefer browser access over installing vendor-supplied apps with wide access to my system.  But, again, see Steve???s counterpoint on this specific issue.

I am wondering how a javascript client is not also easier decoded and analyzed.
But ideally, the javascript browser clients could/should be open source.

> As a general observation, it is enlightening to which level of criminal energy (technical term here, not the legal one) the ZVC developers have risen to circumvent CORS for their backdoor; it does…

I wonder if there are good written standards for security development
from which the judgements ("criminal energy") that you are making could be
drawn. E.g.: I would not be surprised to hear competely differently
worded judgement calls from other evaluations and i therefore think
there are no good "community" ? "industry" ? standard for such judgmenets.
Or are there ?

> Even discussing Zooombombing as a security issue makes me question whether you have started to consider the real issues.  However, let me point out that conferencing systems based on authorization,…

I didn't say security. Just a list of issues to consider.

I think we are in full agreement that user authentication is probably the easiest
way to avoid zoomboming (whatever tool we use). However, the current datatracker
account (manually created) and paywall, single-instance participation only are
too limited to widen the use of meetecho to all the cases we would want to support IMHO.

Cheers
    Toerless

-- 
---
[email-masked]