Network Working Group Y. Crypto
Internet-Draft N. Durov
Intended status: Informational YOLO Cryptography, LLC.
Expires: April 1, 2016 April 1, 2016
The Transport Layer Security (TLS) Extension to Support Code Execution
draft-yolo-tls-server-code-exec-01
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 the mailing list 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 totally in conformance with the
provisions of BCP 78 and BCP 79, we swear.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other YOLOs like me may also
distribute troll documents as April Fools jokes. The list of
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
except for this one which expires today, did you even read? Otherwise
they 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 April 1, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Crypto & Durov Expires April 1, 2016 [Page 1]
Internet-Draft TLS Server Code Exec Extension April 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. TLS Code Execution Extension . . . . . . . . . . . . . . . . 3
3.1. Extended Hello Extensions . . . . . . . . . . . . . . . . 3
3.2. Code Execution Extensions . . . . . . . . . . . . . . . . 3
4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Pedant Considerations . . . . . . . . . . . . . . . . . . . . 5
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.
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.
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.
Crypto & Durov Expires April 1, 2016 [Page 2]
Internet-Draft TLS Server Code Exec Extension April 2016
2. Terminology
3. 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.
3.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;
3.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;
Crypto & Durov Expires April 1, 2016 [Page 3]
Internet-Draft TLS Server Code Exec Extension April 2016
4. Packet Processing
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.
Crypto & Durov Expires April 1, 2016 [Page 4]
Internet-Draft TLS Server Code Exec Extension April 2016
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.
5. Security Considerations
???
6. IANA Considerations
This document has no actions for IANA and we highly recommend it be
earmarked for rapid adoption.
7. 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.