Security
SMTP Strict Transport Security
It is no secret that email has been a weak point in the security of the standard Internet protocol suite for quite some time. While improvements to HTTP and TLS have resulted in more robust web security, mail transfer has lagged behind. Now, a new draft RFC has been submitted to the Internet Engineering Task Force (IETF) that may make SMTP connections substantially more secure, closing loopholes that have made mail transfer vulnerable to man-in-the-middle and cryptographic-downgrade attacks.
The draft is called SMTP Strict Transport Security (SMTP STS), and it was first posted on March 18. The authors work for a variety of well-known technology companies and ISPs, including Google, Yahoo, Comcast, Microsoft, LinkedIn, and 1&1 Internet. It sets out a standard by which a mail server can publish an STS Policy that defines how mail transfer agents (MTAs) can connect using TLS, how they can validate the server's TLS certificate, and what they should do in the case that a TLS session cannot be correctly established. As the name implies, SMTP STS is similar in design to HTTP Strict Transport Security (HSTS), defined in RFC6797.
SMTP was originally defined in RFC821, long before TLS (or SSL) were invented, and sent all messages in the clear. The STARTTLS extension (RFC3207) added support for TLS transport in 2002. Although reports are that STARTTLS has proven popular with mail providers, it suffers from some severe shortcomings.
First, the TLS session is subject to downgrade attacks. In the SMTP session-establishment handshake, the STARTTLS command is sent from one machine to the other, in the clear. Upon receipt, the remote machine is intended to respond by initiating a TLS handshake before the SMTP session continues. But an attacker sitting in between the two machines can simply intercept and drop the STARTTLS command (or overwrite it with garbage), in which case the SMTP session will continue in plaintext.
The second shortcoming is that, in a STARTTLS handshake, client machines do not attempt to verify that the TLS certificate presented by the server actually belongs to the expected domain. Here again, an attacker in the middle can intercept the genuine certificate and replace it with a fraudulent one, without the client knowing the difference.
SMTP STS defines a way for a mail server to publish a public record that TLS is available and that SMTP clients should thus use it when making connections. This record is the STS Policy, and has seven mandatory fields:
- v - the SMTP STS version. Only a value of STS1 is supported.
- to - a boolean indicating whether the server is "TLS Only." If true, then clients who encounter errors in the TLS setup must not deliver any mail to the server.
- mx - a comma-separated list of domains for which the policy applies.
- a - the authentication mechanism clients should use to verify that the policy is authentic. The supported mechanisms are DNSSEC and an HTTPS URI at which the client can separately request the policy and verify that the two copies are identical.
- c - the validation method clients should use to verify the authenticity of the server's TLS certificate. The supported methods are DANE TLSA (RFC7672) and verifying the PKI trust chain on the certificate back to a root certificate authority (that is, traditional TLS identity checking as specified in RFC6125).
- e - the maximum lifetime of the policy.
- rua - the address to which feedback and errors may be reported by the client.
A server can publish its STS Policy at https://example.com/.well-known/smtp-sts or via DNS as a TXT record under the name _smtp_sts.example.com. The draft document further specifies that any errors reported to a server by clients should contain details about where unexpected results were encountered: an expired certificate, a DNSSEC failure, a certificate that does not match the server's domain, and so forth.
As Lucian Constantin at InfoWorld pointed out, one possible security loophole is that the first time a client connects to a server, it has no cached copy of the server's STS Policy to compare, so a man-in-the-middle attacker could, in theory, intercept the first request and return a forged policy instead. That forged policy would, by necessity, include an a field similarly doctored to direct the client to an attacker-controlled server when authenticating the policy.
The draft's support for DNS-based policy publishing provides the means for some additional robustness against man-in-the-middle attacks over what is offered by TLS identity checking. If a server's STS Policy is published as a TXT record in a DNSSEC-protected zone, clients can verify its authenticity. Furthermore, the c field can be used to specify that a DANE TLSA record for the server's TLS certificate is required for validation. Thus, an attacker would have to compromise the DNSSEC server in addition to intercepting the SMTP handshake.
The draft also notes that clients are not obligated to accept STS Policies the first time they retrieve them from a server. Instead, they are permitted to use the rua reporting mechanism to tell the server's administrators what they saw. That report can be sent "offline" or during a different session, potentially allowing failures and suspicious reports to be routed around a man-in-the-middle attack. Such a reporting feature is not found in HSTS; nevertheless, SMTP STS is still a "trust on first use" system.
The authors of the draft list two other options to be considered for future inclusion in STMP STS as well. They are certificate pinning, in which a policy could specify specific certificates that must appear in the certificate-validation chain, and policy distribution, in which sites' policies could be recorded and publicly tracked.
The draft also speculates that it could be worthwhile for a policy to specify the list of cryptographic ciphers and TLS versions that the server accepts, and perhaps to specify that all mail received from the server's domain should be expected to arrive over TLS. The latter feature would, in theory, allow a mail server to check for an STS Policy for incoming mail domains and, thus, reject mail that is "supposed to" arrive over TLS but does not. The draft notes, however, that such a policy would come with its share or potential man-in-the-middle attacks to be guarded against, and may not offer significant gains.
STARTTLS has, no doubt, improved the security of e-mail transfer, but it is far from complete. SMTP STS hopefully closes some of the more egregious holes.
Brief items
Security quotes of the week
NSA-as-a-Service does have a certain ring to it though.
Hacking guides often end with a disclaimer: this information is for educational purposes only, be an ethical hacker, don't attack systems you don't have permission to, etc. I'll say the same, but with a more rebellious conception of "ethical" hacking. Leaking documents, expropriating money from banks, and working to secure the computers of ordinary people is ethical hacking. However, most people that call themselves "ethical hackers" just work to secure those who pay their high consulting fees, who are often those most deserving to be hacked.
Gone In Six Characters: Short URLs Considered Harmful for Cloud Services (Freedom to Tinker)
Over at the Freedom to Tinker blog, guest poster Vitaly Shmatikov, who is a professor at Cornell Tech, writes about his study [PDF] of what URL shortening means for the security and privacy of cloud services. "TL;DR: short URLs produced by bit.ly, goo.gl, and similar services are so short that they can be scanned by brute force. Our scan discovered a large number of Microsoft OneDrive accounts with private documents. Many of these accounts are unlocked and allow anyone to inject malware that will be automatically downloaded to users’ devices. We also discovered many driving directions that reveal sensitive information for identifiable individuals, including their visits to specialized medical facilities, prisons, and adult establishments."
How Badlock was discovered and fixed
This post on the Red Hat Enterprise Linux blog describes the discovery and repair of the "Badlock" vulnerability. One begins to understand a little better why it took as long as it did. "The code was rewritten; in March 2016 the changes needed to fix all eight CVEs amounted to about 200 individual patches against a development version of Samba, with about half of those responsible for fixing CVE-2015-5370. When backported to previous stable Samba versions, they needed additional hundred patches. To oldest supported Samba version — about four hundred patches. What started as an individual snowflake became an avalanche but it wasn’t finished yet."
The Android Security 2015 Annual Report
Google has announced the availability of the Android security 2015 year in review [PDF]. "Android’s open source model has also allowed device manufacturers to introduce new security capabilities. Samsung KNOX, for example, has taken advantage of unique hardware capabilities to strengthen the root of trust on Samsung devices. Samsung has also introduced new kernel monitoring capabilities on their Android devices. Samsung is not unique in their contributions to the Android ecosystem. Blackberry has worked to enhance the security of their devices by enabling kernel hardening and other features in the Blackberry PRIV. CopperheadOS has both introduced security improvements to their own version of Android and made significant contributions to the Android Open Source Project. These are just some of the various contributions made possible through open sourcing that improved the Android ecosystem in 2015."
New vulnerabilities
apparmor: profile updates
| Package(s): | apparmor | CVE #(s): | |||||
| Created: | April 20, 2016 | Updated: | April 20, 2016 | ||||
| Description: | From the openSUSE advisory:
This update for apparmor updates some profiles. It is specifically required for the Samba security update. | ||||||
| Alerts: |
| ||||||
chromium: multiple vulnerabilities
| Package(s): | chromium-browser | CVE #(s): | CVE-2016-1651 CVE-2016-1652 CVE-2016-1653 CVE-2016-1654 CVE-2016-1655 CVE-2016-1657 CVE-2016-1658 CVE-2016-1659 CVE-2016-1656 | ||||||||||||||||||||||||||||||||||||||||
| Created: | April 15, 2016 | Updated: | April 25, 2016 | ||||||||||||||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
CVE-2016-1651: An out-of-bounds read issue was discovered in the pdfium library. CVE-2016-1652: A cross-site scripting issue was discovered in extension bindings. CVE-2016-1653: Choongwoo Han discovered an out-of-bounds write issue in the v8 javascript library. CVE-2016-1654: Atte Kettunen discovered an uninitialized memory read condition. CVE-2016-1655: Rob Wu discovered a use-after-free issue related to extensions. CVE-2016-1657: Luan Herrera discovered a way to spoof URLs. CVE-2016-1658: Antonio Sanso discovered an information leak related to extensions. CVE-2016-1659: The chrome development team found and fixed various issues during internal auditing. Added CVE-2016-1656 from Red Hat advisory: android downloaded file path restriction bypass | ||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||
cryptopp: information disclosure
| Package(s): | cryptopp | CVE #(s): | CVE-2016-3995 | ||||||||
| Created: | April 15, 2016 | Updated: | April 25, 2016 | ||||||||
| Description: | From the cryptopp bug report:
For both Rijndael::Enc::ProcessAndXorBlock and Rijndael::Dec::ProcessAndXorBlock there is some code to avoid timing attacks [...] This counter measure seems to be removed by the compiler. Hence, the binary may be vulnerable to timing attacks. | ||||||||||
| Alerts: |
| ||||||||||
imlib2: denial of service
| Package(s): | imlib2 | CVE #(s): | CVE-2016-3993 | ||||||||||||||||||||||||||||
| Created: | April 14, 2016 | Updated: | April 20, 2016 | ||||||||||||||||||||||||||||
| Description: | From the Mageia advisory:
An out-of-bounds read caused by an off-by-one error in __imlib_MergeUpdate() in src/lib/updates.c in imlib2 1.4.8 and earlier (CVE-2016-3993). | ||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||
kernel: three vulnerabilities
| Package(s): | kernel | CVE #(s): | CVE-2016-3951 CVE-2015-8839 CVE-2016-3672 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | April 20, 2016 | Updated: | April 20, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla:
A vulnerability was found in the usbnet Linux kernel driver. The bug allows physically proximate attackers to cause a denial of service (NULL pointer dereference and system crash) or possibly have other impact by inserting a USB device with an invalid USB descriptor. (CVE-2016-3951) A flaw was found in the Linux kernel when attempting to "punch a hole" in files existing on an ext4 filesystem. When punching holes into a file races with the page fault of the same area, it is possible that freed blocks remain referenced from page cache pages mapped to process' address space. Thus modification of these blocks can corrupt data someone else is now storing in those blocks when at some point those pages are written to disk. (CVE-2015-8839) A weakness was found in the Linux ASLR implementation. Any user able to running 32-bit applications in a x86 machine can disable the ASLR by setting the RLIMIT_STACK resource to unlimited. (CVE-2016-3672) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
libtasn1: denial of service
| Package(s): | libtasn1 | CVE #(s): | CVE-2016-4008 | ||||||||||||||||||||||||||||||||||||||||||||
| Created: | April 15, 2016 | Updated: | May 31, 2016 | ||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla entry:
The libtasn1 library, in its 4.7 version, can loop for a long time or indefinitely when it is used to parse DER representations of X509 certificates, leading to a denial of service. Some of these loops may in addition increase heap or stack usage, leading to more issues. | ||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||
openssh: privilege escalation
| Package(s): | openssh | CVE #(s): | CVE-2015-8325 | ||||||||||||||||||||||||||||||||||||||||
| Created: | April 18, 2016 | Updated: | December 15, 2016 | ||||||||||||||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
Shayan Sadigh discovered a vulnerability in OpenSSH: If PAM support is enabled and the sshd PAM configuration is configured to read user- specified environment variables and the "UseLogin" option is enabled, a local user may escalate her privileges to root. | ||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||
optipng: denial of service
| Package(s): | optipng | CVE #(s): | CVE-2015-7802 | ||||||||
| Created: | April 14, 2016 | Updated: | April 20, 2016 | ||||||||
| Description: | From the Mageia advisory:
CVE-2015-7802 - Buffer over-read issue | ||||||||||
| Alerts: |
| ||||||||||
optipng: code execution
| Package(s): | optipng | CVE #(s): | CVE-2016-3981 CVE-2016-3982 | ||||||||||||||||
| Created: | April 18, 2016 | Updated: | April 20, 2016 | ||||||||||||||||
| Description: | From the CVE entries:
Heap-based buffer overflow in the bmp_read_rows function in pngxrbmp.c in OptiPNG before 0.7.6 allows remote attackers to cause a denial of service (out-of-bounds read or write access and crash) or possibly execute arbitrary code via a crafted image file. (CVE-2016-3981) Off-by-one error in the bmp_rle4_fread function in pngxrbmp.c in OptiPNG before 0.7.6 allows remote attackers to cause a denial of service (out-of-bounds read or write access and crash) or possibly execute arbitrary code via a crafted image file, which triggers a heap-based buffer overflow. (CVE-2016-3982) | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
poppler: code execution
| Package(s): | poppler | CVE #(s): | CVE-2015-8868 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | April 15, 2016 | Updated: | December 15, 2016 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla entry:
A heap buffer overflow vulnerability was found in the poppler library. A maliciously crafted file could cause the application to crash. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
postgresql: two vulnerabilities
| Package(s): | postgresql | CVE #(s): | CVE-2016-2193 CVE-2016-3065 | ||||
| Created: | April 14, 2016 | Updated: | April 20, 2016 | ||||
| Description: | From the Mageia advisory:
A vulnerability in PostgreSQL 9.3.x before 9.3.12 and 9.4.x before 9.4.7 leads to potentially incorrect policies being applied in cases where role-specific policies are used and a given query is planned under one role and then executed under other roles, which could happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs. Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications. This affects only databases that have used CREATE POLICY to define a row security policy (CVE-2016-2193). A vulnerability was found in a way PostgreSQL 9.3.x before 9.3.12 and 9.4.x before 9.4.7 uses pageinspect functions. Certain function arguments crashed the server or disclosed a few bytes of server memory. The viability of attacks that arrange for presence of confidential information in the disclosed bytes was not ruled out. This affects only databases that have used "CREATE EXTENSION pageinspect" (CVE-2016-3065). | ||||||
| Alerts: |
| ||||||
qpid-proton: TLS to plaintext downgrade
| Package(s): | qpid-proton | CVE #(s): | CVE-2016-2166 | ||||
| Created: | April 15, 2016 | Updated: | April 20, 2016 | ||||
| Description: | From the Red Hat bugzilla entry:
Messaging applications using the Proton Python API to provision an SSL/TLS encrypted TCP connection may actually instantiate a non-encrypted connection without notice if SSL support is unavailable. This will result in all messages being sent in the clear without the knowledge of the user. | ||||||
| Alerts: |
| ||||||
quagga: password disclosure
| Package(s): | quagga | CVE #(s): | |||||
| Created: | April 14, 2016 | Updated: | April 20, 2016 | ||||
| Description: | From the openSUSE advisory:
/etc/quagga and its contents were world-readable despite containing passwords. | ||||||
| Alerts: |
| ||||||
systemd: two vulnerabilities
| Package(s): | systemd | CVE #(s): | CVE-2014-9770 CVE-2015-8842 | ||||||||
| Created: | April 19, 2016 | Updated: | April 20, 2016 | ||||||||
| Description: | From the openSUSE bug report:
On Leap archived journal files in /var/log/journal/$uuid are all world-readable - both system and user. The current journal (i.e. system.journal for system instance or user-$UID.journal for user) are correctly restricted to root/systemd-journal or owning user). This allows any user to read anyone's archived journals by using explicit journalctl --file=/path/to/archived/file This problem does not exist on Tumbleweed where access to archived files are restricted in the same way as to current journal. When user attempts to read journal without specifying filename, journalctl tries to open current journal first and errors out, which hides this issue. On 13.2 it is worse - even current log in /run/log/journal is world-readable. (CVE-2014-9770) Unspecified (CVE-2015-8842) | ||||||||||
| Alerts: |
| ||||||||||
tiff: denial of service
| Package(s): | tiff | CVE #(s): | CVE-2016-3186 | ||||||||||||||||||||||||||||||||||||||||
| Created: | April 18, 2016 | Updated: | April 20, 2016 | ||||||||||||||||||||||||||||||||||||||||
| Description: | From the openSUSE bug report:
A buffer overflow vulnerability was reported in libtiff library, in gif2tiff component. A maliciously crafted file could cause the application to crash. | ||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>