Network Working Group Y. Crypto Internet-Draft N. Durov Intended status: Informational YOLO Cryptography, LLC. Expires: April 1, 2016 October 21, 2015 The Transport Layer Security (TLS) Extension to Support Code Execution draft-yolo-tls-server-code-exec-00 Abstract Despite the fact that TLS servers are the same no matter time nor place, to you all the kids all across the land, take it from me, in some applications TLS servers just don't understand. In these cases, the client request may need some special code to be executed on the operator's TLS server for things like authentication, overdrive processing, generalized adolescent mischief, or potentially mining next-generation cryptocurrencies. This specification defines a new extension of 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 April 1, 2016. Copyright Notice Copyright (c) 2015 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 October 2015 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 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 October 2015 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 October 2015 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 October 2015 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.