Security
A look at the OMEMO protocol
For several years, the Off-the-Record (OTR) protocol has been the go-to option for application developers and users needing to secure instant-messaging (IM) conversations. OTR provides a number of features useful for IM, such as mutual authentication and forward secrecy, without requiring a public infrastructure like PGP's web of trust. But OTR has its limitations as well, such as the lack of a way to synchronize a user's messages between multiple clients and an inability to send messages to a user who is offline. In recent months, however, a new alternative has gained popularity. OMEMO, the "OMEMO Multi-End Message and Object Encryption" protocol, fills several of the gaps left open in OTR, while promising ease-of-use to end users. OMEMO also dispenses with one of the oft-criticized requirements of Signal, doing away with the need for a centralized server.
OMEMO is implemented as an extension to the XMPP IM protocol. At present, the specification has not been officially accepted by the XMPP Standards Foundation, so OMEMO does not have an XMPP Extension Protocol (XEP) designation. The first draft was published in October of 2015, based on work by Andreas Straub.
The initial implementation was written by Straub as a Google Summer of Code project for the Conversations IM client for Android. Subsequently, The Guardian Project announced that it would rebase its ChatSecure app on Conversations—although, as we will see, that work became mired in license-compatibility issues that have only recently moved toward a positive resolution. There is also an OMEMO plugin for the Gajim desktop IM client and support has been added to the Cryptocat desktop IM application.
Ratchets
OMEMO's design borrows from the Double Ratchet algorithm (formerly known as the Axolotl Ratchet) developed for the TextSecure and Signal apps. The Double Ratchet algorithm, interestingly, is itself derived from the OTR key-exchange protocol. In this context, the "ratchet" is the function used to derive the new ephemeral key pair that a client uses to encrypt its next outgoing message.
OTR required each client to send every new public key to the other party, then wait for an acknowledgment message to return before using the new key pair. This has the drawback of forcing the client to keep using the same key for several messages if the other party is slow to reply (and it has the side effect of requiring the entire conversation to be a "live" session; one cannot send an OTR message to a user who is offline).
In a Double-Ratchet session, the "key" used to encrypt a message is actually a compound object made up of two parts: a "root" key and a "chain" key. Thus, the client can generate a new ephemeral key pair using either of two mechanisms or ratchets. Whenever the participants successfully exchange messages, they can also update the root keys they use, just as in OTR. But, in between receiving messages from the other party, each client uses a second key-derivation function to update the chain key. The second key-derivation function generates a new chain key by hashing the previous chain key. Because this second ratchet derives its new keys solely from old keys, with no Diffie-Hellman exchange required, the client can generate new keys as often as its needs to. Furthermore, the remote client is able to "catch up" whenever it needs to, and it can even recover messages that arrive out-of-order.
Both OTR and Double Ratchet are limited to one-to-one conversations. OTR's limitation comes from the key-exchange protocol itself; the Signal app provides the additional feature of allowing a user to keep conversation history in sync between multiple clients, but it does this by routing the (encrypted) messages through the central Signal servers.
In addition, Double Ratchet (as implemented in Signal) relies on a central server to secure the initial key exchange step between any new pair of clients. Upon registering with the service the first time, each Signal client generates a set of one-time-use "prekeys" that are stored on the server. Whenever a new remote contact initiates a conversation with the client, the server provides that contact with one of the prekeys, thus enabling the client-to-client session setup.
Many-to-many encryption
OMEMO enables multi-client chats by establishing a separate Double Ratchet channel to every participating client in the conversation—including the remote chat partners and every additional client that has been configured by the user. So Alice's desktop chat program sets up a channel not only to Bob, but one to Alice's mobile phone app as well.
Every message sent by the OMEMO application includes a single payload plus a separate header for each client. The payload is the message body, encrypted with an ephemeral key. Each of the headers contains a copy of the message-body's key, encrypted with a different, per-device session key. Thus, the message body is only sent once, but each remote client is only able to decrypt its own header. The ephemeral keys are periodically updated using Double Ratchet, thus providing forward secrecy.
Being built on XMPP, the protocol is largely server-independent and can be federated. However, the XMPP servers employed by the users do need to support Message Carbons (XEP-0280), which relays multiple copies of each message to all of the intended recipients, and Message Archive Management (XEP-0313), which enables a client to retrieve any messages sent while the client was offline. Both of these XEPs are still working their way through the formal approval process.
OMEMO also decentralizes the initial set-up scheme. Whereas Signal requires the central server to store prekeys for every registered client, OMEMO instead uses the Personal Eventing Protocol (PEP), an existing XMPP extension also known as XEP-0163. With PEP, each client randomly generates the equivalent of a prekey each time it starts up and advertises it to the XMPP server. When a chat session is initiated, the users' XMPP servers contact each other to set up the connection, and they relay the current prekeys between the clients. After set-up, the prekeys can be permanently discarded.
Further developments
OMEMO also supports some features not covered by OTR, such as encrypted client-to-client file transfer. This is done by first sending an XMPP message that contains only a decryption key. Subsequently, the sending client can encrypt the file and send it to the recipient using an existing XMPP file-transfer method (of which there are several options, like XEP-0096, XEP-0234 and XEP-0047). Conversations supports the XEP-0234 method, which is built on top of the Jingle protocol.
OMEMO is still rather new, at least in comparison to OTR, but it has been gaining exposure and several free-software application projects have been exploring it of late. For several months, though, the migration of ChatSecure from its own code base to Conversations was held up by a licensing issue. The crux of the matter was that the ChatSecure developers wanted to reuse the Double Ratchet code released by Signal, known as SignalProtocolKit.
But, unlike Conversations, ChatSecure publishes its app for iOS as well as Android, and SignalProtocolKit is under the GPL—preventing it from inclusion in apps distributed through the iOS App Store (at least in the eyes of many license-compliance experts). On June 13, however, Open Whisper Systems updated the license to include an "additional permissions" clause permitting distribution on the iOS App Store. After the announcement, ChatSecure's Chris Ballinger indicated that the porting effort would resume.
Having multiple implementations available is a vital stress-test for any protocol, of course. Signal quickly garnered endorsements from security researchers like Matthew Green, which encouraged other developers to consider utilizing the Double Ratchet algorithm. By adopting it, OMEMO enables chat clients to move beyond OTR's limitations. The next test will be to see whether OMEMO's extensibility not only gives it an edge over OTR, but over Signal as well. Many free-software advocates find Signal's dependence on a centralized server to be a non-starter; OMEMO may allow them to route around the issue entirely.
Brief items
Security quotes of the week
The results of this thesis showed that creating a botnet by exploiting typo errors from humans is perfectly possible. However, it is not easy to answer how much the cover of free research from the University covered and prevented a interruption of the empiric study by security researchers.
A large portion of ME's security model is "security through obscurity", a practice that many researchers view as the worst type of security. If ME's secrets are compromised (and they will eventually be compromised by either researchers or malicious entities), then the entire ME security model will crumble, exposing every recent Intel system to the worst rootkits imaginable.
Help Make Open Source Secure (The Mozilla Blog)
On The Mozilla blog, Chris Riley announces the "Secure Open Source" (SOS) fund to provide money to help with the security of open-source software. "The SOS Fund will provide security auditing, remediation, and verification for key open source software projects. The Fund is part of the Mozilla Open Source Support program (MOSS) and has been allocated $500,000 in initial funding, which will cover audits of some widely-used open source libraries and programs. But we hope this is only the beginning. We want to see the numerous companies and governments that use open source join us and provide additional financial support. We challenge these beneficiaries of open source to pay it forward and help secure the Internet. Security is a process. To have substantial and lasting benefit, we need to invest in education, best practices, and a host of other areas. Yet we hope that this fund will provide needed short-term benefits and industry momentum to help strengthen open source projects." SOS sounds similar in scope to the Core Infrastructure Initiative (CII) set up by the Linux Foundation.
Tschacher: Typosquatting programming language package managers
Nikolai Tschacher demonstrates how easy it is to run arbitrary code by way of "typosquatting" uploads to programming language download sites. "Because everybody can upload any package on PyPi, it is possible to create packages which are typo versions of popular packages that are prone to be mistyped. And if somebody unintentionally installs such a package, the next question comes intuitively: Is it possible to run arbitrary code and take over the computer during the installation process of a package?" He tried an experiment and was able to run a little program that phoned home from thousands of systems.
Let's Encrypt Email Address Disclosures
Let's Encrypt has a preliminary report about an email address disclosure. "On June 11 2016 (UTC), we started sending an email to all active subscribers who provided an email address, informing them of an update to our subscriber agreement. This was done via an automated system which contained a bug that mistakenly prepended between 0 and 7,618 other email addresses to the body of the email. The result was that recipients could see the email addresses of other recipients. The problem was noticed and the system was stopped after 7,618 out of approximately 383,000 emails (1.9%) were sent. Each email mistakenly contained the email addresses from the emails sent prior to it, so earlier emails contained fewer addresses than later ones." A postmortem is underway. (Thanks to Paul Wise)
Update: postmortem results have been added to the incident report. "A small piece of software had been written to handle one-off mass emailing to our subscribers. It was being used for the first time when this incident occurred.
The software went through code review and testing as it was being
developed, but testing was insufficient. It did not catch a bug which
prepended the email addresses of prior recipients to the body of emails. Insufficient testing is considered to be the root cause of this incident.
"
New vulnerabilities
gnutls: arbitrary file overwrite
| Package(s): | gnutls | CVE #(s): | CVE-2016-4456 | ||||||||||||
| Created: | June 9, 2016 | Updated: | June 15, 2016 | ||||||||||||
| Description: | From the Red Hat bugzilla entry:
It was reported that gnutls 3.4.12 uses an environment variable (GNUTLS_KEYLOGFILE) to write the keys of the running sessions. This variable is obtained insecurely via getenv(), meaning that any set-uid program using gnutls can be used to overwrite any file on the filesystem. | ||||||||||||||
| Alerts: |
| ||||||||||||||
haproxy: denial of service
| Package(s): | haproxy | CVE #(s): | CVE-2016-5360 | ||||||||||||
| Created: | June 10, 2016 | Updated: | June 29, 2016 | ||||||||||||
| Description: | From the Arch Linux advisory:
A problem has been discovered with the new field "rule_deny_status" into struct http_txn, which is filled only by actions "http-request deny" and "http-request tarpit". It's then used in the deny code path to emit the proper error message, but is used uninitialized when the deny comes from a "reqdeny" rule, causing random behaviours ranging from returning a 200, an empty response, or crashing the process. A remote attacker is able to use a specially crafted request to crash the process resulting in denial of service. | ||||||||||||||
| Alerts: |
| ||||||||||||||
kernel: denial of service
| Package(s): | kernel | CVE #(s): | CVE-2015-5327 | ||||||||||||
| Created: | June 13, 2016 | Updated: | June 15, 2016 | ||||||||||||
| Description: | From the Mageia advisory:
An out-of-bounds memory read was found, affecting kernels from 4.3-rc1 onwards. This vulnerability was caused by incorrect X.509 time validation in x509_decode_time() function in x509_cert_parser.c | ||||||||||||||
| Alerts: |
| ||||||||||||||
kernel: two vulnerabilities
| Package(s): | kernel | CVE #(s): | CVE-2016-1583 CVE-2016-4565 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | June 10, 2016 | Updated: | November 4, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Ubuntu advisory:
Jann Horn discovered that eCryptfs improperly attempted to use the mmap() handler of a lower filesystem that did not implement one, causing a recursive page fault to occur. A local unprivileged attacker could use to cause a denial of service (system crash) or possibly execute arbitrary code with administrative privileges. (CVE-2016-1583) Jann Horn discovered that the InfiniBand interfaces within the Linux kernel could be coerced into overwriting kernel memory. A local unprivileged attacker could use this to possibly gain administrative privileges on systems where InifiniBand related kernel modules are loaded. (CVE-2016-4565) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
libav: code execution
| Package(s): | libav | CVE #(s): | CVE-2016-3062 | ||||||||||||
| Created: | June 14, 2016 | Updated: | June 27, 2016 | ||||||||||||
| Description: | From the Debian LTS advisory:
It was discovered that there was a memory corruption issue in libav (a multimedia player, server, encoder and transcoder) when parsing .mp4 files which could lead to crash or possibly execute arbitrary code. | ||||||||||||||
| Alerts: |
| ||||||||||||||
libjpeg: memory leak
| Package(s): | libjpeg libjpeg-turbo | CVE #(s): | |||||||||
| Created: | June 13, 2016 | Updated: | January 3, 2017 | ||||||||
| Description: | From the Mageia advisory:
Out-of-Bounds Read in libjpeg-turbo before 1.5.0 via unusually long Blocks in MCU (LJT-01-005). See the libjpeg-turbo Pentest-Report [PDF] for details. | ||||||||||
| Alerts: |
| ||||||||||
libtorrent-rasterbar: denial of service
| Package(s): | libtorrent-rasterbar | CVE #(s): | CVE-2016-5301 | ||||||||||||||||||||
| Created: | June 13, 2016 | Updated: | September 12, 2016 | ||||||||||||||||||||
| Description: | From the Debian LTS advisory:
A specially crafted HTTP response from a tracker (or potentially a UPnP broadcast) can crash libtorrent in the parse_chunk_header() function. Although this function is not present in this version, upstream's additional sanity checks were added to abort the program if necessary instead of crashing it. | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
mantis: cross-site scripting
| Package(s): | mantis | CVE #(s): | CVE-2016-5364 | ||||
| Created: | June 13, 2016 | Updated: | June 15, 2016 | ||||
| Description: | From the Debian LTS advisory:
It was discovered that there was an XSS vulnerability in custom field management in mantis, a web-based bug tracking system. | ||||||
| Alerts: |
| ||||||
monit: disable SSLv3
| Package(s): | monit | CVE #(s): | |||||
| Created: | June 15, 2016 | Updated: | June 15, 2016 | ||||
| Description: | From the openSUSE bug report:
Disable SSLV3 According to the RFC 7568, SSLv3 is no longer consider secure. Ref: https://tools.ietf.org/html/rfc7568 This Patch allows Monit to be build without SSLV3 enabled. | ||||||
| Alerts: |
| ||||||
nspr: buffer overflow
| Package(s): | nspr | CVE #(s): | CVE-2016-1951 | ||||||||||||||||
| Created: | June 13, 2016 | Updated: | October 6, 2016 | ||||||||||||||||
| Description: | From the Debian LTS advisory:
t was discovered that there was a buffer overflow in a sprintf utility within nspr, the NetScape Portable Runtime library. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
php5: three vulnerabilities
| Package(s): | php5 | CVE #(s): | CVE-2013-7456 CVE-2015-8876 CVE-2016-5114 | ||||||||||||||||||||||||||||||||||||||||
| Created: | June 13, 2016 | Updated: | June 15, 2016 | ||||||||||||||||||||||||||||||||||||||||
| Description: | From the openSUSE advisory:
- CVE-2013-7456: imagescale out-of-bounds read (bnc#982009). - CVE-2015-8876: Zend/zend_exceptions.c in PHP did not validate certain Exception objects, which allowed remote attackers to cause a denial of service (NULL pointer dereference and application crash) or trigger unintended method execution via crafted serialized data (bsc#981049). - CVE-2016-5114: fpm_log.c memory leak and buffer overflow (bnc#982162). | ||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||
qemu: denial of service
| Package(s): | qemu | CVE #(s): | CVE-2016-4952 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | June 13, 2016 | Updated: | June 15, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the openSUSE bug report:
Quick Emulator(Qemu) built with the VMWARE PVSCSI paravirtual SCSI bus emulation support is vulnerable to an OOB r/w access issue. It could occur while processing SCSI commands 'PVSCSI_CMD_SETUP_RINGS' or 'PVSCSI_CMD_SETUP_MSG_RING'. A privileged user inside guest could use this flaw to crash the Qemu process resulting in DoS. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
wireshark: multiple vulnerabilities
| Package(s): | wireshark | CVE #(s): | CVE-2016-5350 CVE-2016-5351 CVE-2016-5352 CVE-2016-5353 CVE-2016-5354 CVE-2016-5355 CVE-2016-5356 CVE-2016-5357 CVE-2016-5358 CVE-2016-5359 | ||||||||||||||||
| Created: | June 13, 2016 | Updated: | July 5, 2016 | ||||||||||||||||
| Description: | From the Mageia advisory:
The SPOOLS dissector could go into an infinite loop (CVE-2016-5350). The IEEE 802.11 dissector could crash (CVE-2016-5351). The IEEE 802.11 dissector could crash (CVE-2016-5352). The UMTS FP dissector could crash (CVE-2016-5353). Some USB dissectors could crash (CVE-2016-5354). The Toshiba file parser could crash (CVE-2016-5355). The CoSine file parser could crash (CVE-2016-5356). The NetScreen file parser could crash (CVE-2016-5357). The Ethernet dissector could crash (CVE-2016-5358). Infinite loop in parse_wbxml_tag_defined() in WBXML Dissector (CVE-2016-5359). | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>