mirror of
https://github.com/OMGeeky/google-apis-rs.git
synced 2026-02-23 15:49:49 +01:00
90 lines
11 KiB
HTML
90 lines
11 KiB
HTML
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1.0"><meta name="generator" content="rustdoc"><meta name="description" content="API documentation for the Rust `_01_impl_vulnerabilities` mod in crate `rustls`."><meta name="keywords" content="rust, rustlang, rust-lang, _01_impl_vulnerabilities"><title>rustls::manual::_01_impl_vulnerabilities - Rust</title><link rel="stylesheet" type="text/css" href="../../../normalize.css"><link rel="stylesheet" type="text/css" href="../../../rustdoc.css" id="mainThemeStyle"><link rel="stylesheet" type="text/css" href="../../../light.css" id="themeStyle"><link rel="stylesheet" type="text/css" href="../../../dark.css" disabled ><link rel="stylesheet" type="text/css" href="../../../ayu.css" disabled ><script id="default-settings"></script><script src="../../../storage.js"></script><noscript><link rel="stylesheet" href="../../../noscript.css"></noscript><link rel="icon" type="image/svg+xml" href="../../../favicon.svg">
|
||
<link rel="alternate icon" type="image/png" href="../../../favicon-16x16.png">
|
||
<link rel="alternate icon" type="image/png" href="../../../favicon-32x32.png"><style type="text/css">#crate-search{background-image:url("../../../down-arrow.svg");}</style></head><body class="rustdoc mod"><!--[if lte IE 8]><div class="warning">This old browser is unsupported and will most likely display funky things.</div><![endif]--><nav class="sidebar"><div class="sidebar-menu">☰</div><a href='../../../rustls/index.html'><div class='logo-container rust-logo'><img src='../../../rust-logo.png' alt='logo'></div></a><p class="location">Module _01_impl_vulnerabilities</p><div class="sidebar-elems"><p class="location"><a href="../../index.html">rustls</a>::<wbr><a href="../index.html">manual</a></p><div id="sidebar-vars" data-name="_01_impl_vulnerabilities" data-ty="mod" data-relpath="../"></div><script defer src="../sidebar-items.js"></script></div></nav><div class="theme-picker"><button id="theme-picker" aria-label="Pick another theme!" aria-haspopup="menu"><img src="../../../brush.svg" width="18" alt="Pick another theme!"></button><div id="theme-choices" role="menu"></div></div><script src="../../../theme.js"></script><nav class="sub"><form class="search-form"><div class="search-container"><div><select id="crate-search"><option value="All crates">All crates</option></select><input class="search-input" name="search" disabled autocomplete="off" spellcheck="false" placeholder="Click or press ‘S’ to search, ‘?’ for more options…" type="search"></div><button type="button" class="help-button">?</button>
|
||
<a id="settings-menu" href="../../../settings.html"><img src="../../../wheel.svg" width="18" alt="Change settings"></a></div></form></nav><section id="main" class="content"><h1 class="fqn"><span class="in-band">Module <a href="../../index.html">rustls</a>::<wbr><a href="../index.html">manual</a>::<wbr><a class="mod" href="">_01_impl_vulnerabilities</a></span><span class="out-of-band"><span id="render-detail"><a id="toggle-all-docs" href="javascript:void(0)" title="collapse all docs">[<span class="inner">−</span>]</a></span><a class="srclink" href="../../../src/rustls/manual/implvulns.rs.html#1-104" title="goto source code">[src]</a></span></h1><div class="docblock"><p>This section discusses vulnerabilities in other TLS implementations, theorising their
|
||
root cause and how we aim to avoid them in rustls.</p>
|
||
<h1 id="a-review-of-tls-implementation-vulnerabilities" class="section-header"><a href="#a-review-of-tls-implementation-vulnerabilities">A review of TLS Implementation Vulnerabilities</a></h1>
|
||
<p>An important part of engineering involves studying and learning from the mistakes of the past.
|
||
It would be tremendously unfortunate to spend effort re-discovering and re-fixing the same
|
||
vulnerabilities that were discovered in the past.</p>
|
||
<h2 id="memory-safety" class="section-header"><a href="#memory-safety">Memory safety</a></h2>
|
||
<p>Being written entirely in the safe-subset of Rust immediately offers us freedom from the entire
|
||
class of memory safety vulnerabilities. There are too many to exhaustively list, and there will
|
||
certainly be more in the future.</p>
|
||
<p>Examples:</p>
|
||
<ul>
|
||
<li>Heartbleed <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160">CVE-2014-0160</a> (OpenSSL)</li>
|
||
<li>Memory corruption in ASN.1 decoder <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2108">CVE-2016-2108</a> (OpenSSL)</li>
|
||
<li>Buffer overflow in read_server_hello <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3466">CVE-2014-3466</a> (GnuTLS)</li>
|
||
</ul>
|
||
<h2 id="goto-fail" class="section-header"><a href="#goto-fail"><code>goto fail</code></a></h2>
|
||
<p>This is the name of a vulnerability in Apple Secure Transport <a href="https://nvd.nist.gov/vuln/detail/CVE-2014-1266">CVE-2014-1266</a>.
|
||
This boiled down to the following code, which validates the server's signature on the key exchange:</p>
|
||
<pre><code class="language-c"> if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
|
||
goto fail;
|
||
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
|
||
goto fail;
|
||
> goto fail;
|
||
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
|
||
goto fail;
|
||
</code></pre>
|
||
<p>The marked line was duplicated, likely accidentally during a merge. This meant
|
||
the remaining part of the function (including the actual signature validation)
|
||
was unconditionally skipped.</p>
|
||
<p>Ultimately the one countermeasure to this type of bug is basic testing: that a
|
||
valid signature returns success, and that an invalid one does not. rustls
|
||
has such testing, but this is really table stakes for security code.</p>
|
||
<p>Further than this, though, we could consider that the <em>lack</em> of an error from
|
||
this function is a poor indicator that the signature was valid. rustls, instead,
|
||
has zero-size and non-copyable types that indicate a particular signature validation
|
||
has been performed. These types can be thought of as <em>capabilities</em> originated only
|
||
by designated signature verification functions -- such functions can then be a focus
|
||
of manual code review. Like capabilities, values of these types are otherwise unforgeable,
|
||
and are communicable only by Rust's move semantics.</p>
|
||
<p>Values of these types are threaded through the protocol state machine, leading to terminal
|
||
states that look like:</p>
|
||
|
||
<div class='information'><div class='tooltip ignore'>ⓘ</div></div><div class="example-wrap"><pre class="rust rust-example-rendered ignore">
|
||
<span class="kw">struct</span> <span class="ident">ExpectTraffic</span> {
|
||
(...)
|
||
<span class="ident">_cert_verified</span>: <span class="ident">verify</span>::<span class="ident">ServerCertVerified</span>,
|
||
<span class="ident">_sig_verified</span>: <span class="ident">verify</span>::<span class="ident">HandshakeSignatureValid</span>,
|
||
<span class="ident">_fin_verified</span>: <span class="ident">verify</span>::<span class="ident">FinishedMessageVerified</span>,
|
||
}</pre></div>
|
||
<p>Since this state requires a value of these types, it will be a compile-time error to
|
||
reach that state without performing the requisite security-critical operations.</p>
|
||
<p>This approach is not infallible, but it has zero runtime cost.</p>
|
||
<h2 id="state-machine-attacks-earlyccs-and-smackskipfreak" class="section-header"><a href="#state-machine-attacks-earlyccs-and-smackskipfreak">State machine attacks: EarlyCCS and SMACK/SKIP/FREAK</a></h2>
|
||
<p>EarlyCCS <a href="https://nvd.nist.gov/vuln/detail/CVE-2014-0224">CVE-2014-0224</a> was a vulnerability in OpenSSL
|
||
found in 2014. The TLS <code>ChangeCipherSpec</code> message would be processed at inappropriate times, leading
|
||
to data being encrypted with the wrong keys (specifically, keys which were not secret). This resulted
|
||
from OpenSSL taking a <em>reactive</em> strategy to incoming messages ("when I get a message X, I should do Y")
|
||
which allows it to diverge from the proper state machine under attacker control.</p>
|
||
<p><a href="https://mitls.org/pages/attacks/SMACK">SMACK</a> is a similar suite of vulnerabilities found in JSSE,
|
||
CyaSSL, OpenSSL, Mono and axTLS. "SKIP-TLS" demonstrated that some implementations allowed handshake
|
||
messages (and in one case, the entire handshake!) to be skipped leading to breaks in security. "FREAK"
|
||
found that some implementations incorrectly allowed export-only state transitions (ie, transitions that
|
||
were only valid when an export ciphersuite was in use).</p>
|
||
<p>rustls represents its protocol state machine carefully to avoid these defects. We model the handshake,
|
||
CCS and application data subprotocols in the same single state machine. Each state in this machine is
|
||
represented with a single struct, and transitions are modelled as functions that consume the current state
|
||
plus one TLS message<sup id="fnref1"><a href="#fn1">1</a></sup> and return a struct representing the next state. These functions fully validate
|
||
the message type before further operations.</p>
|
||
<p>A sample sequence for a full TLSv1.2 handshake by a client looks like:</p>
|
||
<ul>
|
||
<li><code>hs::ExpectServerHello</code> (nb. ClientHello is logically sent before this state); transition to <code>tls12::ExpectCertificate</code></li>
|
||
<li><code>tls12::ExpectCertificate</code>; transition to <code>tls12::ExpectServerKX</code></li>
|
||
<li><code>tls12::ExpectServerKX</code>; transition to <code>tls12::ExpectServerDoneOrCertReq</code></li>
|
||
<li><code>tls12::ExpectServerDoneOrCertReq</code>; delegates to <code>tls12::ExpectCertificateRequest</code> or <code>tls12::ExpectServerDone</code> depending on incoming message.
|
||
<ul>
|
||
<li><code>tls12::ExpectServerDone</code>; transition to <code>tls12::ExpectCCS</code></li>
|
||
</ul>
|
||
</li>
|
||
<li><code>tls12::ExpectCCS</code>; transition to <code>tls12::ExpectFinished</code></li>
|
||
<li><code>tls12::ExpectFinished</code>; transition to <code>tls12::ExpectTraffic</code></li>
|
||
<li><code>tls12::ExpectTraffic</code>; terminal state; transitions to <code>tls12::ExpectTraffic</code></li>
|
||
</ul>
|
||
<p>In the future we plan to formally prove that all possible transitions modelled in this system of types
|
||
are correct with respect to the standard(s). At the moment we rely merely on exhaustive testing.</p>
|
||
<div class="footnotes"><hr><ol><li id="fn1"><p>a logical TLS message: post-decryption, post-fragmentation. <a href="#fnref1" rev="footnote">↩</a></p></li></ol></div></div></section><section id="search" class="content hidden"></section><section class="footer"></section><div id="rustdoc-vars" data-root-path="../../../" data-current-crate="rustls"></div>
|
||
<script src="../../../main.js"></script><script defer src="../../../search-index.js"></script></body></html> |