Im Web finden sich viele, für solche Infos gern verwendete, Blogs und Foren in denen nachzulesen ist wie denn nun das Installationsdatums eines Linux Systems rauszufinden ist. Eine kleine Sammlung aus der Google Suche:

• pro-linux.de
• erasel.net
• unixboard.de
• oldwiki.christian-stankowic.org

Ich fand das Thema auch interessant und dachte mir das ich das posten würde. Jetzt wars eben doof, das ich mein Installationsdatum genau wusste. Das Ausführen des Kommandos:

ls --sort=t /dev -l | tail -n1 | awk '{print $8 " " $7 " " $9}'

bzw. von:

ls --sort=t /dev -l | tail -n1 | awk '{print $8 " " $7 " " $8}'

brachte mir ein falsches Ergebnis (20:51-2009-04-27) auf meinem Desktop Rechner (Ubuntu Hardy). Richtig wäre gewesen 18:10-2008-08-07. Ebenso auf dem Server (Debian Lenny davor Sarge) 05:20-2011-01-22 statt 16:07-2006-11-28. Die passenden Ergebnisse liefert mir:

ls --sort=t / -l | tail -n1 | awk '{print $8 " " $7 " " $9}'

bzw.:

ls --sort=t / -l | tail -n1 | awk '{print $8 " " $7 " " $8}'

Die Dateien unter /dev müssen sich nach einem System Update verändert worden sein. Unter Ubuntu kann der Installationszeitpunkt bzw. das Datum auch anhand des Ordners /lost+found/ im root Verzeichnis abgelesen werden. Dieser wird bei der Installation angelegt und nicht weiter verändert.

Abgesehen von der Tatsache wie viele Leute sich inzwischen sicher an einem falschen Installationsdatum erfreut hatten ist es interessant wir sich ein kurz Tipp durchs Web verbreitet. Für mich ist das der Blogger Copy & Paste Tipp 2011. Deswegen gibts den auch bei mir im Blog.

Mich würde interessieren wann ihr eure Systeme installiert habt oder ob noch jemand mit Ubuntu Hardy unterwegs ist.

Thomas Hoeren, Professor an der Universität Münster, hat zum April 2011 ein Skript zum Thema Internetrecht veröffentlicht. Das Skript behandelt kapitelweise die Themen:

1. Information und Recht – die Kernberiffe
2. Rechtsprobleme beim Erweb von Domains
3. Das Urheberrecht
4. Online Marketing: Werberechtliche Fragen
5. Der Vertragsschluss mit dem Kunden
6. Datenschutzrecht
7. Haftung von Online Diensten
8. Die internationalen Aspekte des Internetrechts
9. Internetstrafrecht
10. Musterverträge

Der Aufbau des Skriptes gleicht sich an die Bedürfnisse von Internetagenturen und Webdesignern an. Einen direkten PDF Download findet ihr hier.

Version: Magento 1.4.2.0

Diese kleine Änderung erlaubt es mit Hilfe des Magento Wysiwyg Editor TinyMCE neben Bildateien auch PDF und ZIP Dateien auf der Server hochzuladen.

Um nun in der Artikelbeschreibung PDFs und ZIPs uploaden zu können sollte der folgende Teil der XML Datei app/code/core/Mage/Cms/etc/config.xml erweitert werden:

 <extensions>
     <allowed>
         <jpg>1</jpg>
         <jpeg>1</jpeg>
         <png>1</png>
         <gif>1</gif>
         <pdf>1</pdf>
         <zip>1</zip>
     </allowed>
     <image_allowed>
         <jpg>1</jpg>
         <jpeg>1</jpeg>
         <png>1</png>
         <gif>1</gif>
     </image_allowed>
     <media_allowed>
         <flv>1</flv>
         <swf>1</swf>
         <avi>1</avi>
         <mov>1</mov>
         <rm>1</rm>
         <wmv>1</wmv>
     </media_allowed>
 </extensions>

Nach Herzenslust können die jeweiligen Abschnitte, die die verschiednen Dialoge im TinyMCE Editor darstellen, um Dateitypen erweitert werden.

Alternativ gibt es hier die Magento 1.4.2.0 PDF und ZIP Upload Mini-Extension zum Download. Diese kleine Extension bewirkt die oben demostrierte Änderung. Die Extension ist gemäß der Verzeichnisstruktur in der ZIP Datei auf den zu Server kopieren.

Version: xt:Commerce v3.0.X

Am 18.02.2011 wurde auf xtc-load.de über einen Patch für einen kritischen Fehler in xt:Commerce v3.0.4SP2.1 berichtet.

Der SQL Injection Bugfix von xtc-load.de behebt NICHT alle Fehler.

Download xt:Commerce v3.0.4SP2.1 incl. eregi (Nullbyte Injection) SQL Injection Bugfix

Angepasste Dateien: inc/xtc_validate_email.inc.php, password_double_opt.php

• { Download Seite }
• { Direkter Download }

Fix für den Fix

Der auf xtc-load.de oder anderen Seiten angebotene Patch löst das Problem mit der SQL Injection sicher, jedoch nicht die Nullbyte Injection in der Funktion xtc_validate_email() (inc/xtc_validate_email.inc.php). Der Patch (xtc-load.de) enthält in dieser Datei folgenden Codeschnippsel der zum verhindern der Nullbyte Injection verwendet werden soll:

// sql injection fix 16.02.2011
if (strpos($email,"\0")!==false) {return false;}

Hierbei wird auf das “\0″ geprüft. Jedoch nicht auf die ebenfalls gültigen “\x00″, “\u0000″ und “\000″ Nullbytes. Ein Fix für den Fix (eine bereits gegen die Nullbyte / SQL Injection gefixte Version) ist das ersetzen des oben erwähnten Codeschnippsels mit folgendem:

## Bugfix for nullbyte injection. More: http://www.monkey-business.biz/1586/xtcommerce-v3-0-x-eregi-nullbyte-injection-sql-injection/
str_replace(array("\0", "\x00", "\u0000", "\000"), '', $email, $count); if ($count > 0) return false;

Der Codeschnippsel hat den selben Sinn wie der bereits enthaltene, er prüft jedoch zusätzlich noch auf die ebenfalls gültigen Nullbytes. In die Variable $count wird von der Funktion str_replace() die Anzahl der ersetzten Nullbytes im E-Mail String hinterlegt. Danach wird geprüft ob ein Nullbyte ersetzt werden musste. Ist dies der Fall wird die Funktion beendet und die E-Mail für ungültig erklärt und nicht in die Datenbank geschrieben.

Details zur Sicherheitslücke

Das Vorgehen ist denkbar einfach. Nach der erfolgreichen Anmeldung im xt:commerce Shop muss der in der E-Mail Adresse injizierte SQL Code (via account_edit.php) über die xt:commerce “Passwort vergessen” Funktion ausgeführt werden nachdem die Passwort vergessen E-Mail angefordert wurde. Die E-Mail Adresse die beim Ausführen von password_double_opt.php aus der “Passwort vergessen” E-Mail heraus zur Injektion verwendet wird kann beispielsweise folgenden String enthalten:

yourmail@example.com \x00' OR customers_email_address = 'shopadmin@example.com

Dies bewirkt die Übermittlung des Strings an den MySQL Server:

UPDATE customers SET customers_password = '7e716d0e702df0505fc72e2b89467910' WHERE customers_email_address = 'yourmail@example.com \x00' OR customers_email_address = 'shopadmin@example.com'

Im weiteren Ablauf des password_double_opt.php wird das Passwort für shopadmin@example.com, in diesem Beispiel Shop Administrator, an yourmail@example.com gesendet.

Was hat das mit dem Nullbyte zu tun?
Die PHP Funktion eregi() die in der xtc_validate_email() Funktion in der Datei inc/xtc_validate_email.inc.php in xt:commerce verwendet wird nutzt die darunter liegende C-Lib um den String zu lesen. Diese Lib erkennt ein Nullbyte (\0, \x00, \u0000, \000) als String Ende. Bei der Überprüfung mit eregi() wird also das Nullbyte von der Funktion als vorzeitiges String Ende angesehen und nur der Teil des Strings bis zum Nullbyte überprüft. Das heißt nach einem Nullbyte können beliebige Zeichen eingeschleußt werden. Es handelt sich hierbei also um keinen Fehler den xt:commerce Shopsystems.

Ob die Nullbyte und SQL Injection von Erfolg gekrönt ist hängt von den php.ini Einstellungen ab. Optionen die \ in Eingaben über $_POST oder $_GET filtern verhindern oder verändern unter Umständen den nötigen Injection String.

Nach dem Update auf WordPress 3.1 war in meinem Theme auf dieser Seite ein weißer Streifen am oberen Rand (on top) des Browserfensters mit 28px Höhe zu sehen. Dieser Streifen entpuppte sich nicht als Element sondern als Style Anweisung html { margin-top: 28px !important; }.

Der Fehler entsteht durch ein neues Freature in WordPress und ist nur im angemeldetem Zustand mit entsprechenden Rechten sichtbar. Kurz: Nach dem Update sehen euere Leser nicht den weißen balken, keine Sorge.

Beheben lässt sich der Fehler durch das Einfügen der wp_footer() Funktion innerhalb des body Tags in euer Theme / Template.

Nach dem Einfügen des wp_footer() Funktionsaufrufs bekommt ihr, nach dem aktuallisieren der Browser Ansicht, die neue WordPress Frontend Toolbar zu sehen.

Not a bug, It’s a feature

Version: Magento 1.4.X

Problem
Bei dem Versuch eine Bildateien auf den Server zu laden wird die Datei nicht hochgeladen, der Benutzer vom Magento Shopsystem abgemeldet und zum Admin Login weitergeleitet.

Ursache
Magento ist auf einem Server installiert auf dem ebenso der PHP Suhosin Patch installiert ist. Die Session wird vom PHP Suhosin Patch anhand der Browserkennung des Benutzers verschlüsselt. Der Login in das Magento Shopsystem erfolgt mit der Browserkennung des Webbrowsers. Die Anfragen zum Datei Upload erfolgen über das Flash Plugin des Browsers, welches eine eigene Browserkennung besitzt. Während des Upload Prozesses kann der Server die Session des Benutzers nicht entschlüsseln und meldet den Benutzer dadurch vom Shopsystem ab.

Lösung
Des Fehlers Lösung ist das deaktivieren der Option suhosin.session.cryptua in der PHP Suhosin Konfiguration.

php.ini

suhosin.session.cryptua = Off

.htaccess

suhosin.session.cryptua 	Off

Jede Lösungmöglichkeit stellt eine alleinstehend funktionierende Option da.

Andere Artikel zur Datei Upload Problematik helfen dir sicher ebenso weiter.