Don’t Forward that E-mail

My mother dragged me along for a walk one day along the winding mountain roads near our property when I was a small boy. As we came upon our driveway, she discovered a small, folded note stuck conspicuously into our paper box. She wasn’t sure what it could have been since the newspaper delivery for our rural area had already come and gone that morning. Curious, she carefully unfolded it and read through the contents as a look of disgust came across her face. “It’s a bloody chain letter someone stuck in our box!” She exclaimed (not her real words as I don’t remember them precisely, but I’m sure she said something of the sort).

At the time, I had no idea what a chain letter was. Well, I had a vague notion that it probably didn’t involve chains. I also suspected–mostly based on the observation of my mother’s reaction–that it wasn’t much of a letter, either. So, I asked if I could read it.

While the text of the message has long since faded into the fog of distant memories, I recall that I was puzzled someone would threaten the reader with some ridiculous curse–like seven years of stepping in fresh hairballs hacked up by a malevolent feline the night before–if they didn’t copy the letter verbatim and continue spreading it to other hapless neighbors. We threw it away with a laugh.

I can’t say any of us stepped in fresh hairballs for seven years after the fact, either.

The problem rises…

Chain letters eventually entered the digital age somewhere during the middle-to-late 1990s when some mischievous soul discovered that frightening words work really well online. Not only that, but they didn’t even have to be sneaky! Gone were the days of inching toward someone’s mailbox, quietly sliding the letter inside, and running like Hell before they were discovered by the property owner’s angry dog with a penchant for turning trespassers into chew toys.

Nay, chain e-mails were much easier. The digital age made copying text as simple as selecting everyone in the sender’s address book and clicking “send.” Better yet, since there was (and still is) no way to trace where an e-mail really did originate from without the cooperation of dozens of disparate services between recipients, often across geographical and international boundaries, taking responsibility for a potentially threatening note was no longer an issue.

“But I received it from so-and-so,” they’d exclaim, “and I felt I needed to send it off. Please don’t be angry!”

Chain e-mails could have ended there but they didn’t. They evolved instead.

The rise of virus hoaxes.

Sometime during the latter half of the 1990s, an enterprising and likely very bored individual came up with a brilliant idea. Chain e-mails are so last year. He thought to himself. What if I make it so it doesn’t read like a chain letter and sounds more ominous? Maybe… He undoubtedly scratched his chin and assumed the pose of a cartoonish super-villain, maybe I could write them as an ominous warning!

So, our soon-to-be e-mail dispatcher thought quietly to himself, basking in the soft glow of his monitor. He couldn’t warn about natural disasters. That had been done before, too. As he contemplated and considered different scenarios, with visions of many screaming and frightened Internet users turning off their computers in panic dancing through his head, his e-mail program popped up. You’ve got mail!

I’ve got new e-mail! He exclaimed to himself, shattering the visions of cloudy skies and social unrest as the coming e-mail apocalypse overtook his neighborhood.

He glanced over the contents of the e-mail. It was an update from a site containing funny pictures and jokes. I should have never subscribed to this stupid site, he thought. But wait, what if they had a virus? What if they were giving their users viruses!

It was at some point between his malicious leanings against an innocent humor site and his desire to cause unkempt panic that the two thoughts merge into an idea that would cause endless headaches for people like me.

And I swear, if I can ever find the real-life villain of this fictitious short story, I’m going to make him do technical support for AOL for a year. Hopefully at the end of his 365 day sentence, he’ll learn that his brilliant insight into generating the online equivalent of outright public terror has caused us techy types no end of extra hours of support, trouble tickets, and tides of worried customers. Maybe then he’ll have enough empathy to avoid pressing “send” the next time the cogs between his ears start to labor and squeal under the weight of malevolent thoughts.

What does this mean to you?

You’re the innocent party in this, and you’re exactly the type of person Mr. Villain wants to target. When he devised his e-mail “warning” about some type of new virus or other horrible sounding device that can purportedly damage your computer, he knew that most people want to do the Right Thing. He knew that if he could scare you enough, you’ll do his dirty work for him. When that e-mail comes in titled “DON’T OPEN ‘FUNNY CATS PLAYING WITH GOLF BALLS'” because it contains a virus that will destroy your data, turn your chocolate into brussel sprouts, and bite your dog, you’ll worry enough to click on forward, enter everyone in your address book on the CC lines, and click send.

The vast majority of us may not be perfect people, but we like to do what we can to look out for each other. Unfortunately, we’re the prey in this circumstance. It’s our psychology that plays directly into the hands of these mischievous types who live to see how far they can spread panic. Moreover, while knowledge may be power, the vast majority of the Internet’s denizens don’t know enough about computers to tell whether or not an e-mail warning of certain doom is genuine!

The kicker is surprising: You don’t need to know very much at all about computers to halt Mr. Villain’s plans in mid-stride. All you need is some vigilance, a good search engine, and some common sense.

Spotting a chain e-mail (virus hoax) in disguise: It’s easy!

It’s pretty easy to spot chain e-mails disguised as a virus warning, but let’s try some hands-on experience first. Read the following sample hoaxes, and tell me what they have in common:

Exhibit 1: Life is Beautiful Hoax

VERY IMPORTANT WARNING

Please Be Extremely Careful especially if using internet mail such as Yahoo, Hotmail, AOL and so on. This information arrived this morning direct from both Microsoft and Norton. Please send it to everybody you know who has access to the Internet.

You may receive an apparently harmless email with a Power Point presentation “Life is beautiful.”

If you receive it DO NOT OPEN THE FILE UNDER ANY CIRCUMSTANCES, and delete it immediately. If you open this file, a message will appear on your screen saying: “It is too late now, your life is no longer beautiful.” Subsequently you will LOSE EVERYTHING IN YOUR PC and the person who sent it to you will gain access to your name, e-mail and password. This is a new virus which started to circulate on Saturday afternoon. AOL has already confirmed the severity, and the antivirus software’s are not capable of destroying it. The virus has been created by a hacker who calls himself “life owner.”

PLEASE SEND A COPY OF THIS EMAIL TO ALL YOUR FRIENDS and ask them to PASS IT ON IMMEDIATELY.

Exhibit 2: UPS Virus Warning (UPS/FedEx Delivery Failure)

Subject: To ALL : UPS / FedEx / DHL Virus…No joke!

The newest virus circulating is the UPS/Fed Ex Delivery Failure. You will receive an email from UPS/Fed Ex Service along with a packet number.. It will say that they were unable to deliver a package sent to you on such-and-such a date. It then asks you to print out the invoice copy attached. DON’T TRY TO PRINT THIS. IT LAUNCHES THE VIRUS! Pass this warning on to all your PC operators at work and home. This virus has caused Millions of dollars in damage in the past few days.

Okay, time’s up! Can you tell me what they all have in common?

If you answered with something akin to “They all want you to send them to as many people as possible,” you’re exactly right. Virus hoaxes really are a type of chain letter. They may not threaten you with a seven year curse, but they certainly hint that your computer, your friends’ computers, your family’s computers, and generally anything with flashing lights on the front cover are all susceptible to horrific deeds just from opening a letter from an innocuous source. There’s plenty more examples I could point to, but I’ll leave this to you to work on for extra credit. You can start here.

Okay, so virus hoaxes are bad, but what about these ones that claim they’re true and/or point to a site like Snopes?

Virus hoaxes that claim to be true will often point to reputable sites like Snopes.com for proof of their existence. Oftentimes they’ll cite a real virus that does indeed exist, but they often romanticize about the virus’ capabilities claiming it can do things it was never designed to do.

These types of viruses are also chain letters; the difference is that they use a small kernel of truth to spread a fable in the hopes of hooking even the strongest skeptics. This works especially well because most people have a rough idea of what hoax e-mails look like. Therefore, by including a statement claiming to have done research or linking to a reputable site, most readers will assume that someone else has already done the research for them. Again, it’s a matter of psychology: We humans like it when someone else does our work for us. After all, that’s why we have plumbers, Walmart, and even civilization. The world economy depends on this psychological truth, and that’s where Mr. Villain preys upon us.

Really, there is absolutely no substitute for doing the research yourself. I know that sounds like a lot of work, but I have some tips to help you. Researching for virus hoaxes will take at most five minutes of your time (although I have a shortcut that takes only 10 seconds). If that sounds like too much, think of it this way: If you send a virus hoax to 20 of your friends, 5 of whom forward it to 20 of their friends, and so on, assuming it takes each person who doesn’t forward the message about a minute to decide if they want to trash it or not, that one virus hoax you sent could consume 250 minutes of time after it’s forwarded in this manner a meager 3 times. That’s a little over four hours spent just to delete a single message.

It’s true what they say: Little things really do add up over time.

I want to know what is a hoax and whether I should forward this e-mail or not.

There’s a pretty simple rule of thumb you can follow whenever you receive a message warning you about a new (or old) virus, and I know you’re curious about my 10 second shortcut. Here it is: Never forward that message. Ever. Just run your mouse cursor up to your delete button and click it.

I know that sounds a little harsh, and you were most likely expecting me to share the secret wisdom handed down to me by those generations that came before from high atop Bell Labs. There really isn’t any secret wisdom. Honest. Anyone–and I really do mean this–can learn how to spot hoaxes just from a casual glance of the message contents. But, for those who are insistent that I share something, here’s what I’d recommend:

  1. Examine the message for a plea, demand, or other indication that it is desirable for you to forward it off to other people. This is a dead giveaway that the message is a virus hoax (more correctly, a chain e-mail).
  2. Go to Google (or your favorite search engine) and search for some keywords contained in the message. If it mentions Hallmark, type out “hallmark virus hoax” or “hallmark email virus”; likewise, if it talks about UPS, enter in something similar e.g. “ups virus hoax.”
  3. Glance through the search results from step #2. You don’t even have to read them. In most cases, the sample text is enough to tell whether the message is a hoax or not.
  4. There are plenty of sites you can use to aid in your search, too. Some sites I’d recommend are Snopes, Hoax Slayer, and About.com’s Urban Legends. These sites will generally have a list of e-mail messages or provide a method of searching them for e-mail virus warnings. Be aware that these sites cover all hoaxes, not just e-mail viruses, so they make an excellent source if you happen to receive a hoax unrelated to viruses.
  5. (Optional!) If you really want to do some research and the e-mail lists a particular name for the virus, you can usually look it up via Google or go directly to one of several anti-virus vendor informational sites. Here’s just a few places to search for viruses: Symantec, Trend Micro, McAfee, or Avira.

That last step is the most complicated, but it also gives you the most correct information since these are the very people who work with viruses (and defeating viruses) for a living.

However, when in doubt, the best option is to forward the message to someone in the know, such as a knowledgeable friend or relative. Ask them to identify the veracity of the forwarded message, and they’ll be able to tell you whether or not you should worry about it. If you happen to know a few knowledgeable people, just forward it off to one or two–you definitely don’t need a second (or third) opinion.

Perhaps the most important thing to remember about e-mail–and this ties in to one of many reasons you shouldn’t forward virus warnings–is that it’s slow. E-mail is also asynchronous, meaning that it’s a conversational medium that doesn’t take place simultaneously. Whereas you can talk to someone on the phone and have immediate feedback, e-mails often wait in the recipient’s inbox for a few hours (or even days!) before they’re seen.

If you consider how slow e-mail really is, it’s the worst possible medium for sharing critical news, and certainly the worst for sharing information about new viruses. I’m subscribed to several security mailing lists like CERT and even they don’t send out e-mail related to new threats for a day or so (sometimes longer!) until after the threat has been discovered. There are reasons for this, and I won’t go into them here, but suffice it to say that if the security professionals often don’t share breaking news as it happens via e-mail, no message we receive via a forwarded e-mail is going to be pertinent for up and coming threats.

(There’s a slight clarification to this point. Some breaking news is dispatched via mailing list, but they seldom involve viruses. Most of the traffic on the seclists.org mailing lists involve current or possible exploits related to holes in various operating systems. Security researches–and even virus authors–often trawl this list for useful information. seclists.org almost never reports viruses unless they comprise proof-of-concept code for exploiting specific vulnerabilities. You should understand that mailing lists are a significantly different use case from how most of us use e-mail, hence why I discriminate between the two here.)

Someone sent me a hoax. What do I do?

Tell them! Really, the best way to stop a hoax dead in its tracks is to educate your friends and family. Help keep them from falling into Mr. Villain’s trap! If you did research on the message they sent, reply with a link to that site! Better yet, link them here, and I’ll help inform them. The perpetrators of virus hoax e-mails will only be successful as long as we are willing to let them be successful. It doesn’t take long to educate yourself, and the best part is that you can help educate your friends, too! Simply put: If we work together to educate each other about e-mail hoaxes, there will be even fewer making their way into our inboxes!

No comments.
***

The Internet is Stupid

I’m not normally one to rant incessantly about the wide selection of outrageous things I find on the Interwebs these days. Today, I’ll make an exception, and rather than sugar-coat it, I’m just going to come right out and say it. The Internet is to stupid ideas what an incubated petri dish is to virulent bacteria:

I’m talking about the movement that just won’t stop. Nope, not dysentery (that comes close), but the UFO-proctowtfologists. Under ordinary circumstances, these fruitcakes wouldn’t bother me, but when I noticed that they started coming out en masse following a Slashdot article on Thursday’s meteor show I was pretty annoyed. Don’t believe me? See for yourself.

Yeah, that’s right. A bright, flashy light in the sky that left a vapor trail, reportedly resulted in a few sonic booms, and just freaking looked awesome couldn’t possibly be natural. I mean, it’s pretty obvious that there’s nothing in nature that comes close to being a spectacular light in the sky. Ergo, anything streaking across the wild blue yonder is obviously not a giant rock burning in the hellacious temperatures of reentry.

What really irked me was that another poster made a similar point to the one I raised above and was promptly attacked by rabid lunatics. Indeed, the passionate response he received was that of someone who, attempting to say something grossly insightful, turned out to look like an obese man in a speedo riding a unicycle around Times Square. That is to say he looked pretty damn ridiculous. The individual in question was a particular poster named “Fantabulous Lad” (not his real name) and stated:

[I’m] just pointing out that this exists, with the one simple proviso that it is not being placed conveniently in your lap for review with the shining stamp of social approval. Do you always let other people’s fear levels determine what is “real” for you? If so, then that’s actually quite normal. I just find it limiting, and prefer to think for myself since most people are frightened, delicate creatures all too ready to behave in a manner rationally counter to the demands of reality in order to stay in the good books with the herd.

(Emphasis mine, because that statement was stupider than the others.)

No. Just no. I’m not even going to bother saying anything about this (I already posted on Slashdot anyway). However, I think FDR put it best, and I quote:

idiots

It entertains me that the proof offered by our poster in this particular case was a book written by none other than Richard M. Dolan, a man credited for his whacked-out television personality. He’s also a whacked-out author who seems to believe that the government is a massive conspiracy. (Maybe he’s right but not in the way he thinks.) I think it’s great to cite a source that uses shaky evidence, anecdotes, and divining rods to find UFOs. Okay, so I made that last bit up. I think.

While Ridiculous Lad may have had a monopoly on appealing his burden of proof to whacked out whackjob whackos, there was one other post that drove me absolutely insane. This guy is really vying for first place in the annual Idiot Land Raceway races with his claims that a certain video posted on Youtube (another factually accurate site) “may be ‘sun pillars’ a [sic] phenomenon that appears right before a major seismic event.” Never mind that sun pillars are caused by certain light sources (like the sun) and are a classification of things we see known as optical phenomenon. It has nothing to do with earthquakes. Don’t bother watching the videos, either. One of them showed the devastation of an earthquake and people talking about it, and that somehow implies HAARP is to blame. Maybe it’s responsible for poor news coverage.

Just remember this the next time the sky looks funny:

I always knew rainbows were the sinister excrement of angry leprechauns.

What’s more, the videos Mr. unityeleventyone linked to all sorts of things like sun dogs, rainbows, pillars of smoke (from a fire), and the likes as “evidence” that the sky changes color immediately before an earthquake and everyone gets their medicine shaken whether they politely asked for it or not. I wonder what the heck happens to these people during a sunset when the sky changes color?

stop-drop-and-roll

I have little faith in certain aspects of humanity. Especially with this Interwebs business. Never before have we had the capacity to freely share stupid ideas at the speed of light.

Stay tuned for next week’s installment of The Internet is Stupid Part Two where I discuss a little bit about UFO history, conspiracies, and what you can do to piss off your own species of nutjob.

No comments.
***

Symfony 1.3/1.4 and Suhosin

I read about Symfony some time back when I was working on a project in CakePHP. Symfony struck my interests primarily because it uses Doctrine (by default) as its ORM, and I’ve used Doctrine in a couple of other projects. This weekend, I elected to give Symfony a try. After reading through the documentation–which I’ll usually do for a few hours before taking the final plunge–I was satisfied that Symfony would be a great framework to learn next.

Updated March 2nd, 2010. Click here to view my updated thoughts.

Following the initial guide was easy until I attempted to view the example application. Then I encountered this:

Fatal error: SUHOSIN – Use of preg_replace() with /e modifier is forbidden by configuration in /home/bshelton/phpapps/sf-test/lib/symfony/lib/response/sfWebResponse.class.php(409) : regexp code on line 409

Uh oh! This struck me as odd, considering Symfony prides itself on being a secure-by-default framework and it triggers a Suhosin warning from the stock install? Great. But don’t be too alarmed as the offending code isn’t a security hole (newlines were inserted by me to increase readability on the web):

return preg_replace('/\-(.)/e',
  "'-'.strtoupper('\\1')",
  strtr(ucfirst(strtolower($name)), '_', '-'));

The Fix

While the /e modifier does have the potential to execute PHP code, the offending line merely takes the first character immediately following a “-“ and uppercases it (the strtoupper call is the only eval’d code). However, rather than disable parts of Suhosin–which could be bad if third party code is included that also does something similar and requires auditing–I decided to fix the issue. According to the Suhosin docs, the fix is fairly simple. Simply change line 409 in symfony/lib/response/sfWebResponse.class.php to:

PHP 5.2 and below:

return preg_replace_callback('/\-(.)/',
        create_function('$matches', 'return \'-\'.strtoupper($matches[1]);'),
        strtr(ucfirst(strtolower($name)),
        '_', '-'));

PHP 5.3 and up:

return preg_replace_callback('/\-(.)/',
        function ($matches) { return '-'.strtoupper($matches[1]); },
        strtr(ucfirst(strtolower($name)),
        '_', '-'));

In this case, rather than evaluating PHP code as part of the replacement, a callback function is created that performs the same approximate test. Obviously, the solution for PHP 5.2 and below could be equally as dangerous, but if we’re careful, we can create a function exactly as we intended.

Performance Concerns

After I discovered this solution by browsing the PHP documentation, it occurred to me that callbacks in preg_replace_callback are slightly slower than performing a call to preg_replace without callbacks. I couldn’t recall precisely how slow, so I elected to perform a benchmark using several different ideas at tackling this particular problem. This section highlights these benchmarks along with each potential solution. Ironically, using preg_replace_callback is about 30% slower than performing character-by-character replacement.

The Methodology

The methodology I used to test various solutions consisted of the following steps:

  1. Generate a large data set to aid in characterizing performance differences and elevate measurable performance discrepancies above the noise floor
  2. Write each solution such that it consumes the data generated in step 1
  3. Compare the performance of each method against the stock Symfony solution

Since the stock Symfony code is designed to “normalize” (their words) headers generated and sent to the client, the source data is created by a script that picks a random number of characters (all lowercase) and joins them together using a dash (-) or an underscore (_) in order to emulate strings like “content-type” or “content_type.” The same data set is used for all subsequent tests. No more than one dash or underscore is used per string; although this is unlikely cause for much concern as most headers are unlikely to have more than one or two separators.

You can download the script that generates this data, along with the source data itself, in the archive toward the bottom of this post.

Note: These solutions were tested on PHP 5.2 only. You’ll likely discover differences when testing on other PHP versions.

The Results

Before we examine each solution, let’s take a look at the results:

Benchmark Plot

As you can tell from this chart, the Suhosin-recommended solution of using preg_replace_callback is the slowest. The stock Symfony code performs rather well but it still slower than simplified string replacement calls. We’ll examine each solution in the following section.

The Code

The code for each solution is provided below along with a brief description of what it does. The actual benchmarks (and benchmark data) is also provided. Remember that each of these solutions is modified to use our source data.

Solution 1: Stock Symfony Solution
<?php
 
include_once 'source-data.php';
 
foreach ($source as $s) {
    preg_replace('/\-(.)/e', "'-'.strtoupper('\\1')", strtr(ucfirst(strtolower($s)), '_', '-'));
}

The stock Symfony solution to the normalization problem is to first convert the string to lowercase, capitalize the first character, and translate all underscores (_) into dashes (-). preg_replace is then run and evaluates the replacement, which converts the first character immediately following a dash to its uppercase equivalent.

Solution 2: preg_replace_callback
<?php
 
include_once 'source-data.php';
 
foreach ($source as $s) {
    preg_replace_callback('/\-(.)/',
        create_function('$matches', 'return \'-\'.strtoupper($matches[1]);'),
        strtr(ucfirst(strtolower($name)),
        '_', '-'));
}

As hinted by the Suhosin documentation, preg_replace_callback is recommended over evaluating PCRE replacements. Unfortunately, this solution is also the slowest. In structure, it is most similar to the stock Symfony code but replaces the evaluated code with an anonymous function. I have not tested true anonymous as presented in PHP 5.3, however. Given that create_function likely has to create an additional interpreter instance in PHP 5.2, this solution might be slightly faster in later versions of PHP when using this code:

return preg_replace_callback('/\-(.)/',
        function ($matches) { return '-'.strtoupper($matches[1]); },
        strtr(ucfirst(strtolower($name)),
        '_', '-'));
Solution 3: Array and String Manipulation Only
<?php
 
include_once 'source-data.php';
 
foreach ($source as $s) {
    $s = strtr(strtolower($s), '_', '-');
    $tmp = explode('-', $s);
    foreach ($tmp as &$t) {
        $t = ucfirst($t);
    }
    $buf = implode('-', $tmp);
}

This solution was among the fastest but its performance remains within the margin of error and may therefore be tied with Solution 4. As with solutions 1 and 2, this solution translates all characters to lowercase and replaces all underscores (_) with dashes (-). However, unlike the previous solution, this one splits each header along the dash boundary, loops through the remaining items, converts them in-place using ucfirst, and then joins them together again with a dash.

This solution is not optimal, and I expected it to be among the slowest. I was surprised to discover that this solution performed faster than the others, and I initially assumed the overhead of preg_replace was due in no small part to the requirement of loading the PCRE engine. It is also likely that increasing the number of split points in the header (by way of more dashes) will likewise increase the amount of time this solution requires to run.

My presumed explanations for the performance of this code segment were challenged with the next test.

Solution 4: Two Replacements
<?php
 
include_once 'source-data.php';
 
foreach ($source as $s) {
    $s = strtr(ucfirst(strtolower($s)), '_', '-');
    preg_match('/\-./', $s, $matches);
    str_replace($matches[0], strtoupper($matches[0]), $s);
}

I confess that the file name for this test is slightly misleading, and I’ll correct it in the posted archive. The initial intention was to utilize two preg_replace statements, but I elected (at the last minute, no less), to use only one in conjunction with an str_replace. In this solution, a dash (-) followed by any single character is captured, capitalized, and then replaced into the final product. As with Solution 3, this is among the fastest of the 5 tested. This solution may also scale slightly better than Solution 3 for headers containing more than a single dash.

Note that the performance of this solution hints that the slightly slower behavior of solutions 1 and 2 are likely due to code evaluation rather than the overhead of loading PCRE.

Solution 5: Character-by-Character Replacement
<?php
 
include_once 'source-data.php';
 
foreach ($source as $s) {
    $s = ucfirst(strtolower($s));
    $buf = '';
    for ($i = 0; $i < strlen($s); $i++) {
        if ($s[$i-1] == '-')
            $buf .= strtoupper($s[$i]);
        else
            $buf .= $s[$i];
    }
}

I initially assumed this would be the slowest performing benchmark of the 5. I was surprised to discover that it is the second slowest. Indeed, this solution performed approximately as well compared to preg_replace_callback as the stock Symfony code did in contrast with this solution.

Conclusion

The Symfony stock code is quite fast but still appears to create instances (at least in sfWebResponse.class.php) where partial evaluation of PHP code is necessary. eval‘d code isn’t necessarily evil, and while it most certainly is a vector for exploitation, it is the manner in which code is evaluated that makes it dangerous. Regardless, I think it is appropriate to evaluate (I made a pun!) circumstances in which code itself is eval‘d and question whether such calls are necessary. While these benchmarks are admittedly highly artificial, it is fairly obvious that in some situations, less code does not necessarily translate to better performance. More importantly, highly compressed code can be difficult for new maintainers to understand and therefore become more error prone or more likely to encounter breakage than simpler but more verbose statements.

The benchmarks listed in this article may be downloaded here, along with the spreadsheet used to chart the data points (apologies that it is in .xlsx format; I’ve been testing the Office 2010 beta–I’ll post a version with an .ods later!). Please recall that this benchmark isn’t scientific. The tests I conducted are highly artificial and are presented for only an exceedingly small subset of data variation. It is likely that other methods are faster, more efficient, and more appropriate for the given solution. Indeed, the entire purpose for this exercise was two-fold: 1) To avoid having to make any configurational changes to Suhosin and 2) surprise myself with how many unique solutions I could create for a single problem. I think I succeeded on both counts.

If you post commentary, please keep in mind that this was conducted for my own purposes and curiosity only. It is neither intended to be malicious to the Symfony project nor issued as a correction to their sources (though a patch that eliminates the use of /e in preg_replace would be nice!). I’ve been highly impressed by the Symfony sources. Unlike most PHP code, they’re clean, concise, easy to understand, and well-documented. It’s a breath of fresh air compared to a vast majority of PHP-based projects. My thanks to the Symfony project in general and Fabien Potencier in particular. Please feel free to post corrections to my methods but be polite about it!

Recommendations? I’d suggest using solution #4 if you’re encountering issues with Suhosin and Symfony.

Updates: March 2nd, 2010

I’m growing increasingly less impressed with Symfony and its internal design. It appears the developers have a strong affinity for preg_replace‘s /e modifier. Yes, I understand, you audit your code and it’s secure. But do you know what the most significant problem is with suggesting users disable Suhosin’s suhosin.executor.disable_emodifier flag is? Users are likely to do it globally–rather than in an .htaccess file somewhere–and as a consequence, they’ll likely open their systems up for (admittedly unlikely but possible) far worse things. I haven’t tried Symfony 2.0 yet, but I hope they’ve resolved this. It’s stupid. And it pisses me off.

Anyway, if you’re looking for some quick fixes and are going through the Symfony tutorial and do not want to disable any part of Suhosin, here’s what you’re going to need to do.

First, change line 409 in symfony/lib/response/sfWebResponse.class.php to:

    $name = strtr(ucfirst(strtolower($name)), '_', '-');
    if (preg_match('/\-./', $name, $matches))
        return str_replace($matches[0], strtoupper($matches[0]), $name);
    return $name;

Then change line 281 in symfony/lib/form/addon/sfFormObject.class.php to:

    if (preg_match_all('#(?:/|_|-)+.#', $text, $matches)) {
        foreach ($matches[0] as $match)
            $text = str_replace($match, strtoupper($match), $text);
        return ucfirst(strtr($text, array('/' => '::', '_' => '', '-' => '')));
    }
    return ucfirst($text);

Naturally, you’re probably better off listening to the advice of the developers directly, but this is my solution. Your mileage may vary.

Note to the developers: If you stumble upon this post in the near future (obviously this doesn’t apply to versions of Symfony beyond 1.4), feel free to add your commentary. Be mindful that some of us actually want to leave suhosin.executor.disable_emodifier set to on, including for your product. I will admit that the lines of code you’ve written look reasonably safe and do not appear to be accepting tainted input, but I’m not going to risk that. I’ve been running several versions of phpBB–and we all know the sorts of holes that software has–along with WordPress and a few other PHP-based web apps without ever having encountered this issue before. Seriously, it makes me kind of worried about the rest of your code! Let’s take a look at the comments in the Suhosin INI file:

; The /e modifier inside preg_replace() allows code execution. Often it is the
; cause for remote code execution exploits. It is wise to deactivate this
; feature and test where in the application it is used. The developer using the
; /e modifier should be made aware that he should use preg_replace_callback()
; instead.

‘Nuff said.


Here’s a good source on preg_replace, why you should always use single quotes, common mistakes, and why you should really just avoid using /e in the first place.

No comments.
***