De: “dirsubmit326@yahoo-inc.com”
Para: jmafonseca2008@yahoo.com.br
Enviadas: Sexta-feira, 9 de Março de 2012 5:35
Assunto: Yahoo! Listing [Order 151913725]

Dear Yahoo! Directory Submit Client:

The URL you previously submmitted for expedited review

with Yahoo! Directory Submit order #151913725 has been reviewed
by the Yahoo! Directory Submit editorial team as part of the Annual Review
process and your credit card has been charged the applicable fee.

Never mind that the site has been off the air since earlier in 2011 so Yahoo! did obviously never review this site – because the site did no longer exist on March 9 2012.

They went ahead and charged my card without ever providing the service they claim they did.

Billing a card twice by accident is a mistake. The batch job failing overnight is a mistake. Charging for the wrong currency is a mistake. These are nuisances, but are explainable and normally easy to fix.

But claiming to have reviewed a site that doesn’t exist is not a mistake, it’s a scam.

It is now May 21 2012 and I have never heard back from them. But it doesn’t stop there. Have a look at the rest of this ridiculous message:

In accordance with the Yahoo! Directory Submit Terms of Service, your site
is reviewed annually to ensure the site is functional, placed in
an appropriate category, has an accurate and relevant
description, and continues to meet the qualifications for
inclusion in the Yahoo! Directory. For more information on the
Annual Review and/or the Recurring Annual Fee, please see the
Yahoo! Directory Submit Terms of Service
(http://docs.yahoo.com/info/suggest/terms.html).

Really? AllWebHotels.com is fully functional and “meets your qualifications” for the Yahoo! Directory?! That’s one great quality control you got going there!

On top of it all, just to complete my day, an old friend of mine requested a conversation by Yahoo! Messenger. I downloaded it and regrettably installed the thing.

Now their messenger installed all sorts of spyware on my Firefox and I simply can’t get rid of all the Yahoo! crap on my browser.

Oh and Yahoo! apparently uninstalled the uninstall function, I can’t find it anywhere.

They took U$ 300 from me for no reason, they didn’t reply support emails requesting a refund for this scam and then they crapped all over my browser.

Google, Facebook and DuckDuckGo don’t even have to try. Yahoo! is destroying itself. What a sad end to one of the WWW’s once most exciting success stories.

package MyAgent;

1;

Well, it doesn’t. The parent class’ fields haven’t been correctly set up. Try $object->timeout(), for example. The following test….

ok($ua->timeout() > 0, 'timeout must be > 0');

…will fail. Because we haven’t run the parent constructor, which should set up a properly initialized UserAgent. We need to run the parent constructor in order to fill in the object.

Let’s go with our intuition, I’d probably try this.
package MyAgent;

1;

That won’t work. We get:

Attempt to bless into a reference at /usr/share/perl5/LWP/UserAgent.pm line 82.

We’re giving our parent a reference to ourselves, not a class name. UserAgent can’t bless $something => $HASHREF which is the correct, documented, behavior for bless.

So we’re left another alternative: instantiate the parent object, which should fill in all instance variables, then we bless that to ourselves. Which is what calling the super constructor is supposed to do in any object oriented language.

package MyAgent;

1;

Let’s write a simple test case for that:

#!/usr/bin/perl

my $user_agent = new MyAgent();
isa_ok($user_agent, 'MyAgent');
isa_ok($user_agent, 'LWP::UserAgent');


Both isa_ok tests pass: it’s a MyAgent and it’s a subclass of LWP::UserAgent.

What did we do?

We instantiated the parent class explicitly and then told Perl it belonged to our current class(we blessed it). It’s almost like class composition instead of inheritance, except instead of having the superclass stored as an instance variable, we have it stored as the blessed variable itself – which probably is what every other object oriented language does anyway, each in their own chic way.

Common Mistakes

Trying something like Java won’t work.
package MyAgent;

1;

$this::SUPER->new() doesn’t do anything for us in the above example. The variable which will become our object is $obj, and it’s just an empty hash. $this contains MyAgent, nothing more. MyAgent::SUPER->new() makes it clear why: new() is setting up a class, statically, nothing is returned from it and $obj is not filled with instance data.

The following is not a mistake per se, but it’s ugly OO code.

sub new {
my ($this) = @_;
my $obj = new LWP::UserAgent();
bless $obj, $this;
return $obj;
}

Calling the superclass explicitly also works, but is ugly(some might say uglier still, considering the already quirky OOrientation in Perl)

How do other popular packages do it?

package WWW::Mechanize;

Exactly as we did on the working example above.

__FIN__
1;

Let’s draw a parallel here. Blaming Reddit, Youtube and even Wikipedia for any eventual copyrighted content submitted by their users is akin to blaming gun makers for homicides committed using their product. You will not, in our lifetimes, see the gun makers be criminally convicted for murders committed using their product. It’s been tried, and it’s always been a lost cause. Civil lawsuits have been won, damages have been granted for violent gun-related crimes, but a criminal conviction has never been attained, precisely because you can’t be criminally responsible for crime you didn’t commit(or actively participate in, in some way).

Why should SOPA, then, convict websites like Wikipedia of a felony if anyone is able to submit copyrighted content to them? It is obvious that if SOPA is passed, it may be used against websites by the very copyright holders. Copyright owners, who have been known for spreading their own content as a “honey pot” in order to implicate downloaders, could easily sabotage sites like Wikipedia by submitting their own content, taking screenshots filing lawsuits for copyright infringement.

SOPA has the potential to create a sea of lawsuits, by everyone against everyone. Just upload your copyrighted work and file a criminal complaint any given site. This old trick has been used against me in the past, by a photographer.

One website I worked on was sued by a photographer who claimed one of his photos was used without authorization. We checked and the photo had been uploaded just days before the lawsuit was filed…it is unlikely this photographer found this photo casually on the internet. Most likely, we were the victims of that very photographer. We checked and this person had over 300 identical lawsuits against sites which allowed the upload of photos. Basically, this photographer was making a living by submitting his photos and then filing lawsuits. As of this time, we’re still defending ourselves against his accusations. Now, imagine if SOPA were in effect here, we’d be criminally responsible, along with 300 others, for a crime we didn’t commit.

SOPA has the potential of destroying the collaborative nature of the Internet and it must be stopped. Do your part!

Here’s a simple example. I’ll ask Google to define what monopoly means.

I take the definition and search for it in quotes, on Google itself. Which gives me the following result:

The definition which Google showed on its search result is exactly the same provided by the Oxford Dictionary. But the user never reached the source of the original definition of “monopoly”, never registered for that site’s services, never even saw the logo of Oxford.

I wonder if dictionary sources are getting some compensation for allowing this?

The solution is to “View Original Message” on the drop-down menu located at the top-right hand corner of Gmail messages. There you’ll find the link, you should copy and paste it into a new browser tab.

After a few pleasant hours of the usual custom compilations, package upgrades and pre-requisites checking, the migration was finally done. To our surprise, all went perfectly – not a single glitch.

Comparing to some of my past experiences, it’d be surreal to imagine such a successful migration a few years ago, with zero complaints or technical issues.

Peace lasted very little, as expected: several hours after the launch, Apache had started randomly returning blank pages and producing 500 Server Errors.

The only clue I had was this error_log entry, repeated thousands of times:

(103)Software caused connection abort: cache: error returned while trying to return disk cached data


So mod_cache was ruining our sleep.

What didn’t work

Since you’ve likely Googled or Binged the problem and read all the suggestions in mailing lists and forums, here are some steps I tried and still didn’t work:

• Disabled SELinux – no luck. (Who knows, in previous lives I had issues with Apache serving and SELinux.)
• Changed mounted disks for the cache data – no luck. (Maybe we had a bad filesystem, who knows.)
• I thought it could be related to the Amazon EBS virtual drive latency, so I used the instance RAM memory for the cache directory(using tmpfs) – no luck.
• Tried reducing the CacheDirLevels and CacheDirLength to one. Nope…wait 15 minutes or so, and the errors returned.
• Set htcacheclean to clean up after 30 minutes, allowing only 250MBytes of cache data. (/usr/sbin/htcacheclean -p /var/cache/apache/ -l250M -d30). No luck – the errors still appeared, seemingly randomly.

There was apparently no specific file type that triggered the error. PHP scripts, Perl programs, WordPress, MediaWiki and our in-house systems – all equally affected.

Note that each time the Cache settings were changed, we started with a fresh cache directory(/var/cache/apache1,apache2,apache3 … apacheN). Once we found a solution, we went back to /var/cache/apache – cleaning it up before.

After reading a dozen or so related complaints in mailing lists and having unsuccessfully tried their recommendations I figured it was time to access the Apache documentation and see what directives we could tweak that could help us.

mod_disk_cache gives us 5 configuration options only: CacheDirLength, CacheDirLevels, CacheMaxFileSize, CacheMinFileSize and CacheRoot. Click here for a detailed explanation of each. After testing several combinations of these directives, and starting with a fresh cache directory, the error would return after a few thousand(or so) requests. Debugging this issue is specially hard because the problem doesn’t happen as soon as the Apache server is started – it takes a while to replicate and test.

The Solution

This combination of CacheMaxFileSize and CacheDisable for the images directory.

CacheMaxFileSize 64000
CacheDisable /images


Limiting the cached files to 64KB and making sure the /images directory was not being cached solved the problem. It’s been a week now and we had zero of the dreaded “Software caused connection abort” error 103 messages. Having to block the images directory came as a shock to us, because none of the errors we examined were triggered by serving an image. It seemed random and happened for html files, PHP and Perl scripts and so forth.

So what’s the cause? I have no idea. Folks wanted the site back up and running, so we had zero time left for long debugging sessions. It’s something which only happened after a few minutes. The reason it took the initial install more time to present the problem was because we performed the main migration on a late sunday night, when traffic was considerably lower.

Additional Info


#httpd -l
Compiled in modules:
core.c
prefork.c
http_core.c
mod_so.c

# Cache-related directives on httpd.conf:
CacheRoot /var/cache/apache/
CacheEnable disk /
CacheMaxFileSize 64000
CacheDirLevels 1
CacheDirLength 1
CacheDisable /images
CacheDefaultExpire 176400
CacheIgnoreHeaders Set-Cookie
CacheIgnoreNoLastMod On


I’m aware of the dangers of a badly implemented ORM schema and I took care to add enough constraints to my query so that next() won’t blow up my memory space. And I never use all() … at all().

So I searched for options on how to quiet these messages, because in a heavy traffic site these log files reach gigabytes every day. Plus, logging all that stuff surely slows the site down. Here’s how I solved it. If you came here looking for an elegant solution, please hit Back now.


# cd /usr/local/share/perl5/DBIx/Class
# vi ResultSource.pm
:/Prefetching # this will search for the first occurrence of the word Prefetching
#carp (
# "Prefetching multiple has_many rels ${last} and ${pre} "
# .(length($as_prefix)
# ? "at the same level (${as_prefix}) "
# : "at top level "
# )
# . 'will explode the number of row objects retrievable via ->next or ->all. '
# . 'Use at your own risk.'
#);


Comment out the multiline carp() call, and Bob’s your uncle. A clean error_log from now on.

The traffic on some of the sites is quite respectable, so i was definitely not a “morning bug” issue.

The messages I was receiving varied, and the error seemed random – it wasn’t the first connection, it wasn’t a last, not related to long queries, not related to a certain section of the web site and so on. Worst kind of problem to debug.

Some of the messages I received included:

DBI Connection failed
or
Can't connect to MySQL server on [...]
or
DBI Connection failed: Lost connection to MySQL server at 'reading authorization packet', system error: 0 at [...]


Further testing led me to several MySQL bug reports, some of which were legitimate. Others were just support requests disguised as bugs.

It turns out sometimes the network latency of EC2 instances can get quite high. I’d heard such comments before, but never had any issues.

Raising connect_timeout from the default of 5 seconds to 30 solved the ‘connection failed’ problem. Raising the net_read_timeout solved the ‘Lost connection’ issue. All three problems were related to network latency.

Added to my MySQL server’s /etc/my.cnf [mysqld] section:

connect_timeout=30
net_read_timeout=45


Update: download the fixed version here.

The discussion is happening over at the timthumb.php development site.

If you don’t absolutely need to use external images on your site thumbnails, then you should clear the $allowedSites array immediatley:


$allowedSites = array (
'flickr.com',
'picasa.com',
'blogger.com',
'wordpress.com',
'img.youtube.com',
'upload.wikimedia.org',
);


The vulnerable code is at line 641:


$isAllowedSite = false;
foreach ($allowedSites as $site) {
if (strpos (strtolower ($url_info['host']), $site) !== false) {
$isAllowedSite = true;
}
}


strpos() will report a true value if it finds the allowed site anywhere within the $site string. So ‘flickr.com.badguyblackhat.com’ will pass.

The Exploit

Instead of submitting an image, an attacher will try to make a thumbnail out of a file containing PHP code, also ending in the .php extension.

The thumbnail process will fail of course, but a copy of the PHP file will be stored at the ./cache/ directory – using the same name that was submitted(including .php). The attacker will then access the file remotely and your server will run its contents.

The vulnerability is very serious, it is out on the WWW right now and you should take immediate action.

Temporary Fix

Clear the $allowedSites array until a new version is released.

Update: download the fixed version here.


$allowedSites = array ();


https://plus.google.com/u/0/downgrade/

Unfortunately, I shared a couple of posts on Google+ and they ended up on over a hundred mailboxes as unsolicited mail. The checkbox under the Share button means you’d like to share with everyone NOT on Google+. I scanned it in a hurry and ended up accidentally spamming almost 200 mailboxes of former bosses, former relationships and tens of folks I haven’t talked to in a while. Some of the phone calls were less friendly than others.

In one word: Awkward.

Tip received via Reddit.com