Serious security issue in OneFileCMS 1.1.0

There a is serious bug in OneFileCMS 1.1.0 that enables remote users to create, write and delete files in web server context.

If you have a running OneFileCMS installation — pull the plug now. Until this issue has been resolved make sure only trusted users can access your OneFileCMS-powered website.

The author has been informed. Please come back later for updates :)

This is the encrypted exploit (I will post the key once the security holes have been fixed)

Happy new year BTW :)

Update 17.01.2010: The issue seems to be resolved! Update now!

Public DNS

Lately there has been a lot of hassle in Germany regarding Internet censorship via DNS blocking. As a reaction, several groups have set up public DNS resolvers that do not block IPs. CCC has compiled a small list with such servers.

Either I am doing something wrong or many of resolvers listed are slow or unresponsive. Foebud-DNS for example regularly responds after several thousand milliseconds, if at all. Even though providing uncensored public DNS is very commendable, this is simply unusable.

Google has just made their own public DNS resolvers 8.8.8.8 and 8.8.4.4 available. A very clever move that makes Google a bit less dependent on ISP infrastructure. And look at them IP addresses… They are as simple as they can get. Depite the outcry of privacy groups and advocates one must admit this is very, very clever. Even skeptics like me are tempted to use Google resolvers just out of laziness… :) It is funny and scary at the same time.

BTW, OpenNIC has some decent public DNS resolvers available. I think I will use one of them and 8.8.8.8 as a backup.

Gedanken zu Mailadressen-Verschleierung

Vorweg: Ich diskutiere mit einem Kollegen grad das Thema “Mailadressen-Verschleierung” als Anti-Spam-Maßnahme. Den technischen Hintergrund dazu gibts auf techblog.tilllate.com.

> Die Frage ist nicht, ob sie [Anm.: die Spammer] theoretisch dazu in der Lage
> wären, sondern ob sie es [Anm.: das Dekodieren verschleierter Mail-Adressen]
> auch wirklich tun. :) Und scheinbar scheint der Trick das Spamaufkommen
> zumindest zu reduzieren.

Es ist richtig, dass es da einen Unterschied gibt. Allerdings sehe ich es nicht als Aufgabe eines Links an, Spam zu verhindern. Denkt man konsequent auf diesem Weg weiter müsste man ja zu dem Schluss kommen, dass es sinnvoll wäre, überhaupt keine E-Mail-Adressen mehr auf Websites zu schreiben, denn das würde Spam ja noch wirkungsvoller verhindern. Man führt so den Zweck des Internets, nämlich die Kommunikation — und die will man doch, ad absurdum.

Auch die in dem Blog-Post genannten Methoden finde ich ehrlich gesagt albern. Das sind alles nur Krücken. Was für Verrenkungen will man sich von Spammern denn noch aufzwingen lassen? Die ewig nervenden CAPTCHAs gehören für mich zur gleichen Kategorie, nur gibt es noch keine Alternative zu denen.

Spam zu verhindern ist die Aufgabe eines dedizierten Spam-Filters auf dem Mailserver. Nur so ist Spam einigermaßen wirkungsvoll beizukommen. So mache ich das seit über 10 Jahren und ich habe kein Problem mit Spam. Die Leute, die mir schreiben wollen, sollen das tun. Wie sie an die Mailadresse kommen ist mir egal, abschreiben, automatisiert auslesen… egal. Wenn mir jemand Spam schreibt, bleibt er im Spam-Filter hängen und fertig ist die Geschichte.

Maillink-Obfuscation macht auch mehr Probleme als dass sie welche löst. Insbesondere das Verschleiern mit Javascript. Was ist z.B., wenn ein Rechtsanwalt in Abmahn-Stimmung aufs Impressum geht, wo eine verschleierte Mailadresse steht und er “aus Prinzip” JavaScript abgeschaltet hat – schon gibts *aus seiner Sicht* einen Abmahngrund.

Computer und das Internet sind dazu da, den Menschen zu bereichern und ihm die Arbeit zu erleichtern. Mail-Adressen zu verschleiern macht dagegen nur unnötig Arbeit und macht nichts besser als ein guter Spam-Filter — daher mein Fazit: Nein zur Mailadressen-Verschleierung! :)

Optimize WP-PostRating db table

Suffering from slow WP-PostRating plugin? Here’s how you could make it faster — add an index to the plugin’s database:

ALTER TABLE `wp`.`wp_ratings` ADD INDEX `Select1`(`rating_postid`, `rating_ip`);

Quick and painless. Replace wp.wp_ratings with the table name you are using.

It is BTW quite common for WordPress plugins that come with their own database tables not to create indexes. You may not notice that on a low traffic server but when using such plugins on high traffic servers such as Smashing Magazine you have to look out for them and take action.