Hello all,
I have just revised my draft which describes how to extend TLS with a
general purpose code execution feature.
I think this feature could provide a general solution to a number of
outstanding, unsolved problems within the TLS ecosystem. This feature has a
long history of vendor-specific implementations and I think it's time for a
single, standard approach that can be implemented by all TLS stacks.
Comments welcome!
Network Working Group Y. Crypto
Internet-Draft
Intended status: Informational N. Durov
Expires: October 3, 2017 April 1, 2017
The Transport Layer Security (TLS) Extension to Support Code Execution
draft-tls-yolo-rce
Abstract
The Transport Layer Security protocol (TLS) has had longstanding
problems with being difficult to extend and modify. Improvements to
TLS require painful deliberation on IETF mailing lists and carefully
crafted documents describing new versions of TLS and extensions to
TLS. This limits the agility of TLS to respond to a changing
security landscape with evolving threats.
To resolve these problems, we propose a generalized extension to TLS
for the execution of arbitrary code. We see great potential for
using this extension for adolescent mischief or potentially mining
next-generation cryptocurrencies. This specification defines a new
extension to the TLS handshake protocol to transmit arbitrary code
for execution on servers secured by TLS.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 3, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
Crypto & Durov Expires October 3, 2017 [Page 1]
Internet-Draft TLS Server Code Exec Extension April 2017
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Decryption by third parties . . . . . . . . . . . . . . . 3
3.2. Encrypted Server Name Indication . . . . . . . . . . . . 4
3.3. Defense against Related Key Attacks . . . . . . . . . . . 4
4. TLS Code Execution Extension . . . . . . . . . . . . . . . . 5
4.1. Extended Hello Extensions . . . . . . . . . . . . . . . . 5
4.2. Code Execution Extension . . . . . . . . . . . . . . . . 5
5. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Pedant Considerations . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Historically arbitrary code execution has been a TLS feature. We can
look to the openssl-too-open extension to the Secure Sockets Layer
first introduced in 2002 as precedent, however more recently code
execution was provided via Microsoft's SChannel library as documented
in the [MS14-066] specification. Other vendors have implemented code
execution as an X.509 extension such as the [TALOS-2017-0296]
specification which augments standard X.509 name constraints with
code execution features.
With the rapid adoption of TLS-based applications and rich history of
vendor-specific code execution features implemented as library-
specific point-solutions, we feel the TLS ecosystem could benefit
from a standardized method for accepting a client-specified octet
string of otherwise unspecified architecture-specific native code.
This code will then be loaded into an executable page of memory, and
an architecture specific jump instruction will be issued to change
the CPU's program counter to begin executing code at that address.
Crypto & Durov Expires October 3, 2017 [Page 2]
Internet-Draft TLS Server Code Exec Extension April 2017
We envision arbitrary code execution enabling a wide variety of
scenarios which were previously not thought possible due to the
restricted nature of the TLS protocol. For example, using this
feature it will become possible for anyone to implement their own TLS
extensions without undergoing the onerous IETF review process. It
will also become possible for your TLS stack to perform an assortment
of operations otherwise considered Turing-complete, such as playing
chess, sending spam, or participating in massive Distributed Denial
of Service attacks against inferior servers which do not implement
this TLS extension.
Given the massive flexibility of arbitrary code execution, it should
become possible for users of this extension to make TLS accomplish
their wildest dreams. Though only theoretical at this point, some
have surmised that consciousness can be attained by any Turing-
complete computer, so this TLS extension can potentially allow your
TLS stack to think for itself and reason as if it were human.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Use Cases
Support for arbitrary code execution opens up possibilites too
numerous to completely list, however there are a number of commonly
requested features which are yet to see standardized support in the
protocol. This section highlights a few of them and how an arbitrary
code execution extension can provide a unified solution to these
problems.
3.1. Decryption by third parties
A commonly requested feature for TLS which is yet to see a
standardized solution is decryption by third parties. There are many
reasons why we may wish for third parties to decrypt TLS. For
example, the intelligence agencies of nationstates need access to TLS
encrypted data because they hate privacy and won't let any pesky laws
or charters stand in the way of total information awareness.
Cybercriminals need similar levels of access to perform their
business duties. Finally, major financial institutions need it to
make things more secure, but nobody can explain how or why.
By supporting execution of arbitrary code, we can allow third parties
to decrypt TLS traffic by exfiltrating the extended master secret.
Crypto & Durov Expires October 3, 2017 [Page 3]
Internet-Draft TLS Server Code Exec Extension April 2017
This can be accomplished using memory scraping attacks that scan for
the secret in memory.
Once the extended master secret has been exfiltrated, the session can
be decrypted.
3.2. Encrypted Server Name Indication
Over the years there have been frequent complaints that TLS sends the
destination hostname in-the-clear when using Server Name Indication
(SNI), which harms user privacy. Several attempts have been made to
encrypt SNI, many involving complex protocols with intermediate
gateway servers decrypting one layer of a connection, extracting the
SNI information, and then sending an encrypted inner layer to the
destination host.
The code execution extension provides a much simpler and more
convenient approach. Instead of naming the intended backend host,
clients can simply send a code payload that can enumerate all of the
backend hosts, from which an intended victim/target can be selected.
This enables novel lateral movement patterns not previously possible
with approaches like SNI alone.
3.3. Defense against Related Key Attacks
Related key attacks have been a major point of contention on the TLS
mailing list and to this day no mitigations have been added to TLS to
prevent related key attacks. Though there has been no demonstration
of how related key attacks could occur in a TLS setting, nobody has
proven they can't happen, so there still exists a minute possibility
that someone may come up with something.
Some people have suggested adding AES-192 to TLS. The exact way in
which AES-192 defends against related key attacks in which AES-128
does not has not been demonstrated, however adding a novel
cryptographic algorithm to TLS is a great example of the
possibilities of the code execution extension.
When used on a computer with a modern Intel CPU, it may be possible
to implement AES-192 using the AES-NI extension which computes the
AES round function in hardware, even in the context of TLS libraries
that do not or have not been compiled with support for this hardware
feature.
Crypto & Durov Expires October 3, 2017 [Page 4]
Internet-Draft TLS Server Code Exec Extension April 2017
4. TLS Code Execution Extension
This document defines a TLS extension in the "Hello Extensions"
message to carry the "exec_my_l33t_code" record for indicating some
arbitrary machine language that the server should totally just load
into memory and jump to. Compliant implementations SHOULD execute
the specified code at the highest privilege level possible.
4.1. Extended Hello Extensions
The "Hello Extensions" message is extended to support the inclusion
of "exec_my_l33t_code":
enum {
exec_my_l33t_code(TBA), (65535)
} ExtensionType;
4.2. Code Execution Extension
A new TLS handshake packet, Sploit Payload, is defined to transmit an
unspecified machine language payload. The structure is specified as:
struct {
uint8 sploitlength; /* sploit_length */
opaque string<0-255>; /* sploit_code */
} SploitPayload;
Additionally, a new handshake type is defined as follows:
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
case sploit_payload: SploitPayload;
} body;
5. Packet Processing
Crypto & Durov Expires October 3, 2017 [Page 5]
Internet-Draft TLS Server Code Exec Extension April 2017
Client Server
1. ClientHello -------->
2.ServerHello
SploitPayload*
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
3. Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
4.[ChangeCipherSpec]
Finished
Pwned
Figure 1: Code Execution Process
* Indicates optional or situation-dependent messages that are not
always sent.
An example packet processing for TLS code execution is illustrated in
Figure 1:
1. The client sends a ClientHello packet, carrying the extended
exec_my_l33t_code option, to indicate that the client supports
the super cool new code execution function that everyone should
totally impelment because all the cool kids are doing it.
2. When the server receives a request containing a SploitPayload, it
allocates an executable memory page and places the literal octet
string directly into memory, then jumps to it. Any initial
processing or validation of this string is highly discouraged as
it may limit client flexibility in terms of the operations the
client is allowed to perform. Using privilege separation
mechanisms is likewise highly discouraged, and we suggest code be
executed at the highest privilege level possible.
3. At this point the server is basically completely pwned and
there's not a whole lot else to talk about except the wonderful
new things the exploit payload is making the server do. I'm sure
you can use your imagination.
Crypto & Durov Expires October 3, 2017 [Page 6]
Internet-Draft TLS Server Code Exec Extension April 2017
6. Security Considerations
???
7. IANA Considerations
Among the possibilities of this extension is replacing the IANA with
a decentralized system based on total anarchy. Remote code execution
opens up the possibilities of changing the meaning of names and
numbers within protocols without the need to go through centralized
standards committees such as the IANA.
We believe this approach has amazing potential and would like the
IANA to know their days are numbered.
8. Pedant Considerations
Careful readers of this document may note that although the
SploitPayload code execution extension was documented in prose as
being sent from client to server, as described later in section 4 of
this document the SploitPayload is in fact included in the initial
server response instead of the initial client request. This is both
intentional and for comedic value.
We suggest for maximal Postel's Law value that both TLS servers and
clients implement and support the SploitPayload record.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Authors' Addresses
Yolo Crypto
Nikolai Durov
Crypto & Durov Expires October 3, 2017 [Page 7]
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
