Ich hatte ja bereits vor längerer Zeit angemerkt, dass SquirrelMail mit konfiguriertem Suhosin-Patch nicht richtig läuft. Und da seit einem Jahr, wo der Bugreport nun Upstream bekannt ist, immer noch nichts passiert ist, gibt es hier für alle geplagten nun ein Diff-File zum Ersparen der ganzen Tipparbeit (Ja, der Patch ist grundlegend REINES Copy&Paste). Zumal ja durchaus schon die Grundlagen für eine Lösung ohne /e vorhanden sind. (more…)
Nach dem ich mich seit meinem finalen Entschluss, Windosen nur noch mit dem Dosen-Öffner und einer Linux-CD zu behandeln, gab es inzwischen in meinem Umfeld erste Umsteiger in Sachen zu betreuender Rechner. Aufgabe war es, ein Notebook für den Einsatz für Office-Arbeiten und einfache Buchhaltungsaufgaben fertig zu machen. Da es gewisse Altlasten zu beachten gab, gestaltet sich der Umstieg jedoch nicht ganz reibungslos, auch wenn das Grundsystem mit Office und Browser tadellos läuft, und abgesehen von kleineren Quärelen mit dem HAL im Zusammenspiel mit dem Plasma-Desktop derzeit kleinere Work-Arounds benötigen.
Ein größeres Projekt stand jedoch die Tage an: Für die Finanzverwaltung sollte WISO Sparbuch 2010 eingerichtet werden, damit die bestehenden Daten gepflegt und ergänzt werden können. Da das Programm für Linux nicht verfügbar ist, und auf den Einsatz einer VM aus Resourcengründen vermieden werden soll, fiel die Wahl auf Wine, was bereits seit längerem als durchaus brauchbare Alternative zum Einsatz virtueller Maschinen mit Paravirtualisierung oder Vollvirtualisierung gelten kann. (more…)
Wer auf seinem Server SPF einsätzt, oder eMails von anderen, die SPF einsätzen weiterleiten will, der hat es mit Postfix derzeit noch etwas schwer. Es gab zwar bereits vor längerer Zeit einen Patch für Postfix 2.1.4, der SRS direkt in Postfix integriert und der auch nahezu vollständig konfigurierbar war, jedoch hat es dieser Patch nie in die aktuelle Distribution geschafft, weshalb man die für SRS nötige Funktionalität in aktuellen Postfix-Versionen vergeblich sucht.
Einzig durch längere Suche auf der Seite des libsrs2-Projektes findet man unter Umständen Abhilfe. die dort vermerkten Konfigurationshinweise beziehen sich jedoch auf oben erwähnten Patch, weshalb sie für die Nutzung nicht tauglich sind. (more…)
Eigentlich hat mal wieder alles wie üblich harmlos angefangen. Eigentlich ging es mir nur darum, die Funktionen von RRDTool in meinen Scripten nutzen zu können, ohne auf Prozesssteuerbefehle wie system, exec, popen & Co. zurückgreifen zu müssen, da diese auf meinem Server aus gutem Grund deaktiviert sind. Dafür begab ich mich nun auf die Suche, ob es für PHP ggf. bereits eine entsprechende Extension gibt und wurde auch recht schnell fündig: Für PHP4 hatte bereits vor mehreren Jahren jemand sich die Mühe gemacht und eine entsprechende, kleine Erweiterung geschrieben. Glücklicherweise ließ sich diese (nach Download der benötigten Header) auch problemlos für PHP5 compilieren. Da die Dokumentation wie üblich aus dem bestand, was der C-Compiler zu gesicht bekommt, hab ich natürlich einen Blick dorthinein geworfen und musste feststellen, dass eine Reihe von Funktionen, insbesondere das Dumpen von RRD-Files, das Lesen von Infos und ein paar der neueren Funktionen von RRDtool bisher nicht über die Extension ansprechbar waren. (more…)
Mehr oder weniger aus eigenem Interesse habe ich die Tage einmal nach einer Möglichkeit gesucht, die Funktionalität von Mailgraph und Bindgraph, die auf meinem Webspace werkeln, mit einem eigenen PHP-Skript nutzen zu können. Diese Scripte nutzen beide RRDTool, also so ziemlich der Standard in dieser Hinsicht. Bindings sind auch für Python und Perl vorhanden – jedoch für PHP gibt es kein offizielles. Durch einen Blogeintrag bei IONCANNON, der zugleich eine einfache Einführung in die Nutzung gibt, bin ich auf einen etwas älteren Versuch aufmerksam geworden, mit dem jemand eine solche Möglichkeit geschaffen hat. (more…)
Ich hatte ja letztens erwähnt, dass mich das Ausbleiben von Benachrichtigungsmails bereits stutzig gemacht hat, dass irgendwas nicht stimmen kann … Und nun ist auch amtlich was: Beim Einspielen eines Patches wurde apticron mal eben seiner Hauptfunktionalität reduziert: Das Versenden von Benachrichtigungsmails. Braucht ja auch keiner: Weil ich kenn absolut niemanden, der Apticron für soetwas seltsames wie Benachrichtigungen über neue Updates verwendet. Das einzige, wofür man überhaupt apticron jemals einsetzen würde, wäre als komfortablerer Weg apt-get update auszuführen. (more…)
As I mentioned in an earlier post, that wasn’t the full story yet. So I’ll now keep my promise and will add the rest of the story and the missing informationen. (more…)
In May, June, July and August Milian and me were working on rewriting and optimizing some parts of the parser which caused a lot of performance gains, but also some trouble as I notice now. The problem is less that the code got broken somehow and fixed in some way again – which it sure got 😉 – but that it’s hard to reproduce how we did the fixing back then.
So what I’m refering to is a problem Secunia noted two releases after the initial patch for it. Back in GeSHi 1.0.7.22 there existed a problem, that could cause GeSHi to go into an infinite loop – I already reported about this on the news page twice. In GeSHi 1.0.8 this issue was fixed and after the release an advisory asking for an update was issued. In 1.0.8.1 work mainly concentrated on fixing the bugs in 1.0.8 thus no major work was done on the parser. The only big news in that version was a fix to a bug that had been in GeSHi since its early days and although I explicitely said there’s no real use for it in an attackers point of view Secunia started to report it which got the stone rolling.
Three days later – on the 3rd of November – I got mail from Romain Beauxis from the Debian Maintainance team caring about the php-geshi package asking me about details on the report filed by Secunia. I didn’t instantly recognize it as the bug I fixed in 1.0.8.1 but when I finally did looked up the patch I had applied back then – which was quite easy as only a few lines changed and I exactly remembered where – and sent back my answer; including a remark they should concentrate on the 1.0.7.22 bug more as that one was the more critical of both – even though Secunia didn’t even feel like mentioning it.
And that’s wher the work begins and the real trouble starts. Although I have an easy testcase there appeared a lot of questions; „What was the patch?“ being the most interesting while the least answerable of all. So the research began, only having some little hints like the approximate date of the fix, probable revisions falling in that time, the approximate place within the GeSHi source (which is about 500 lines that could be THE place!!!) and the beforementioned testcase
Following up on the mail discussion I had with the package maintainers at Debian some more details reentered the scene which shrinked the space of solutions some more. Within the changes there often have been minor changes where only few lines changed – including some changes where only formatting got changed to ease reading. All in all, about 150 revisions felt into the given range of dates, where still about 50 revisions did change geshi.php in some way – most of them affecting the faulty routine.
Besides the mentioned formatting changes there were structural and functional changes – like a new aspect of the parser getting implemented or the way some old task was performed getting optimized. If you simply skipped over the different patches there was one revision that sent out some strange „feeling“ when you read its commit comment- though you couldn’t really verify if it was the given one commit we were looking for.
So at first there had to be some look on the parts that could be affected. In parse_code there only were two loops that could easily get into hanging if you weren’t cautious enought. The first was the loop looking for the strict code blocks withing the source and the second being the loop for highlighting one such strict code block by stepping through it. And that’s where memories and luck popped in. Inspired by a mail from the Debian maintainers I where Nico Golde simplified the view on the first of the mentioned loops, I suddently remembered that Milian and me fixed some positioning code that was there to tell GeSHi where to continue after it found certain patterns. So I rechecked that portion of the code Nico had simplified in the version that was released and found the same oddity I just stumbled upon in the simplified code if Nico.
In the end I wrote a small test script and single-stepped it in the debugger … and there it was: The debugger looped exactly where I expected it to do when I was using the testcase. Given that all summed up and I verified the revision those lines were last changed: Exactly the revision I already felt strange about when I first had a broad view on that issue one week earlier.
Current state is that my findings are on their way to Nico Golde and Romain Beauxis and hopefully into an patched version 1.0.7.22-2 soon!
To sum things up on the problem you could say the following: Even if there is a patch, and you know the issue, it’s not always as simple to bring both information together as sometimes the glue for both is missing as not every issue forcibly has an ID in the bugtracking system – sometimes intentionally and sometimes because you missed to do so. What was the case with this particular issue is hard to say especially when taking into account, that you aren’t always free on your commit comments as giving to much details there might help the bad guys to be faster while being to unspecific might let you loose the connection between the comment and the problem you solved.
Remains some last topic: Why didn’t the Debian guys simply update: After some mail exchange that question was answered: They simply couldn’t as there was a feature freeze in effect prohibiting them from including any patch that added or removed any feature from the package only leaving the way open to (important) patches that focussed on correcting security issues like both the Denial of Service problem in 1.0.7.22 and the Remote Code Execution in 1.0.8 had been. And even though there had been attemps to get the newer release 1.0.8.1 into Lenny – which would have saved a lot of work – none of them was successful making up just much more work than there would have been necessary in the first place.
If you do your work later it not only gets more and harder, it also will involve much more power of others than necessary if it was done in time.
P.S.: Sorry for not being specific on some topics – I promise to get back on the details as soon as the Debian people have fixed the problem in their package.
Powered by WordPress