From f3e2300a6420c14939f288f575b9a155838cc3eb Mon Sep 17 00:00:00 2001 From: akwizgran <michael@briarproject.org> Date: Fri, 19 May 2023 16:11:49 +0100 Subject: [PATCH] Add blog post about security issues. --- ...3-three-security-issues-found-and-fixed.md | 152 ++++++++++++++++++ 1 file changed, 152 insertions(+) create mode 100644 content/news/2023-three-security-issues-found-and-fixed.md diff --git a/content/news/2023-three-security-issues-found-and-fixed.md b/content/news/2023-three-security-issues-found-and-fixed.md new file mode 100644 index 0000000..24ee041 --- /dev/null +++ b/content/news/2023-three-security-issues-found-and-fixed.md @@ -0,0 +1,152 @@ +--- +aliases: +- /news/2023-three-security-issues-found-and-fixed.html +date: 2023-05-24T11:00:00+00:00 +title: "Three security issues found and fixed" +--- + +In February of this year, security researchers at +[ETH Zürich](https://appliedcrypto.ethz.ch/) notified us that they had found +three security issues in the Briar app. Two of these issues were fixed in +version 1.4.22 of Briar, which was released in February. The third issue was +fixed in version 1.5.3, which is being released today. All users are +encouraged to upgrade to version 1.5.3 of the app as soon as possible. + +We have not received any reports of these bugs being exploited in the wild, +and the third issue is not exploitable. + +We would like to apologise for the design and implementation mistakes that led +to these issues, and to thank Yuanming Song and Prof. Kenny Paterson for +finding the issues and responsibly disclosing them to us. + +We have requested an independent security audit of Briar's protocol stack to +ensure that no other issues remain undiscovered. + +For those who are interested in the details, a description of each issue is +given below. The researchers' report can be found [here](https://ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/appliedcrypto/education/theses/report_YuanmingSong.pdf). + +### Issue 1: Receiving invalid message would have caused app to exit + +The first issue (fixed in Briar 1.4.22) would have allowed a malicious user to +prevent their contacts from using Briar by repeatedly sending them invalid +messages that would cause the app to exit. + +Receiving a message longer than the maximum allowed length should have raised +an error that would cause the invalid message to be discarded. Instead, the +check raised a different type of error that would cause the app to exit. + +There was no risk of memory corruption, as the length check took place in +memory-safe Java code. Invalid messages were not stored or forwarded to other +users. + +### Issue 2: Message duplication in blogs, forums and private groups + +The second issue (fixed in Briar 1.4.22) would have allowed a malicious user +to create duplicates of messages written by other users in blogs, forums and +private groups. The duplicates would have had the same content and timestamps +as the originals, but would have appeared alongside the originals as though +they were separate messages from the same authors. + +To explain this issue we need to give some background information about the +structure of Briar messages. + +Every message in Briar consists of a timestamp, a group identifier and a +message body. Each message has a unique identifier that is calculated by +hashing these fields. + +Different features of the app use these fields in different ways. The blog, +forum and private group features make use of digital signatures: the body of +each message contains some content along with a digital signature by the +author of the content. The signature covers the content as well as the +timestamp, the group identifier and the author's Briar identity. + +When verifying the signature on a message, Briar deserialises the message body +to extract the content and signature, then serialises the content, timestamp, +group identifier and author's Briar identity to recreate the exact information +that was originally signed. This ensures that none of these fields can be +altered without invalidating the signature. + +The ETH Zürich researchers discovered that this process of deserialising the +message body and then reserialising the content to verify the signature made +it possible to take a message signed by another user and produce a message +with a different body (and therefore a different unique identifier) that would +nevertheless be identical to the original after deserialisation and +reserialisation. Thus the signature from the original message would still be +valid, and there would appear to be two identical messages signed by the same +author. + +It would not have been possible to alter the content, timestamp, group +identifier or Briar identity without invalidating the signature, but the +duplicate messages might have caused confusion. + +This issue occurred because Briar did not check that the message body was +serialised in canonical form before deserialising it, so it was possible to +create multiple non-canonical representations of the same message body, which +would all be converted into the same canonical form after deserialisation and +reserialisation. + +Fortunately, genuine messages in blogs, forums and private groups have always +been created in canonical form, so the issue was solved by rejecting any +messages that were not in canonical form. + +### Issue 3: Poorly designed cryptographic handshake + +The third issue (fixed in Briar 1.5.3) involved a poorly designed +cryptographic handshake. At first it appeared that design flaws in this +handshake could have allowed network traffic between Briar users to be +decrypted by an attacker who had successfully carried out a specific set of +other attacks against those users. Fortunately, we were able to confirm that +this was not possible thanks to an extra layer of cryptographic protection +provided by the Tor network. The issue was not exploitable and there was no +danger to users. Even so, Briar 1.5.3 replaces the insecure handshake with a +more secure version. + +The handshake in question is part of the Bramble Handshake Protocol (BHP), +which is used when users add each other as contacts by exchanging Briar links. +The purpose of BHP is to derive a shared secret that is known to both users +but not to anyone else, include anyone who may be eavesdropping on the network +connection used for the handshake. The shared secret is ephemeral, meaning +that it should not be possible to recreate the shared secret using any +information that is retained by the users after the handshake. + +BHP did not meet these design criteria. An adversary who was able to eavesdrop +on the connection that was used for the handshake, and was later able to +compromise both users' Briar accounts, could have decrypted network traffic +between the users that was sent between the time of the handshake and the time +of the account compromises. + +Fortunately, we were able to confirm that the eavesdropping part of the attack +was not achievable. The connections used for BHP handshakes are always made +via the Tor network, using version 3 of Tor's hidden service protocol. Through +discussions with the developers of Tor we were able to confirm that this +protocol uses strong encryption that would have prevented an adversary from +eavesdropping on BHP handshakes. Without being able to eavesdrop, an adversary +could not later decrypt past network traffic even if both users' accounts were +compromised. + +The poor design of the BHP handshake was a serious mistake on our part. +Fortunately, thanks to the extra layer of protection provided by Tor, users +were not put at risk by this mistake. + +Briar 1.5.3 replaces the insecure handshake with a more secure version, and we +have requested an independent security audit of the whole protocol stack to +ensure that no other mistakes of this kind were made. + +### About Briar + +Briar is a messaging app designed for activists, journalists, and anyone else +who needs a safe, easy and robust way to communicate. Unlike traditional +messaging tools such as email, Twitter or Telegram, Briar doesn't rely on a +central server - messages are synchronized directly between the users' +devices. If the internet's down, Briar can sync via Bluetooth or Wi-Fi, +keeping the information flowing in a crisis. If the internet's up, Briar can +sync via the Tor network, protecting users and their relationships from +surveillance. + +{{% funding %}} + +{{< contact >}} + +Twitter: [@BriarApp](https://twitter.com/BriarApp) + +Mastodon: [@Briar](https://fosstodon.org/@briar) -- GitLab