CRLF Examples

A CRLF is about as simple as vulnerabilities get!  CRLF stands for Carriage Return Line Feed, which is a term applied to new-line characters.  The attack involves injecting new-line characters in user-submitted data.

Very often web information is sent/received/stored in line-delimited format.  For example:

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: name=value
Accept: */*

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value

Return-Path: <fred@avolio.com>
...
Received: from [168.191.22.140] (helo=hub.avolio.com)
      by dfw-mmp1.email.verio.net with esmtp
      id 15a5m1-0003z3-00
      for fma@al.org; Fri, 24 Aug 2001 01:28:38 +0000
Received: from system1.avolio.com (system1.avolio.com [10.1.0.2])
      by hub.avolio.com with ESMTP id f7O1Sci13128
      for <fma@al.org>; Thu, 23 Aug 2001 21:28:39 -0400
Errors-to: <error@avolio.com>
Message-Id: <4.3.2.7.2.20010823212648.00b38850@hub1.avolio.com>
X-Sender: avolio@mail.veriomail.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 23 Aug 2001 21:27:04 -0400
To: fma@al.org
From: Frederick M Avolio <fred@avolio.com>
Sender: <admin@avolio.com>
In-Reply-To: <4.3.2.7.2.20010415150149.00b08080@mail.example.com>
Subject: test


CRLF and Email
Server-side code must be careful when generating output in line-delimited format.  For example, if your server-side code sets cookies or sends emails based on user-submitted data, it is possible that the data contains new-lines.  For example, if the string:

"This is a subject \nCC: spammed@example.com"

...is used as the Subject in an email, an attacker could cause your server to send spam.

Or, maybe your website allows visitors to order t-shirts online.  Every time someone orders a t-shirt, a little PHP script sends you an email.  A malicious user could get your script to send him a copy of the order, which might include sensitive information.  Worse, if a hacker knows what these order emails look like, he could then forge orders and maybe get free t-shirts.

CRLF and HTTP

Cleverly formed URLs can also cause problems if the web server or browser doesn't remove new-lines.  For example, the following URL can be typed into a browser and sent to a vulnerable web server:

"http://example.com/page.php HTTP/1.0\015\012Cookie: name=value"

The web server might interpret it like this:

GET /page.php HTTP/1.0
Cookie: name=value

...which means a seemingly harmless link (in an email or forum, for example) could change the cookies seen by the server.  Likewise, a server which echoes back cookies may be tricked into sending extra cookies.  For example, if your server is implemented like this:

print ("HTTP/1.1 200 OK")
for k,v in cookies do
    print ("Cookie:", k, " = ", v)
end

... then a client could send you a cookie with the value "blah \nCookie: loggedin=true".

Using safe libraries will help mitigate this problem.  For example, the PHP setcookie function URL-encodes the cookie value.  However, it is still possible to set HTML headers, email headers, etc manually through PHP or any other server-side language.

CRLF and Access Logs

Very often a web server will be configured to log all traffic for various reasons.  Some companies are required to log access and may be subpoenaed for them.  By sending a CRLF-injected GET request to a vulnerability web server, it may be possible to add fake entries to the access log (or any other log-like file):

"http://example.com/page.php?key=\015\01211.20.09 GET /fakepage.php"

This might cause the following two log entries:

11.20.09 GET /page.php
11.20.09 GET /fakepage.php

While seemingly harmless, keep in mind that access logs have been used in criminal court as evidence.
Comments