Beiträge von codestyling

Zitat von Beatinu

Die Strings sind nicht vorne abgeschnitten und hinten verlängert, sondern vorne verlängert und hinten abgeschnitten, daher kann es sein (nicht nachgeguckt), dass eine 0 am Ende des vorherigen Strings dem Nachfolgestring gleich ein Ende macht.

Musst du mir mit deinen Daten mal erklären:

DE 12 04 95 [COLOR=Red]00[/COLOR] [COLOR=Blue]00 00 00 5E[/COLOR] 08 00 00 1C 00 00 00 
-1794895138    FFFFFFFF950412DE
1577058304  [COLOR=Blue]5E000000[/COLOR]
469762056   1C000008
201326592   0C000000
687865923   29000043

Mit diesem 1 Byte Offset auf Strings bezogen, fehlt leider das 1. Zeichen, weil er ja den String um 1 Byte zu weit hinten anfängt zu interpretieren.
... wollt ich nur mal gesagt haben. :)

Zitat von solveig

Hallo!

WAS IST DAS?? XSS?? Bahnhof??

"According to the advisory, the attacker does require authentication and access to the following URL:http://[host]/[directory]/wp-admin/admin.php?page=nggallery-manage-gallery"

Was bedeutet: "the attacker does require authentication and access to the following" ?

Heute war auf einmal meine deutsche Sprachdatei vom Server verschwunden und ich hatte einen smiley in meinem blog im footer, den ich dort nicht eingebaut habe !?????

Grüsse von solveig:)

XSS ist Cross Site Scripting Wikipedia Cross-Site Scripting – Wikipedia .
Wenn jemand die Berechtigung in deinem Blog hat, die Nextgen Gallery zu benutzen, dann kann dieser jemand ein Javascript als Beschreibungstext eingeben, der beim Anklicken des Bildes ausgeführt wird.

Wenn später mal ein angemeldeter Admin auf das Bild draufdrückt, weil er/sie es sich dann im eingeloggten Zustand ansehen will, dann übernimmt das Script die Kontrolle und trägt u.U. einen neuer User als Admin ein oder räumt dem Verursacher Admin Rechte ein. Dann kann dieser jemand deine Seite nach Belieben ändern.

Hast du einen Link zu Blog, so das man mal schauen kann, was genau evtl. schon in der Seite versaut sein könnte ?

Noch eine Ergänzung: Der Smily unter dem Footer kommt von WP Stats und zeigt, das deine Statistik funktioniert.

Zitat von infected

Ja manchmal trat der Fehler auch im Frontend auf. Genau wie Du sagst, erschien dann nur eine weiße Seite mit der besagten Fehlermeldung. Wir können mal folgendes machen: Ich könnte Dir nen FTP Account einrichten und dann kannst Du Deine Test auf meinem Testblog fortführen, quasi am lebenden Objekt.

Ich hab da noch einen Vorschlag: Wir "müllen" das Thema hier erstmal nicht weiter zu als unser persönlichen Chat :mrgreen: sondern ich schickt dir meine E-Mail Adresse und Skype Kontakt, sofern du Skype hast, das geht einfacher.

Und ich würde eine Protokollfunktion in der gettext.php erstmal einbauen, die den Fehler erkennt und in dem Falle ein Logfile (Text) schreibt mit Zeitstempel, Serverauslastung und Fehlerstelle. Dann kann man das auch mal mit den Logs vergleichen und schauen, was in diesem Moment passiert ist.

Da ich nicht testen kann, warum das 1. Zeichen verschoben ist, würde aus
"Artikel schreiben" -> "rtikel schreibenA"
Der 1. weg, dafür von folgenden "Artikel löschen" das A hinten dran.

Passiert der Fehler auch im Frontend ? Dann müssten doch nur Fehlermeldung ausgeliefert werden oder ?

Mit Thai hast du dir eine harte Nuss ausgesucht. Die th.mo Dateien sind bestenfalls Alpha Status (schätze mal max. 40% übersetzt) und hier zum Download: Revision 4534: /th/trunk/messages
Für Plugins oder Themes wird's vermutlich noch schwerer werden, was zu finden.

Ich beschäftige mich seit einigen Wochen (soweit es meine spärliche Freizeit zulässt) mit dem Thema Lokalisierung/Internationalisierung. Eine Patentlösung dafür hab ich noch nicht gefunden, deswegen schreib ich gerade an einer eigenen Lösung für WP.
Auf dem "Markt" sind Lösungen, die wie du schon sagtest, welche entweder die DB's umschalten und auf eine andere Subdomain leiten oder die andere Sorte, die in einem Post alle Sprachen per Sektionen unterbringen.

Mir gefällt der Sektionsansatz nicht, denn wenn ich das Plugin außer Kraft setze (setzen muß wegen Sicherheitspatch), sehe ich nur noch eine Sprache und komme an den Rest nicht mehr ran oder alles auf einmal.
2 Datenbanken sind schon eher was, aber da hapert es dann mit der sprachübergreifenden Suche oder Umschaltung in die andere Sprache.

Alles in Allem ein zu lange sträflich missachtetes Thema ohne wirkliche Patentlösungen.

Zitat von infected

Ich muss zugeben, dass ich von euren letzten Postings nicht viel verstanden habe, dazu fehlt mir einfach das Fachwissen. Daher weiss ich auch nicht in wie weit eure Überlegungen fortgeschritten sind.

Trotzdem möchte ich mich jetzt schonmal für eure super Hilfe danken! Ist ja auch nicht gerade selbstverständlich...

Nicht jeder muss alles können, nur wissen, wohin man sich wenden kann :)

Ich hab noch einen, gerade im Labortest: Da es ja offensichtlich die Index Adressierung zu den Strings zermüllert (manchmal jedenfalls), wäre es eine Option, einen korrekten Index (ohne Absturz und ohne substr) zu haben, auch wenn dann die Beschriftungen evtl. um 1 Zeichen verschoben sind (1. fehlt, dafür 1. von nächsten hinten dran) und der Speed dem von vorher entspricht?

Ist zwar auch eine Krücke aber besser als keine Seite ausliefern. Und im Frontend sollte es deutlich weniger auffallen und wenn dann beim nächsten Reload ggf. weg sein.

Da ich den Fehler ja nicht nachstellen kann, bin ich da limitiert, aber es gibt noch diese Umgehung. Wenn ich in Netz die Reports zum gleichen Thema lese, dann ist meist PHP 5.2.6 und Apache 2.x beteiligt. Auf Apache 1.x bzw PHP 4 scheint das nicht aufzutreten.

Zitat von Beatinu

Codestyling, ich glaube, du hast wenig Chancen den Fehler bei dir zu finden, wenn das Problem bei dir nicht auftritt.

Sehr gut möglich. Aber evtl. könntest du ein var_dump für die ersten 10 Einträge hier reinbauen (gettext.php):

function readint() {
        if ($this->BYTEORDER == 0) {
            // low endian
            $low_end = unpack('V', $this->STREAM->read(4));
            [B]var_dump($low_end);[/B]
            return array_shift($low_end);
        } else {
            // big endian
            $big_end = unpack('N', $this->STREAM->read(4));
            [B]var_dump($big_end);[/B]
            return array_shift($big_end);
        }
    }

und das Ergebnis im Fehlerfall bereitstellen ?

Zitat von Beatinu

Noch was: Bei mir war es so, dass der Versatz erst beim Auslesen der .mo-Revision aufgetaucht ist. Wenn das zuverlässig sein sollte, könnte man bei $revision != 0 statt substr() my_substr() aufrufen. Sehr sehr unschön, aber eine Möglichkeit.

Das schau ich mir mal an. Hier nur Ablauf, rekonstruiert, wie er bei Infected auftritt:
Original Fehlerbild von Infected:

Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in /www/htdocs/xxx/test2/wp-includes/gettext.php on line 91
Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in /www/htdocs/xxx/test2/wp-includes/gettext.php on line 91
Fatal error: Maximum execution time of 30 seconds exceeded in /www/htdocs/xxx/test2/wp-includes/gettext.php on line 166

Mo-File einlesen:
1. streams.php fread() ganzer Fileinhalt

2. gettext.php Zeile: 122
$magic = $this->readint();
Byteorder ermitteln

3. gettext.php Zeile: 133
$revision = $this->readint();
Revision lesen

4. gettext.php Zeile: 135 - 137
$this->total = $this->readint();
$this->originals = $this->readint();
$this->translations = $this->readint();
Anzahl totaler Einträge lesen (int)
Anzahl der originale Lesen (int)
Anzahl der Übersetzungen lesen (int)

5. gettext.php Zeile: 257
$this->load_tables();
erster Aufruf lädt die Tabellen

6. gettext.php Zeile: 154 - 157
$this->STREAM->seekto($this->originals);
$this->table_originals = $this->readintarray($this->total * 2);
$this->STREAM->seekto($this->translations);
$this->table_translations = $this->readintarray($this->total * 2);
Original und Übersetzungtabellen arrays laden

7. gettext.php Zeile: 166
$translation = $this->STREAM->read($this->table_translations[$i * 2 + 1]);
Translation Eintrag lesen

Da er in gettext.php Zeile 166 nach 30 Sekunden hart beendet wurde, muß die Schleife, deren Zähler in 4.)
gelesen wurde, noch immer laufen, weil die Anzahl Einträge massiv groß ist, Zeile: 162
for ($i = 0; $i < $this->total; $i++) {

Nachtrag: Mofile Anfang:
DE 12 04 95 00 00 00 00 5E 08 00 00 1C 00 00 00
0C 43 00 00 29 0B 00 00 FC 85 00 00 00 00 00 00

$magic = 0x950412DE
$revision = 0x00000000
$this->total = 0x0000085E (Anzahl: 2142, ok)
$this->originals = 0x0000001C (Offset: 28 Bytes)
$this->translations = 0x0000430C (Offset: 17164 Bytes)

16164 - 28 Bytes = 17136 Byte / 2142 Einträge = 8 Bytes Breite = 4 Byte Offset + 4 Byte Länge

Zitat von Beatinu

Ich hab das getestet. Bei allen Versuchen war _pos richtig. Das Verhalten von substr() war entweder richtig oder der ausgegebene String war eine Position zu weit vorne. Ich konnte das Verhalten fast zuverlässig ändern indem ich auf meiner phpBB-Installation eine Seite neu geladen habe. Das heißt natürlich nicht, dass _pos immer richtig sein muss. Ich habe _pos im richtigen Constructor auch mal initialisiert, aber das hat mein Problem nicht behoben.

Es könnte sein, dass substr() nur Äger macht, wenn der String lang ist und Apache schon eine Weile läuft. Da z.B. phpBB auch substr() verwendet und ich dort nie ein Problem hatte, gehe ich davon aus, dass die Stringlänge wichtig ist. Wenn ich den Apache neu starte, ist der Fehler für eine Weile (keine Ahnung, wie lange genau) weg.

Ich hab mal einen Test gestartet nur so zum Analysieren. Dabei hab ich mutwillig so initialisiert: $this->_pos = -100000000;
sofortiges Ergebnis (seitenlang):

Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in C:\Program Files (x86)\xampp\htdocs\_root_merlin\wp-includes\gettext.php on line 91

Noch ein Test mit $this->_pos = 190000; liefert nur 4 Zeilen und dann english:

Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in C:\Program Files (x86)\xampp\htdocs\_root_merlin\wp-includes\gettext.php on line 73
Warning: array_shift() [function.array-shift]: The argument should be an array in C:\Program Files (x86)\xampp\htdocs\_root_merlin\wp-includes\gettext.php on line 74
Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in C:\Program Files (x86)\xampp\htdocs\_root_merlin\wp-includes\gettext.php on line 73
Warning: array_shift() [function.array-shift]: The argument should be an array in C:\Program Files (x86)\xampp\htdocs\_root_merlin\wp-includes\gettext.php on line 74

Da er in der 91'er Zeile nur anfängt wenn Pos negativ ist, sieht das nach einem int Problem auf 64bit Machinen bei nicht initialisierter _pos aus und die höherwertigen Bits sind alle 0xFF. Warum bei dir die Strings "nur" um 1 Zeichen verschoben sind, ist mir unklar. Dann dürftest du nur kaputte Strings haben haben aber keine 91'e Warning Zeile.

Zitat von Beatinu

Das wird nicht passieren, siehe PHP: Variablen - Manual Der Default-Wert für Int ist 0, die Initialisierung spielt also keine Rolle. _pos wird immer richtig erhöht, nur liefert substr() leider nicht immer das, was man haben möchte. Ist wohl in der neuesten PHP-Version behoben.

Eine performante Lösung ist, die in WP nachimplementierte gettext-Funktion durch die entsprechende PHP-Funktion zu ersetzten - sofern vorhanden (s. PHP: Gettext - Manual ).

Du vergisst dabei nur, das es mod_php mit zusätzlichen Bytecode Optimierern und Bytecode Caches gibt. Wenn in Stress-Situationen (was sowohl du als auch Infected beschreibt als "wenn was los ist auf meinen Seiten") der Bytecode vom File gerade noch rumliegt, dann kann der Inhalt der var auf sonst was stehen. Ich sag ja nicht, das substr() nicht fehlerhaft sein könnte, aber dieser Fehler sollte dann deutlich häufiger auftreten als nur bei Last.

Und noch was, auf 64 Bit Machinen kann die Zwangskonvertierung von NULL (siehe var_dump) zu negativen Werten führen mit der Konsequenz (PHP Subst):

Zitat

If start is negative, the returned string will start at the start 'th character from the end of string .

Ich hab heute morgen den gefunden Positionsfehler im Bugtrac eingekippt und es ist bereits jetzt ein Changeset verfügbar: #5599 (Sporadic timeout /wp-includes/gettext.php) - WordPress Trac - Trac

Es muß nicht nur das Positionsproblem sein, es kann je nach System (PHP Version und OS) eben auch noch zusätzlich der substr() Bug bzw. der fread() Bug eine Rolle spielen. Ich würde das mit der zusätzlichen fread() Anpassung laufen lassen, bei subst() ist die derzeitige Lösungs alles andere als optimal, wenn sie überhaupt nötig ist. Denn wenn die _pos irgendwo in data steht, dann liest man Phantasiewerte für die Stringanzahlen aus, was den gleichen Effekt haben dürfte.

Zitat von Alphawolf

Schau dir mal den Call Stack an: http://www.zoosau.de/wp_error/

Hättest ja mal als Beigabe das hier noch geben können: #5599 (Sporadic timeout /wp-includes/gettext.php) - WordPress Trac - Trac
Die US Boys interessiert das seit 5 Monaten nicht, denn die brauchen ja kein Übersetzungsfile. Wenn wir uns also nicht selbst helfen, die werden es nicht machen. :cry:
Also ich zieh mir jetzt mal den Bereich gettext komplett rein und schau mir an, was das sein kann. Spannend ist die Aussage, dass die byteweise Ersatzroutine ein paar Übersetzungen schrottet, insbesondere wenn mehrere *.mo im Spiel sind (in dem Fall wohl das Simple Forum *.mo).

Erste Feststellung:

class StringReader {
  [COLOR=Red][B]var $_pos;[/B][/COLOR]
  var $_str;


  function StringReader($str='') {
    $this->_str = $str;
    $this->_pos = 0;
    [COLOR=Blue][B]echo "parent(init)<br />";[/B][/COLOR]
  }


  function read($bytes) {
[I][B][COLOR=Red]   [COLOR=Blue] var_dump($this->_pos);
    var_dump($this->_str);
    exit;[/COLOR][/COLOR][/B][/I]

Die _pos vom StringReader wird nicht initialisiert durch den CachedFileReader (parent Constructor nicht aufgerufen)! Die [COLOR=Blue]blaue[/COLOR] Ausgabe produziert nur folgendes:

NULL string(226673) "ޕ� ........

Alphawolf: Kann es sein, das in Stress-Situationen des Servers die _pos zufällige Werte annehmen kann, weil PHP die Klasse auf schon mal benutzten Speicher blendet, der irgendwie gefüllt ist? Dann liest man quasi Müll aus dem Binärstring und "seeked" sich u.U. tot bis die 30 Sekunden um sind.
Speziell wenn Bytecode Optimierer im Spiel sind, die cachen und bei vielen gleichzeitigen Zugriffen in mod_php den Bytecode nehmen und nochmal ausführen, kann es sein, das ich die letzte Inkrementierung eines anderen Benutzers bekomme, also ggf. mitten oder am Ende der Daten stehe ?

Zitat von infected

... Ist ja lange genug gut gegangen. Prompt werde ich wieder mit ner schönen Meldung bestraft Ich werd gleich mal Beatinu´s Tipp testen.

Aber es kann sein, das die Performance deiner Blogs sehr leidet. Ich werd dann mal einen performanten Ersatz entwerfen und testen, kann aber etwas dauern, soll ja auch was halten :mrgreen:.

Wusste doch, das ich eine vernüftige Erklärung schon gelesen hatte von Putzlowitsch: http://forum.wordpress-deutschland.org/konfiguration/…html#post111917

Zitat von infected

Ich trau mich fast gar nicht es zu sagen, aber ich denke/hoffe das Problem hat sich gelöst. Bislang keinerlei Fehler.

Hoffentlich war´s dann auch die entgültige Lösung. Dann hätte Alphawolf mit seiner Aussage doch noch recht :-D

Ich bin ja auch für einfache Lösungen und wenn es geht, dann ist es ja für Produktivsysteme ok. Aber dennoch bin ich nicht zufrieden mit dieser Lösung, denn:

Wenn ein ungeänderter Programmcode 100 mal mit exakt den gleichen Eingangsdaten (was dein permanentes Zwischenspeichern ja ist) funktioniert und bei der 101ten Ausführung plötzlich nicht mehr, dann ist da was faul.
Gleicher Code und identischer Input kann keine 2 Resultate haben.

Wenn ich die Threads hier so querlese, scheint des Öfteren das Plugin cforms eine Rolle zu spielen, wenn etwas nicht mehr so geht, wie es soll.
Ist nur so eine Idee, falls das jemand von benutzt, dies testhalber zu deaktivieren.

Zitat von infected

Was testen?

Wenn du Alphawolf's Vorschlag durch hast, und es immer noch passiert, wäre Beatinu's Patch der nächste Versuch, so meinte ich das, sorry.
Wäre schon übel, sollte es unter Stress-Situationen in der substr() Funktion zu solchen spontanen Problemen kommt!

Es wäre gut, wenn infected das ebenfalls mal testen könnte, ich würde mir heute abend einen performanten Workarround überlegen. Deshalb wäre ein bestätigter Test, das es daran liegt, sehr wertvoll.

Zitat von Reitmeier

Hi,
das ganze schon mal mit nem anderen Virenscanner getestet?
Nur um mal etwas gewissheit zu bekommen.
cu

Gleiche Aktionen durchgeführt, wie vorher nur unter Kontrolle von McAfee VirusScan Enterprise 8.5i und es wird nichts beanstandet.
Allerdings wurde zwischenzeitlich der TinyMCE Editor gegen den FCKEditor ausgetauscht.

Hab es gerade im FireFox ausprobiert. Es verhält sich genau wie die schreibst, neue Klassen sind erstmal nicht zu sehen.
Ändert auch nichts, wenn man Shift+Reload benutzt. Erst wenn ich den Browsercache leeren lasse und reload der Seite mache, sind auch die neuen Klassen drin. Das ist ein bekanntes Problem bei der Auslieferung von javascript basierten Dateien bzw bei der Auslieferung von CSS Dateien.