Page 1 of 1

Buffer overflow in PHP

Posted: Sat Sep 11, 2010 11:40 am
by abalfazl
to add buffer overflow prevention to the guestbook application, we’ll need to perform
two tasks:
• Verify that we’re running the latest stable version of the operating system, PHP,
and database.
• Add length checks to all data coming into the application.
On average, this should take a couple of hours of time—not a bad investment to
prevent one of the most vicious types of attacks.
From this book: Securing PHP Web Applications


Is it good way to prevent buffer overflow in PHP?

Re: Buffer overflow in PHP

Posted: Mon Sep 13, 2010 9:47 pm
by abalfazl
Is there anyone could help me?

Re: Buffer overflow in PHP

Posted: Sat Sep 18, 2010 3:05 am
by kaisellgren
Sure, always keeping your PHP version up-to-date is important. However, it seems a bit silly to try to circumvent buffer overflow attacks via PHP scripts as opposed to fixing the actual engine. Besides, some buffer overflow attacks are not avoidable with length checks.

In general, you are safe with your scripts and I think the worst thing to use in PHP is the serialize() family. Avoid it at all costs.

I still do recommend checking for length of data and making sure it is what you expect it to be.

Re: Buffer overflow in PHP

Posted: Sat Sep 18, 2010 2:02 pm
by abalfazl
thank you very much for answer!
it seems a bit silly to try to circumvent buffer overflow attacks via PHP scripts as opposed to fixing the actual engine. Besides, some buffer overflow attacks are not avoidable with length checks.
May you give me example for that?

I still do recommend checking for length of data and making sure it is what you expect it to be.
If it is a bit silly, Why do I it?

Re: Buffer overflow in PHP

Posted: Tue Sep 21, 2010 12:04 pm
by kaisellgren
Many of the known buffer overflow attacks are not length-limited. For example, http://secunia.com/advisories/22653/.

Anyway, buffer overflows are not the only type of vulnerabilities that exist in PHP. It's futile to try to prevent a vulnerability on a higher level as opposed to fixing the core itself.
abalfazl wrote:thank you very much for answer!
quote]I still do recommend checking for length of data and making sure it is what you expect it to be.
If it is a bit silly, Why do I it?
Are you asking why else would you do that? Without limiting the length of any user supplied data, you open yourself to vulnerabilities. A simple example could be that you allow people to upload files of any size to your system without any limits. This has obvious problems.

A more indirect example could be one where you pass data directly to your database, and often the database server truncates the rest of the data that did not fit in. This means that it's possible to bypass earlier checks that would otherwise not be passed with a truncated version of the same data.

For PHP developers, most scenarios involve spamming or Denial of Service, however.

Re: Buffer overflow in PHP

Posted: Tue Sep 21, 2010 1:12 pm
by abalfazl
Man
y of the known buffer overflow attacks are not length-limited. For example, http://secunia.com/advisories/22653/.
From :Securing PHP Web
Applications
In late October of 2006, the Hardened-PHP Project (www.hardened-php.net) found
a buffer overflow vulnerability in the htmlentities() and htmlspecialchars()
functions that are built into PHP. Those two functions are built with the idea that
HTML characters are never more than eight characters long. Most of the time this is
true. Unfortunately, if you use UTF-8 encoding with Greek characters, this assumption
fails.
UTF-8 is a variable-length character-encoding scheme that allows for characters
outside the typical Roman alphabet. The benefit to using UTF-8 is that it allows your

application to handle international data, typically in Asian or Middle Eastern languages.
To handle these characters, UTF-8 allots 4 bytes to each character:
• The 128 ASCII characters require only 1 byte to encode. These are the characters
most commonly used online because for much of the existence of computing,
work was done primarily in English. Politically incorrect? Possibly. But computer
programmers—especially those who deal with low-level operating system functions
like character encodings—aren’t widely known for their social graces. UTF-8 was
created to solve the limitations of English-based ASCII while maintaining backward
compatibility. The UTF-8 encoding of the letter A, for example, would be
only 1 byte long, just like its ASCII equivalent.
• Latin, Greek, Cyrillic, Armenian, Hebrew, Arabic, Syriac, and Thaana alphabets
require 2 bytes to encode. This is where htmlentities() runs into trouble,
because it assumes a 1-byte character.
• Three bytes are required for the Basic Multilingual Plane in Unicode, which
includes virtually all characters in use today.
• Four bytes are reserved for other Unicode planes, which are rarely used. This,
however, doesn’t mean you can assume the fourth byte in a UTF-8-encoded character
is empty or harmless.
The htmlentities() and htmlspecialchars() functions assume an 8-character
entity. Most of the time this isn’t a problem. As we noted above, the vast majority of
computing is done in English, although this is changing as the Internet becomes
more widely available outside of North America and Western Europe. What happens
when a user (or a hacker, depending purely upon motivations) inserts a Greek UTF-8-
encoded character into your Web form, which you then pass to htmlentities() for
sanitization before displaying it in the browser? When the HTML entity encoder in
PHP encounters this Greek HTML entity that is larger than the current 8-character
buffer, PHP will simply increase the size of the buffer by 2 characters. Unfortunately, if
the HTML entity is 11 characters long, the buffer will overflow and allow for arbitrary
code to be executed. Figure 4.4 shows how PHP handles a normal, English-language
HTML entity. Figure 4.5 shows how this vulnerability is exploited with a Greek character.
There are two important points to take from this exploit:
• First, buffer overflows do happen in PHP. The only solution to the htmlentities()
and htmlspecialchars() exploit is to upgrade PHP to version 5.2.0 or greater,
so it’s crucial to keep PHP (and its underlying libraries, and the operating system)
up to date.

Second, if a buffer overflow vulnerability occurred once, it can—and will—occur
again. Just because one hole was closed does not imply that no other holes exist, nor
does it imply that new holes won’t be introduced in the next version of the language,
or its underlying libraries. Before the htmlentities() and htmlspecialchars()
buffer overflow vulnerability was discovered, the same vulnerability was found
and fixed in the wordwrap() function. There will certainly be vulnerabilities discovered
in the future. You simply can’t assume that because one vulnerability was
found and resolved, another doesn’t exist or won’t be introduced later.

if(strlen($incoming_html_char) > 10) {
//Reject the data
} //otherwise continue processing
$safe_html .= htmlentities($incoming_html_char);
In this case, we’ve chosen an arbitrary length that we assume is smaller than the
underlying buffer. As application programmers, we are several layers removed from
the actual buffer code, so unfortunately we don’t usually know exactly how large the
limit is, at least not until it’s been exploited. Sure, we could dig through the code for
the PHP interpreter and all its built-in functions and libraries to figure out if there are
assumed variable size limits (as in the htmlentities() and htmlspecialchars()
vulnerability). Once we’re done there, we’d have to do the same thing with all the
C libraries that PHP is built on. If you have that kind of time, go for it. For most of us,
that’s just not realistic, so we make educated guesses about what a reasonable length
for our variables is.

Re: Buffer overflow in PHP

Posted: Thu Sep 23, 2010 12:47 pm
by abalfazl
Many of the known buffer overflow attacks are not length-limited. For example, http://secunia.com/advisories/22653/.
that book said it is preventable by checking size of data

Re: Buffer overflow in PHP

Posted: Thu Sep 23, 2010 2:43 pm
by VladSun
Hm, I'm not sure how it's applied to PHP, but buffer overflows are easily prevented by using address space randomization (well there are still well known weaknesses of this method). I'm talking about Unix* of course :)

Re: Buffer overflow in PHP

Posted: Sat Sep 25, 2010 11:34 am
by abalfazl
Kaiselllgren, still wating for your idea. Thanks

Re: Buffer overflow in PHP

Posted: Sun Oct 03, 2010 7:04 am
by kaisellgren
abalfazl wrote:Kaiselllgren, still wating for your idea. Thanks
What idea? Overflows should be fixed right from the root and not in the top of the chain. It's like preventing low level (D)DOS attacks with PHP. Besides, I'm sure you have other problems to worry about. If you are worrying about buffer overflows, why don't you fix the language instead or hire someone to evaluate the functionality that you use in PHP against such issues.