!!! gzip_cnc: Security-Warnung !!!

[Michael Schröpl]

Hallo Leute,

ich wende mich an diejenigen, die aufgrund der Dis-
kussionen in diesem Forum bzw. durch die Ankündigung über die News des Self-Portals mein Skript "gzip_cnc"
zur Komprimierung statischer Webseiten installert haben.

Es hat leider sich herausgestellt, daß es möglich ist,
auf einer Site, welche gzip_cnc verwendet, Sicherheits-
konzepte des Webservers zu unterlaufen.

Bis zum Schließen der entsprechenden Lücke (wobei ich
im Moment noch nicht weiß, wie ich diese am sinnvoll-
sten schließen kann) empfehle ich daher dringend,

####################################
    ### gzip_cnc nicht zu verwenden. ###
    ####################################

Das mindeste, was gzip_cnc braucht, um unter vertret-
baren Umständen eingesetzt zu werden, ist eine zusätz-
liche Möglichkeit zur Unterscheidung zwischen "lega-
len" und "illegalen" Zugriffen.
Ob es dafür eine rein technische Möglichkeit gibt,
oder ob das Problem durch eine zusätzliche Konfigu-
ration innerhalb von gzip_cnc gelöst werden muß (das
wäre machbar, würde aber vom Anwender entsprechende
Kenntnisse über den Server verlangen und fehleran-
fällig sein), weiß ich im Moment selbst nicht.

Das Problem liegt nicht an einem Programmierfehler,
sondern es geht um das gesamte Konzept von gzip_cnc
und Apache - daher ist beispielsweise Christians Por-
tierung nach C (gzip_cncc) von diesem Effekt genauso
betroffen, und vermutlich auch andere Programme, die
nach demselben Prinzip arbeiten (das muß gar nichts
mit Komprimierung zu tun haben ...).

Traurige Grüße
         Michael

[Christian Kruse]

Hallo Michael,

Das mindeste, was gzip_cnc braucht, um unter vertret-
baren Umständen eingesetzt zu werden, ist eine zusätz-
liche Möglichkeit zur Unterscheidung zwischen "lega-
len" und "illegalen" Zugriffen.
Ob es dafür eine rein technische Möglichkeit gibt,
oder ob das Problem durch eine zusätzliche Konfigu-
ration innerhalb von gzip_cnc gelöst werden muß (das
wäre machbar, würde aber vom Anwender entsprechende
Kenntnisse über den Server verlangen und fehleran-
fällig sein), weiß ich im Moment selbst nicht.

Dann werd doch mal etwas konkreter. Was genau ist das Problem?

Traurige Grüße

Nich den Kopf haengen lassen. Wird schon :)

Gruesse,
 CK

P.S.: Hast du meine EMail erhalten?

[Mathias Bigge]

Hi Michael, hi Christian,

Nich den Kopf haengen lassen. Wird schon :)

vielleicht könntest Du uns eine Frist setzen, das Ding vorübergehend abzuschalten, und dann das Problem veröffentlichen, damit man gemeinsam darüber nachdenken kann. Ich war gerade so begeistert....

Viele Grüße
Mathias Bigge

[Test ... Test ...]

Test ... Test ...

< javascript:alert("Blala")>

< www.a1.net>

ftp://ftp.microsoft.com

< ftp.microsoft.com>

Test ... Test ...

[Test ... Test ...]

Test ... Test ...

<javascript:alert()>

< javascript:alert()>

<javascript://abc; alert()>

< javascript://abc; alert()>

Test ... Test ...

[Test ... Test ...]

Test ... Test ...

< callto:12.34.56.78>

< telnet:www.a1.net>

< http://www.a1.net/ A1>

< A1 http://www.a1.net/>

Test ... Test ...

[Orlando]

Bevor du hier noch weiter nervst: </faq/#Q-19>

[Michael Schröpl]

Hallo Christian,

Dann werd doch mal etwas konkreter. Was genau ist
das Problem?

das Problem ist die bedenkenlose Auswertung von
PATH_TRANSLATED. Das kann leider nicht nur über den
Action-Mechanismus gesetzt werden ... und gzip_cnc
kann bisher nicht unterscheiden, warum es aktiviert
wurde. (Ich suche noch nach einer Möglichkeit ...
einen Tip habe ich schon bekommen.)

Und _wenn_ gzip_cnc einmal beschlossen hat, den Inhalt
einer Datei auszugeben, dann kann kein HTTP-Sicher-
heitskonzept das mehr verhindern, weil auf dieser Ebene
gar kein HTTP-Zugriff mehr erfolgt - das ist schon
lange vorbei ... :-(

Viele Grüße
      Michael

[Christian Seiler]

Hallo,

das Problem ist die bedenkenlose Auswertung von
PATH_TRANSLATED. Das kann leider nicht nur über den
Action-Mechanismus gesetzt werden ... und gzip_cnc
kann bisher nicht unterscheiden, warum es aktiviert
wurde. (Ich suche noch nach einer Möglichkeit ...
einen Tip habe ich schon bekommen.)

ich weiß jetzt nicht, ob das jetzt genau der Tipp ist, den Du schon bekommen hast, aber bei PHP/CGI gibt's ein ähnliches Feature; da wird geprüft, ob ein Redirect passiert ist und wenn nicht, dann wird abgebrochen. Basiert leider auf der nicht-standard CGI-Variable REDIRECT_STATUS aber da auf der Website sowieso nur was von Apache steht ... (genaueres unter http://www.php.net/manual/en/security.cgi-bin.php)

Grüße,

Christian

[Michael Schröpl]

Hallo Christian,

bei PHP/CGI gibt's ein ähnliches Feature; da wird
geprüft, ob ein Redirect passiert ist und wenn
nicht, dann wird abgebrochen.
Basiert leider auf der nicht-standard CGI-Variable
REDIRECT_STATUS aber da auf der Website sowieso nur
was von Apache steht ... (genaueres unter
http://www.php.net/manual/en/security.cgi-bin.php)

ja, in dieser Richtung bin ich gerade am Probieren.

REDIRECT_STATUS löst das Problem in meinem Fall leider
nicht - ich habe sowohl bei einem legalen als auch
bei einem illegalen Zugriff denselben Inhalt in dieser
Environment-Variablen vorgefunden (so daß ich mich nun
wundere, was PHP an dieser Stelle genau macht ...).

Meine Hoffnungen setze ich im Moment auf die Environ-
ment-Variable REDIRECT_URL - diese scheint in jedem
Fall den URL zu enthalten, der eigentlich angefordert
wurde (wobei allerdings gewisse Übersetzungen, etwa
Directory Defaulting, bereits erledigt sind - der URL
ist bereits kanonisiert).

An diesem Wert kann ich offenbar unterscheiden, ob

• das Skript explizit aufgerufen wurde (dann ist
    REDIRECT_URL gleich concat (SCRIPT_NAME, PATH_INFO))
    oder
• ein normaler Zugriff via Handler erfolgte (dann ist
    REDIRECT_URL gleich PATH_INFO)

REQUEST_URI hat einen ganz ähnlichen Inhalt, ist aber
leider noch nicht übersetzt, so daß ich diesen Wert
für Vergleiche nicht heranziehen kann: Bei direkten
Dateizugriffen über den Skript-Aufruf sind REQUEST_URL
und REDIRECT_URL gleich, nicht aber bei Zugriffen auf
Directory Defaults etc.

Meine aktuelle Idee wäre die defensive Variante:
1. Falls PATH_TRANSLATED leer,
   => Selbsttest-Dialog-Aufruf
2. sonst
   a) falls REDIRECT_URL gleich PATH_INFO
      => normale Operation
   b) sonst => HTTP/403 (Forbidden).
Vielleicht verbiete ich damit zuviel, falls durch
irgendwelche weiteren Übersetzungen (mod_rewrite?)
die Bedingung 2a) nicht mehr gelten sollte ... das
wäre im Einzelnen noch zu testen.

Viele Grüße
      Michael

[Christian Seiler]

Hallo Michael,

REDIRECT_STATUS löst das Problem in meinem Fall leider
nicht - ich habe sowohl bei einem legalen als auch
bei einem illegalen Zugriff denselben Inhalt in dieser
Environment-Variablen vorgefunden (so daß ich mich nun
wundere, was PHP an dieser Stelle genau macht ...).

O jemine. Vielleicht haben wir soeben die große PHP-Sicherheitslücke Nr 3 gefunden (2 gabs ja schon: File-Uploads und POST-Verarbeitung) Wie genau hast Du diesen Fall hinbekommen? - ich will mal einen Testcase für PHP machen.

Meine aktuelle Idee wäre die defensive Variante:

1. Falls PATH_TRANSLATED leer,
      => Selbsttest-Dialog-Aufruf
2. sonst
      a) falls REDIRECT_URL gleich PATH_INFO
         => normale Operation
      b) sonst => HTTP/403 (Forbidden).
   Vielleicht verbiete ich damit zuviel, falls durch
   irgendwelche weiteren Übersetzungen (mod_rewrite?)
   die Bedingung 2a) nicht mehr gelten sollte ... das
   wäre im Einzelnen noch zu testen.

Dann wünsche ich auf jeden Fall viel Glück. (und hoffe, dass Bedingung 2a keine Probleme macht)

Grüße,

Christian

[Michael Schröpl]

Hallo Christian,

REDIRECT_STATUS löst das Problem in meinem Fall leider
nicht - ich habe sowohl bei einem legalen als auch
bei einem illegalen Zugriff denselben Inhalt in dieser
Environment-Variablen vorgefunden (so daß ich mich nun
wundere, was PHP an dieser Stelle genau macht ...).
O jemine. Vielleicht haben wir soeben die große PHP-
Sicherheitslücke Nr 3 gefunden (2 gabs ja schon:
File-Uploads und POST-Verarbeitung) Wie genau hast Du
diesen Fall hinbekommen? - ich will mal einen Testcase
für PHP machen.

Ich habe mir ein Verzeichnis /handler angelegt, und darin
eine Datei ".htaccess" mit dem Inhalt
     Action text/html /cgi-bin/env.pl
sowie eine Datei "index.html" mit einem irrelevanten Inhalt.
env.pl gibt alle Variablen des Environments aus.

Dann habe ich zwei Zugriffe gemacht
 a) GET /handler/index.html
 b) GET /cgi-bin/env.pl/handler/index.html
Zugriff a) ist der normale implizite Aufruf des Handlers, so
wie man das bei PHP auch tun würde; Zugriff b) ist der Versuch,
mit dem Handler eine beliebige Datei anzusehen in der Hoffnung,
daß dieser mehr darf, als die Apache-HTTP-Kontrollen zulassen
würden.

Bei beiden Zugriffen bekam ich
   REDIRECT_STATUS=200.
Allerdings produziert der Handler-Zugriff zusätzlich noch
   REDIRECT_REDIRECT_STATUS=200
   REDIRECT_REDIRECT_REDIRECT_STATUS=200
, also zwei zusätzliche redirections - vielleicht verläßt
sich PHP ja auf etwas in dieser Richtung ...

Es spielt dabei übrigens keine Rolle, ob der DirectoryDefault
explizit (vom Anwender) oder implizit (von Apache) umgesetzt
wird - das Ergebnis in PATH_TRANSLATED ist dasselbe.

Viele Grüße
      Michael

[Christoph Zurnieden]

Hallo,

da gibt es viel Möglichkeiten, welche ist genau gemeint?
Gerne auch ausnahmsweise per PM.

Ich würde nämlich gerne einen Workaround anbieten, da einige meiner Kollegen dieses Teil auf meine Empfehlung hin benutzen.

Es wäre mir unangenehm usw, Du verstehst?

so short

Christoph Zurnieden

[Michael Schröpl]

Hallo Christoph,

Es wäre mir unangenehm usw, Du verstehst?

was glaubst Du, wie unangenehm _mir_ das ist ...

Viele Grüße
      Michael

[Michael Schröpl]

Hallo Leute,

ich habe eine Frage an die Spezialisten von der
Netzwerk-Front - insbesondere diejenigen, die sich
mit TCP/IP auskennen.

Ist es möglich, daß ein ankommender HTTP-Request dem
Apache eine willkürliche IP-Adresse vorgaukelt und
trotzdem irgendwie an eine Antwort kommt?

Das Problem besteht letzten Endes darin, daß
gzip_cnc.pl eben nicht _nur_ via Handler-Einbindung,
sondern _auch_ durch direkte URL-Adressierung
aufgerufen werden kann (und sich in beiden Fällen
derzeit etwas zu gleich verhält - ich habe inzwischen
einen Prototyp 1.11, der PATH_INFO mit REDIRECT_URL
vergleicht und 'böse' Zugriffe ablehnt, aber der
ist noch arg wenig getestet ... noch nicht mal auf
meiner eigenen Domain ... bis ich wieder einen
Download anbieten kann, werden wohl noch ein paar
Tage ins Land gehen, die Dokumentation will ja auch
angepaßt werden, und da gibt es einiges zu schreiben).

_Wenn_ es nämlich nicht möglich ist, die IP-Adresse
des Servers, auf welchem gzip_cnc installiert ist,
bei Zugriffen 'von außen' zu fälschen, dann läßt
sich der direkte URL-Zugriff auf das Skript zunageln:
(.htaccess im Installationsverzeichnis des Skripts)

<FilesMatch gzip_cnc.pl>
 order deny,allow
 deny  from all
 allow from meine.eigene.ip.adresse
</FilesMatch>

Die Handler-Einbettung erfolgt durch HTTP-Zugriffe
des Servers selbst - den stört dieser Schutz also
nicht ... die Methode hätte den Vorteil, daß sie ohne
Änderung von des gzip_cnc-Code auskommt und von jedem
Anwender sofort umgesetzt werden könnte.

Natürlich wäre es auch nicht verkehrt,

• dem Skript einen beliebigen eigenen Namen zu geben,
• den Selbsttest-Modus abzuschalten und
• das Senden eigener HTTP-Header abzuschalten
  um einem potentiellen Angreifer den Weg nicht unnötig
  einfach zu machen - das wohl ist der transparenteste
  Betriebs-Modus, den gzip_cnc anbietet ... allerdings
  ist security by obscurity nie wirklich eine tragfähige
  Lösung ...

Viele Grüße
      Michael

[Christian Seiler]

Hallo,

ich habe eine Frage an die Spezialisten von der
Netzwerk-Front - insbesondere diejenigen, die sich
mit TCP/IP auskennen.

bin zwar kein Spezialist, hab' mich aber mit dem Thema auseinandergesetzt.

Ist es möglich, daß ein ankommender HTTP-Request dem
Apache eine willkürliche IP-Adresse vorgaukelt und
trotzdem irgendwie an eine Antwort kommt?

Die HTTP-Kommunikation auf TCP-Ebene sieht wie folgt aus:

---- immer in TCP -----

• Client sendet ein Paket mit dem SYN-Header-Flag (und einer Source-IP)
• Der Server sendet ein Paket mit dem SYN/ACK-Header-Flag an die im vorigen Paket vergebene Source-IP zurück
• Der Client sendet nochmals ein Paket mit dem ACK-Header-Flag zurück.
  ---- jetzt HTTP-spezifisch ------
• Der Client sendet jetzt sein Paket ohne SYN/ACK/FIN-Headers aber mit den Anfrage-Daten z.B. "GET blablabla HTTP/1.1 etc."
• Der Server antwortet jetzt mit einem Paket mit dem ACK-Flag.
  ------ hier wird jetzt auf dem Server der Request bearbeitet -----
  (der Rest ist uninteressant, da nur Daten zurückgeliefert werden)

Der IP-Faker müsste also mindestens 3 Pakete faken. Man muss jetzt aber wissen, dass jedes TCP/IP-Paket einen Zähler enthält, der mit einer Zufallszahl initialisiert wird. Da der Angreifer den Zähler des Servers nicht kennt (da er das erst im ersten Antwortpaket erfahren kann, welches aber nicht an ihn geschickt wird, da die gefakete IP nicht seine ist) dann muss er sie raten. Das ist möglich jedoch extrem unwarscheinlich. Aber: Wenn er den Counter einmal erraten hat (der wird jedes Paket hochgezählt), dann stehen ihm für _diese_ Verbindung Tür und Tor offen. Er kann jedoch nur Anfragen absetzten, aber keine Daten empfangen, da die Pakete nicht an ihn gerichtet sind.

Lange Rede, kurzer Sinn: Da gzip_cnc dazu dient, Daten _zurück_zuliefern, ist es nicht möglich.

_Wenn_ es nämlich nicht möglich ist, die IP-Adresse
des Servers, auf welchem gzip_cnc installiert ist,
bei Zugriffen 'von außen' zu fälschen, dann läßt
sich der direkte URL-Zugriff auf das Skript zunageln:
(.htaccess im Installationsverzeichnis des Skripts)

<FilesMatch gzip_cnc.pl>
order deny,allow
deny  from all
allow from meine.eigene.ip.adresse
</FilesMatch>

Ja - das würde funktionieren.

Grüße,

Christian

[Christian Seiler]

Hallo,

Der IP-Faker müsste also mindestens 3 Pakete faken. Man muss jetzt aber wissen, dass jedes TCP/IP-Paket einen Zähler enthält, der mit einer Zufallszahl initialisiert wird. Da der Angreifer den Zähler des Servers nicht kennt (da er das erst im ersten Antwortpaket erfahren kann, welches aber nicht an ihn geschickt wird, da die gefakete IP nicht seine ist) dann muss er sie raten. Das ist möglich jedoch extrem unwarscheinlich. Aber: Wenn er den Counter einmal erraten hat (der wird jedes Paket hochgezählt), dann stehen ihm für _diese_ Verbindung Tür und Tor offen. Er kann jedoch nur Anfragen absetzten, aber keine Daten empfangen, da die Pakete nicht an ihn gerichtet sind.

Nachtrag: der Angreifer kann nicht mal wissen, ob er erfolgreich war, da er ja keine direkte Antwort bekommt.

Grüße,

Christian

[Sven Rautenberg]

Moin!

Der IP-Faker müsste also mindestens 3 Pakete faken. Man muss jetzt aber wissen, dass jedes TCP/IP-Paket einen Zähler enthält, der mit einer Zufallszahl initialisiert wird. Da der Angreifer den Zähler des Servers nicht kennt (da er das erst im ersten Antwortpaket erfahren kann, welches aber nicht an ihn geschickt wird, da die gefakete IP nicht seine ist) dann muss er sie raten. Das ist möglich jedoch extrem unwarscheinlich. Aber: Wenn er den Counter einmal erraten hat (der wird jedes Paket hochgezählt), dann stehen ihm für _diese_ Verbindung Tür und Tor offen. Er kann jedoch nur Anfragen absetzten, aber keine Daten empfangen, da die Pakete nicht an ihn gerichtet sind.

Nachtrag: der Angreifer kann nicht mal wissen, ob er erfolgreich war, da er ja keine direkte Antwort bekommt.

Ich stimme vollkommen zu.

Es ist für den Angreifer insbesondere nicht möglich, unter der IP-Adresse des Webservers irgendeine Antwort zu empfangen.

Selbst wenn er es schaffen würde, die IP des Webservers erfolgreich zu faken und alle Counter etc. korrekt zu raten, dann würde er dennoch kein einziges Datenpaket _auf die Netzwerkleitung_ kriegen, denn das Routing des Webservers würde alle Datenpakete zur eigenen IP auf das Loopback-Device (127.0.0.1) routen - die Daten kämen niemals auf eine abhörbare Netzwerkleitung. Den Direktzugriff auf die IP/IPs des Webservers zu beschränken hilft enorm gegen Faker.

Rein von der TCP/IP-Ebene ist es IMO unmöglich, per gefakter IP unberechtigt an den Inhalt einer URL zu gelangen. Wie das Ausliefern einer unberechtigten URL an eine externe IP ohne Faken verhindert werden kann, ist Michaels Aufgabe. :)

- Sven Rautenberg

[Henryk Plötz]

Moin,

Rein von der TCP/IP-Ebene ist es IMO unmöglich, per gefakter IP unberechtigt an den Inhalt einer URL zu gelangen. Wie das Ausliefern einer unberechtigten URL an eine externe IP ohne Faken verhindert werden kann, ist Michaels Aufgabe. :)

Auch wenn ich da noch Bedenken hatte, weil einiges eben doch möglich ist (schwache Sequenznummern, man kann Pakete an 127.0.0.1 im LAN doch dem angegriffenen Computer einflößen), ist da noch eine Sache die alles sofort zunichte macht: Wenn der angegriffene Rechner ein SYN/ACK für eine Verbindung erhält, die er nicht angefordert hat, hat er gefälligst sofort ein RST zu senden, um die Verbindung wieder abzubauen.

Eine Anmerkung aber noch: Es geht nicht nur um das Empfangen, bei einigen Anwendungen würde das Aufrufen eines URL bereits ausreichen, um eine serverseitige Aktion auszulösen.

--
Henryk Plötz
Grüße aus Berlin

[Michael Schröpl]

Hallo Henryk,

Eine Anmerkung aber noch: Es geht nicht nur um das
Empfangen, bei einigen Anwendungen würde das Aufrufen
eines URL bereits ausreichen, um eine serverseitige
Aktion auszulösen.

gzip_cnc ist sogar eine solche Anwendung (ein Request
bewirkt möglicherweise die Erzeugung eines Cache-Ein-
trags), aber die serverseitige Reaktion ist nicht son-
derlich von der Art des Requests abhängig (ausgenommen
natürlich vom Wert des PATH_INFO / PATH_TRANSLATED-
Paars, das dabei entsteht) - wiederholte Zugriffe auf
denselben URL bewirken weder etwas Unerwünschtes noch
etwas Variierendes.

Viele Grüße
      Michael

[Michael Schröpl]

Hallo Leute,

ich wende mich an diejenigen, die aufgrund der Dis-
kussionen in diesem Forum bzw. durch die Ankündigung über die News des Self-Portals mein Skript "gzip_cnc"
zur Komprimierung statischer Webseiten installert haben.

Es hat leider sich herausgestellt, daß es möglich ist,
auf einer Site, welche gzip_cnc verwendet, Sicherheits-
konzepte des Webservers zu unterlaufen.

Bis zum Schließen der entsprechenden Lücke (wobei ich
im Moment noch nicht weiß, wie ich diese am sinnvoll-
sten schließen kann) empfehle ich daher dringend,

####################################
    ### gzip_cnc nicht zu verwenden. ###
    ####################################

Das mindeste, was gzip_cnc braucht, um unter vertret-
baren Umständen eingesetzt zu werden, ist eine zusätz-
liche Möglichkeit zur Unterscheidung zwischen "lega-
len" und "illegalen" Zugriffen.
Ob es dafür eine rein technische Möglichkeit gibt,
oder ob das Problem durch eine zusätzliche Konfigu-
ration innerhalb von gzip_cnc gelöst werden muß (das
wäre machbar, würde aber vom Anwender entsprechende
Kenntnisse über den Server verlangen und fehleran-
fällig sein), weiß ich im Moment selbst nicht.

Das Problem liegt nicht an einem Programmierfehler,
sondern es geht um das gesamte Konzept von gzip_cnc
und Apache - daher ist beispielsweise Christians Por-
tierung nach C (gzip_cncc) von diesem Effekt genauso
betroffen, und vermutlich auch andere Programme, die
nach demselben Prinzip arbeiten (das muß gar nichts
mit Komprimierung zu tun haben ...).

Traurige Grüße
         Michael

[Michael Schröpl]

Hallo Leute,

(nein, ich wollte das _nicht_ so abschicken ...)

'es gibt' nun eine neue Version 1.11 von gzip_cnc, welche die
bisherige Mißbrauchsmöglichkeit hoffentlich abfängt. Die mir
bekannte Methode funktioniert jetzt jedenfalls nicht mehr.

Um die obige Aussage zu relativieren: Es gibt noch _kein_
fertiges Download-Paket mit aktualisierter Dokumentation.

Auf meiner Domain läuft aber bereits die Version 1.11 - Eure
Besuche können also als Stabilitätstest dienen (nein, ich
_brauche_ nicht mehr traffic, ich habe aber noch einiges an
Luft nach oben in meinem Webspace-Vertrag ...).
Insbesondere habe ich jetzt auch wieder eine Version 1.11 im
Selbsttest-Modus verfügbar (verlinkt aus der Installations-
beschreibung) - diese hatte ich nach der Meldung des Fehlers
erst mal abgeschaltet.
Ich habe nichts dagegen, wenn jemand anhand dieses bekannten
URLs versucht, das Problem der Version 1.10 auf meinem Server
zu reproduzieren, um zu prüfen, ob das Loch wirklich gestopft
ist.

Die bereits angepaßten Teile der Dokumentation sind auch schon
online verfügbar.
Der wichtigste Teil ist natürlich der geänderte Quelltext unter
   http://www.schroepl.net/projekte/gzip_cnc/program.htm
, den ich hiermit möglichst vielen möglichst mißtrauischen
Augen zum Überprüfen anbiete.
Neu dabei ist die Funktion "validate_handler_activation",
welche die zusätzliche Prüfung der Art des Aufrufes dieses
Skripts zu realisieren versucht.
Ich mache ausdrücklich darauf aufmerksam, daß die Art des
Angriffs im Kommentar dieser Funktion sehr genau beschrieben
ist - nur dadurch ist es Euch möglich, zu kontrollieren, ob
meine Gegenmaßnahme das Problem wirklich lösen kann.

Wer bereits jetzt auf Version 1.11 umsteigen will, kann sich
den Perl-Quelltext in dieser HTML-Seite im Browser markieren
(Cntrl-A), kopieren (Cntrl-C) und per Editor in eine Datei
abspeichern.
Das geht wesentlich effizienter, als den tatsächlichen Inhalt
dieses (programmgenerierten) HTML-Dokuments (mit entity-
encoding usw.) irgendwie weiter verarbeiten zu wollen.

Am Wochenende werde ich die Dokumentation anpassen und ein
neues Download-Archiv basteln.

Viele Grüße
      Michael

[Christian Kruse]

Hallo Michael,

Die bereits angepaßten Teile der Dokumentation sind auch schon
online verfügbar.
Der wichtigste Teil ist natürlich der geänderte Quelltext unter
   http://www.schroepl.net/projekte/gzip_cnc/program.htm
, den ich hiermit möglichst vielen möglichst mißtrauischen
Augen zum Überprüfen anbiete.

Ich habe ein paar kleinere Fixes gemacht und dir die modifizierte Version
zugeschickt.

Gruesse,
 CK

[Michael Schröpl]

Hallo Christian,

Ich habe ein paar kleinere Fixes gemacht und dir die
modifizierte Version zugeschickt.

wohin? Im Büro habe ich schon seit Wochen keine Mail
mehr von Dir bekommen ...

Viele Grüße
      Michael

[Christian Kruse]

Hallo Michael,

Ich habe ein paar kleinere Fixes gemacht und dir die
modifizierte Version zugeschickt.

wohin? Im Büro habe ich schon seit Wochen keine Mail
mehr von Dir bekommen ...

An [e-mail]. Die stimmt doch noch? Hm, das wuerde erklaeren, warum
du auf meine letzten beiden Mails nicht reagiert hast :)

Gruesse,
 CK

[Christian Kruse]

Hallo Michael (nochmal),

wohin? Im Büro habe ich schon seit Wochen keine Mail
mehr von Dir bekommen ...

An [e-mail]. Die stimmt doch noch? Hm, das wuerde erklaeren,
warum du auf meine letzten beiden Mails nicht reagiert hast :)

*uarhgs* misstrauisch geworden durch die Frage habe ich direkt mal ins maillog
geschaut:

Sep  6 15:45:20 amalthea qmail: 1031319920.822732 delivery 3959: failure: Connected_to_193.247.180.58_but_sender_was_rejected./Remote_host_said:_553_sorry,_domain_must_exist_(#5.7.1)/
Sep  6 15:45:26 amalthea qmail: 1031319926.331235 delivery 3960: failure: Connected_to_193.178.169.53_but_sender_was_rejected./Remote_host_said:[e-mail][e-mail]_does_not_exist/

Mit anderen Worten: mein Mailserver hat sich mit 'interner.name'
angemeldet -- was natuerlich quark ist, das ist der interne Name. Jetzt sollten
sie angekommen sein (hoffentlich).

Gruesse,
 CK

[Michael Schröpl]

Hallo Christian,

wohin? Im Büro habe ich schon seit Wochen keine Mail
mehr von Dir bekommen ...
An [e-mail]. Die stimmt doch noch?

Ja. Ich habe gerade eine Art "ping" hingeschickt und Minuten später
eine Antwort zurück bekommen (die GMX-Adresse ist nur ein Forwarder
mit Spam-Filter usw.).

Jetzt sollten sie angekommen sein (hoffentlich).

Ja - alles prima. Jetzt muß ich nur noch den Inhalt verdauen ...

Viele Grüße
      Michael

[Christoph Zurnieden]

Hallo,

wohin? Im Büro habe ich schon seit Wochen keine Mail
mehr von Dir bekommen ...
An [e-mail]. Die stimmt doch noch?

Ja. Ich habe gerade eine Art "ping" hingeschickt und Minuten später
eine Antwort zurück bekommen (die GMX-Adresse ist nur ein Forwarder
mit Spam-Filter usw.).

Jetzt sollten sie angekommen sein (hoffentlich).

Ja - alles prima. Jetzt muß ich nur noch den Inhalt verdauen ...

Da habe ich heute mittag noch auf die Schnelle Deinen Perlcode nach C portiert und in gzip_cncc reingefummelt (Und dem Christian gesandt. Keine Antwort, habe allerdings auch keine erwartet) und bin gerade erst zum Testen gekommen, da seh ich doch, das ich da ein Posting übersehen habe.
Ich bin selber auf einige Problemchen gestoßen und bitte deshalb um Details falls es keine Perlspezifischen Haken sind.

BTW: schon durchgelesen?
http://interviews.slashdot.org/interviews/02/09/06/1343222.shtml?tid=145

so short

Christoph Zurnieden

[Michael Schröpl]

Hi Christoph,

Ich bin selber auf einige Problemchen gestoßen und bitte deshalb um
Details falls es keine Perlspezifischen Haken sind.

ich habe bisher nur kurz drüber geschaut, aber das Wesentliche ist ein
sehr viel besserer Perl-Stil als meiner, und der (noch ungetestete)
Versuch, If-Modified-Since zu behandeln, also mehr HTTP zu unterstützen.
Bisher liefert gzip_cnc immer content; nun soll es auch HTTP-304 können.

Das wäre traffic-sparender, wenn die Besucher oft Caches validieren -
was sie eigentlich nicht tun sollten, weil gzip_cnc ihnen 'lange' (aber
konfigurierbare) Expires-Header zu senden versucht ...

BTW: schon durchgelesen?
http://interviews.slashdot.org/interviews/02/09/06/1343222.shtml?tid=145

Wann bitte soll ich _das_ auch noch schaffen? Eigentlich müßte ich fünf
wichtigere Dinge tun - beispielsweise mal schnell den kompletten RFC2616
verstehen lernen, um mit den Squid-Leuten weiter diskutieren zu können
... oder in mod_gzip eine geänderte Regelanalyse einbauen, weil es mit
der bisherigen niemals richtig HTTP/1.1 wird unterstützen können ...
ich könnte mühelos einen Stab C-Programmierer beschäftigen ... ;-)

Viele Grüße
      Michael

[Christoph Zurnieden]

Hallo,

Hat ein wenig länger gedauert. Möchte mal wissen, wieso sich alle Leute auf das Wochenende freuen?
Wahrscheinlich weil sie vorher alle Sorgen und Nöte bei mir geparkt haben *grmpf*

Ich bin selber auf einige Problemchen gestoßen und bitte deshalb um
Details falls es keine Perlspezifischen Haken sind.

ich habe bisher nur kurz drüber geschaut, aber das Wesentliche ist ein
sehr viel besserer Perl-Stil als meiner, und der (noch ungetestete)
Versuch, If-Modified-Since zu behandeln, also mehr HTTP zu unterstützen.
Bisher liefert gzip_cnc immer content; nun soll es auch HTTP-304 können.

Ja, schlecht wär's natürlich nicht. Sollte eigentlich auch kein größeres Problem darstellen.

Interessante Aufgabe.
Ja, gefällt mir ;-)

Das wäre traffic-sparender, wenn die Besucher oft Caches validieren -
was sie eigentlich nicht tun sollten, weil gzip_cnc ihnen 'lange' (aber
konfigurierbare) Expires-Header zu senden versucht ...

Nun, Du kennst die Clientsoftware, und die Proxies, und ...
*sigh*
;-)

BTW: schon durchgelesen?
http://interviews.slashdot.org/interviews/02/09/06/1343222.shtml?tid=145

Wann bitte soll ich _das_ auch noch schaffen?

Während der Kaffepause. Da habe zumindest ich es gemacht.

Eigentlich müßte ich fünf
wichtigere Dinge tun - beispielsweise mal schnell den kompletten RFC2616
verstehen lernen, um mit den Squid-Leuten weiter diskutieren zu können

Ja, das würde sich empfehlen. Die Jungs sind wirklich gut.
Aber auch ziemliche Betonköpfe, wie man so vernehmen konnte ;-)

... oder in mod_gzip eine geänderte Regelanalyse einbauen, weil es mit
der bisherigen niemals richtig HTTP/1.1 wird unterstützen können ...

Oh Gott! ;-)

ich könnte mühelos einen Stab C-Programmierer beschäftigen ... ;-)

Nein, mehr als einer ist nie "mühelos", das würdest Du ohne psychotherapeutische Intensivbegleitung nicht lange überleben >;->

so short

Christoph Zurnieden

[Michael Schröpl]

Hi Christoph,

Nun, Du kennst die Clientsoftware, und die Proxies,
und ... *sigh*

Alles, was mir die Squid-Entwickler in den letzten
Tagen erzählt haben, klang sehr überzeugend.

Wann bitte soll ich _das_ auch noch schaffen?
Während der Kaffepause. Da habe zumindest ich es
gemacht.

Die ist leider schon verplant ... irgendwer muß ja
auch noch die Anwender-Fragen auf der mod_gzip-
Mailingliste beantworten ... und die Dokumentation
dafür pflegen ... und ...

Ja, das würde sich empfehlen. Die Jungs sind
wirklich gut. Aber auch ziemliche Betonköpfe,
wie man so vernehmen konnte ;-)

Bisher merke ich nur, daß sie HTTP wirklich drauf
haben. Viiiiiel besser als ich ... und daß mod_gzip
wegen des Vary:-Problems sehr viel weniger RFC2616-
compliant ist, als ihm gut tun würde. :-(

ich könnte mühelos einen Stab C-Programmierer
beschäftigen ... ;-)
Nein, mehr als einer ist nie "mühelos", das würdest
Du ohne psychotherapeutische Intensivbegleitung
nicht lange überleben >;->

Also von Deiner oder Christian Kruses Sorte halte ich
einige aus ... ;-)

Viele Grüße
      Michael

[Christoph Zurnieden]

Hallo,

Nun, Du kennst die Clientsoftware, und die Proxies,
und ... *sigh*

Alles, was mir die Squid-Entwickler in den letzten
Tagen erzählt haben, klang sehr überzeugend.

Dazu kann ich nichts sagen, da war ich nicht dabei (pun intended ;-)

Wann bitte soll ich _das_ auch noch schaffen?
Während der Kaffepause. Da habe zumindest ich es
gemacht.

Die ist leider schon verplant ... irgendwer muß ja
auch noch die Anwender-Fragen auf der mod_gzip-
Mailingliste beantworten ... und die Dokumentation
dafür pflegen ... und ...

Also ich weiß ja nicht, aber Pause sollte Pause bleiben. Die auch noch mit Arbei zu füllen ist kontraproduktiv.

Ja, das würde sich empfehlen. Die Jungs sind
wirklich gut. Aber auch ziemliche Betonköpfe,
wie man so vernehmen konnte ;-)

Bisher merke ich nur, daß sie HTTP wirklich drauf
haben. Viiiiiel besser als ich ... und daß mod_gzip
wegen des Vary:-Problems sehr viel weniger RFC2616-
compliant ist, als ihm gut tun würde. :-(

Details bitte, Herr Kollege, Details.
...
Nein, das weiß ich schon, geht's evt noch genauer? ;-)

ich könnte mühelos einen Stab C-Programmierer
beschäftigen ... ;-)
Nein, mehr als einer ist nie "mühelos", das würdest
Du ohne psychotherapeutische Intensivbegleitung
nicht lange überleben >;->

Also von Deiner oder Christian Kruses Sorte halte ich
einige aus ... ;-)

Über Christian kann und darf ich nichts sagen, aber mich als Kollegen oder gar Untergebenen im Angesicht einer Deadline? Das gäbe Mengenrabatt bei Deiner Hausapotheke! ;-)

so short

Christoph Zurnieden

[Michael Schröpl]

Hallo Christoph,

Wann bitte soll ich _das_ auch noch schaffen?
Während der Kaffepause. Da habe zumindest ich es
gemacht.
Die ist leider schon verplant ... irgendwer muß ja
auch noch die Anwender-Fragen auf der mod_gzip-
Mailingliste beantworten ... und die Dokumentation
dafür pflegen ... und ...
Also ich weiß ja nicht, aber Pause sollte Pause bleiben.
Die auch noch mit Arbeit zu füllen ist kontraproduktiv.

also das Self-Forum zwischendurch finde ich immer wieder sehr
entspannend ... ;-)

Bisher merke ich nur, daß sie HTTP wirklich drauf
haben. Viiiiiel besser als ich ... und daß mod_gzip
wegen des Vary:-Problems sehr viel weniger RFC2616-
compliant ist, als ihm gut tun würde. :-(
Details bitte, Herr Kollege, Details.
...
Nein, das weiß ich schon, geht's evt noch genauer? ;-)

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44
http://www.w3.org/Protocols/rfc2616/rfc2616-sec1.html#sec1.2

mod_gzip ist nur 'conditionally compliant', weil es das SHOULD-
Requirement für den Vary-Header nicht erfüllt.

Viele Grüße
      Michael

[Christoph Zurnieden]

Hallo,

Also ich weiß ja nicht, aber Pause sollte Pause bleiben.
Die auch noch mit Arbeit zu füllen ist kontraproduktiv.

also das Self-Forum zwischendurch finde ich immer wieder sehr
entspannend ... ;-)

Gut, diesem Argument ist nichts entgegenzusetzen ;-)

Bisher merke ich nur, daß sie HTTP wirklich drauf
haben. Viiiiiel besser als ich ... und daß mod_gzip
wegen des Vary:-Problems sehr viel weniger RFC2616-
compliant ist, als ihm gut tun würde. :-(
Details bitte, Herr Kollege, Details.
...
Nein, das weiß ich schon, geht's evt noch genauer? ;-)

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44
http://www.w3.org/Protocols/rfc2616/rfc2616-sec1.html#sec1.2

mod_gzip ist nur 'conditionally compliant', weil es das SHOULD-
Requirement für den Vary-Header nicht erfüllt.

Nunja, SHOULD != MUST, aber er sollte dann doch mit rein ;-)
(*klonk* sagt das 2 EUR Stück im Wortwitzkassenschweinchen)

so short

Christoph Zurnieden

[Kai Lahmann]

hi

Das wäre traffic-sparender, wenn die Besucher oft Caches validieren -
was sie eigentlich nicht tun sollten, weil gzip_cnc ihnen 'lange' (aber
konfigurierbare) Expires-Header zu senden versucht ...

mal ehrlich, wie sehr werden die Expires-Header eigentlich so gemeinhin beachtet?

... oder in mod_gzip eine geänderte Regelanalyse einbauen, weil es mit
der bisherigen niemals richtig HTTP/1.1 wird unterstützen können ...

kannst du dazu näheres erzählen? Würde mich mal allgemein mal interessieren, was Apache und die gängigsten Module da noch so an Macken mitschleppen

ich könnte mühelos einen Stab C-Programmierer beschäftigen ... ;-)

*gg* damit bist du nicht alleine :)

Grüße aus Bleckede

Kai

[Michael Schröpl]

Hallo Kai,

mal ehrlich, wie sehr werden die Expires-Header
eigentlich so gemeinhin beachtet?

wenn die Browser die richtige Caching-Strategie ein-
gestellt haben ("automatisch"), dann gehen die HTTP-
304 dramatisch zurück.
Wenn nicht, dann sind Benutzer, die bei über 80% (!)
ihrer Zugriffe HTTP-304 bekommen, ein gutes Erkennungs-
merkmal für "immer prüfen" bei Dokumenten mit vielen
kleinen Markierungsbildchen ...  (ich habe in der
Serverfarm die Möglichkeit, Zugriffe zuverlässig nach
Personen zu filtern.)

Ich hatte noch im Frühjahr im Schnitt 35% 304er.
Nach dem Senden sinnvoller Expires sank der Wert auf
24% (ohne jede aktive Aufklärung der Benutzer - das
müßte ich auch mal machen, per Artikel).

... oder in mod_gzip eine geänderte Regelanalyse
einbauen, weil es mit der bisherigen niemals
richtig HTTP/1.1 wird unterstützen können ...
kannst du dazu näheres erzählen?

Es ist das hier schon mehrfach beschriebene Problem:
Solange mod_gzip keinen vernünftigen "Vary:"-Header
sendet, kann Squid etc. nicht begreifen, ob und wie
er komprimierten Content cachen darf.

Und da Squid in Version 2.5 nun tatsächlich das Cachen
von Negotiated Content in voller Breite implementiert,
wäre es um so dringender ...

Viele Grüße
      Michael

[Kai Lahmann]

hi

wenn die Browser die richtige Caching-Strategie ein-
gestellt haben ("automatisch"), dann gehen die HTTP-
304 dramatisch zurück.
Wenn nicht, dann sind Benutzer, die bei über 80% (!)
ihrer Zugriffe HTTP-304 bekommen, ein gutes Erkennungs-
merkmal für "immer prüfen" bei Dokumenten mit vielen
kleinen Markierungsbildchen ...  (ich habe in der
Serverfarm die Möglichkeit, Zugriffe zuverlässig nach
Personen zu filtern.)

gibt's Verrückte, die auf 'immer prüfen' stellen?!? Ich hatte schon überlegt diese Funktion aus meiner Mozilla-Distribution zu werfen - einige "geht nicht" gehen leider auch auf (absichtlich?) derartig absurd eingestellte Prefs zurück - XUL-Debuttting ist da auch ein Heißer Kandidat - oder Cache ganz (!) aus....

Es ist das hier schon mehrfach beschriebene Problem:
Solange mod_gzip keinen vernünftigen "Vary:"-Header
sendet, kann Squid etc. nicht begreifen, ob und wie
er komprimierten Content cachen darf.

/me wird dann wohl morgen mal das Archiv konsultieren...

Grüße aus Bleckede

Kai

[Michael Schröpl]

Hi Kai,

wenn die Browser die richtige Caching-Strategie ein-
gestellt haben ("automatisch"), dann gehen die HTTP-
304 dramatisch zurück.
gibt's Verrückte, die auf 'immer prüfen' stellen?!?

natürlich. Und vor allem dann, wenn sie eine Dienstleistung nutzen,
die ihnen realtime-Börseninformationen liefern soll (unsere nämlich).

Auf die Idee, daß wir uns natürlich selbst darum kümmern müssen, daß
unsere Seiten von niemandem gecached werden, und deshalb passende
HTTP-Header mitsenden, kommt von den DAUs so leicht keiner - einige
haben die Panik, veraltete Informationen geliefert zu bekommen ...

Und die Dokumentation zu "automatisch" bzw. "when the page is out of
date" sieht in meinen Augen nicht so aus, als ob der Benutzer sie
begreifen könnte.

Bei Mozilla 1.1 stimmt ja nicht mal der Text zwischen dem Konfigu-
rationspunkt und der Online-Hilfe (wo noch "automatisch" steht ...)
überein ...

Automatically: Select this if you want Mozilla to compare a web

page to the cache when the page is determined by the server to

haved expired.

(ist das "haved" ein Teppfuhler?)

Im Vergleich zum M$IE 5.5 ist der Text immerhin schon großartig. ;-)

Was an dieser Stelle aber insbesondere fehlt, ist, daß der Browser
auch in diesem Falle immer noch HTTP befolgt, also Pragma, Cache-
Control, negative Expires-Werte, ... es sollte dringend ein Hinweis
dort stehen, daß (und ggf. wie) der Server die Aufbewahrungsfristen
von Seiten im Cache beeinflussen kann und sich der Browser vorrangig
an HTTP halten muß und nur in gewissen Spielräumen selbst bestimmen
darf, ob eine Seite in seinem Cache liegen darf und ob er einen
neuen Request senden muß.

Viele Grüße
      Michael

[Christian Kruse]

Hallo Christoph,

Da habe ich heute mittag noch auf die Schnelle Deinen Perlcode nach C portiert
und in gzip_cncc reingefummelt

Ja, den habe ich heute bekommen (ich rufe meine Privat-Mailbox immer nur einmal
am Tag ab und am WE im Moment gar nicht, ich hab einen gesperrten
Telefon-Account). Gleichzeitig ist eine Mail von Michael hierher geflattert, die
erzaehlt, dass sein Patch das Problem nicht loest...

(Und dem Christian gesandt. Keine Antwort, habe allerdings auch keine
erwartet)

Das tut mir leid. Aber ich bin im Moment einfach zu ca. 100% ausgelastet. Da
dauert es einfach etwas laenger.

BTW: schon durchgelesen?
http://interviews.slashdot.org/interviews/02/09/06/1343222.shtml?tid=145

Noe, und bis ich dazu komme, wirds auch noch etwas dauern.

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Ganz übersehen, 'tschuldigung.

Da habe ich heute mittag noch auf die Schnelle Deinen Perlcode nach C portiert
und in gzip_cncc reingefummelt

Ja, den habe ich heute bekommen (ich rufe meine Privat-Mailbox immer nur einmal
am Tag ab und am WE im Moment gar nicht, ich hab einen gesperrten
Telefon-Account).

Was ist denn da ...?
Ach was, geht mich ja gar nix an.

Gleichzeitig ist eine Mail von Michael hierher geflattert, die
erzaehlt, dass sein Patch das Problem nicht loest...

War ich mal wieder zu voreilig, was? ;-)
Aber war auf den ersten Blick recht plausibel. Hinterher habe ich dann auch festgestellt, das es weitere Problem gibt, hatte nur zu wenig Zeit, mich intensiver damit zu bechäftigen.

(Und dem Christian gesandt. Keine Antwort, habe allerdings auch keine
erwartet)

Das tut mir leid.

Nein, ich habe wirklich keine erwartet.
Du kannst also die Asche aus Deinem Haupthaar wieder entfernen ;-)

Aber ich bin im Moment einfach zu ca. 100% ausgelastet. Da
dauert es einfach etwas laenger.

Wie wäre es mit einem zweitem Prozessor? >;->

"Schöler Zurnieden! Konjugieren sie "delegieren"!"
"Ich delegiere."
...
"Und? Weiter bitte?"
"Weiter brauchte ich noch nie."

;-)

BTW: schon durchgelesen?
http://interviews.slashdot.org/interviews/02/09/06/1343222.shtml?tid=145

Noe, und bis ich dazu komme, wirds auch noch etwas dauern.

Das ist schade, würde Dich wahrscheinlich interessieren.

so short

Christoph Zurnieden

[Christian Kruse]

Hoi,

Ganz übersehen, 'tschuldigung.

Ich bin zutiefst getroffen! ;)

Was ist denn da ...?
Ach was, geht mich ja gar nix an.

Perl Mail dann :) Is nix fuers Forum.

Du kannst also die Asche aus Deinem Haupthaar wieder entfernen ;-)

*schuettel* *riesel* ;)

Aber ich bin im Moment einfach zu ca. 100% ausgelastet. Da
dauert es einfach etwas laenger.

Wie wäre es mit einem zweitem Prozessor? >;->

Den hatte ich erwartet. Gut konditioniert![tm]

"Schöler Zurnieden! Konjugieren sie "delegieren"!"
"Ich delegiere."
...
"Und? Weiter bitte?"
"Weiter brauchte ich noch nie."

;-)

*g* Der war mir allerdings neu

Noe, und bis ich dazu komme, wirds auch noch etwas dauern.

Das ist schade, würde Dich wahrscheinlich interessieren.

Ups, ich hab ja freie Zeit (ich darf auf Kollegen warten). Na, dann dauerts
doch nicht so lange :)

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

"Schöler Zurnieden! Konjugieren sie "delegieren"!"
"Ich delegiere."
...
"Und? Weiter bitte?"
"Weiter brauchte ich noch nie."

;-)

*g* Der war mir allerdings neu

Der fiel mir so ein.
Hat aber bestimmt schon jemand anderes früher gebracht. Würde mich wundern, wenn ausgerechnet ich einen neuen Witz erfunden hätte ;-)

so short

Christoph Zurnieden

[Michael Schröpl]

Hallo Leute,

es gibt nun wieder ein Download-Archiv von gzip_cnc,
in der Version 1.11.

Gegenüber dem bereits veröffentlichten Quelltext habe
ich nichts geändert (für Christians viele gute Ideen
ist jetzt nicht der richtige Zeitpunkt); ich habe vor
allem die Dokumentation erheblich erweitert und bitte
Anwender darum, sich das neue Kapitel über Sicherheits-
aspekte gründlich zu Gemüte zu führen.

Falls mir ein wenig Zeit zuläuft, wird es in Kürze ein
weiteres Release mit Christians Verbesserungen geben -
aber ich will jetzt erst mal das Sicherheitsproblem in
den Griff bekommen (mal sehen, was die Apache Group
dazu beisteuern kann).
Neue Features einbauen kann man nachher immer noch.

Viele Grüße
      Michael