Geeklog Forums

This is not in a negative sense, but it is now getting very difficult
almost impossible to keep up with the security issues.

The best part of GL in comparison to various other CMSes has been said to
be its security AND almost atregular interval security flaws are being detected.
This I agree is the norm with any software but then no one has so much
ensurances and claims on "security" !

When I went thru pains of shifting from 1.3.9 thru 1.3.11 to 1.3.11sr1
( mind you that we use plugin and customizations and it makes the situation
all the more difficult, at times impossible, though developers will say its none of their concern )
I thought , well, now I can settle and manae contents rather than my cms system.
Incidentallt .11sr1 fixed already some SQL injection and I am now :angry: that
Stefan Esser did not find it all.

Now that Bercegay finds some more I wonder what next !
Can some one please help me now IF they accept the fact that I cannot move
beyond .11sr1 and already have many changes in various files so that I cannot
replace files.

1) What is the REAL possibility of SQL injection causing problem ?
2) What are the things that I can avoid ? For example , I can do without SPamX
plugin and I can do withour Search. Does it reduce my chances of vulnerability ?
3) Some quick and dirty fixes eg, some htaccess or similar file to give
protection without having to touch files ?
4) I can keep the site ONLY for registered users, no anonym inputs
5) others ... ?

[ BTW - can some one say in one or two words *how* they do these injections ?
Though not geek, may be some very simple prevention may be found ..]

It will be very much appreciated that if "geeks" here appreciate that many
very ordinary human beings use GL and they *needed* changes like skin, plugins
so they change the GL they use,and once changed they have to manage the site
rather than the software as they are really not geeks. Saying them "you have to
DO this and this ONLY" or "go elsewhere" is disappointing !!

First of all, let me start by saying that I don't want to downplay the recent security issues found by James. I actually had an item "check that we don't trust values from cookies too much" on my to-do list for quite a long time, which makes this all the more embarrassing.

But I think you're overstating things a bit when you say that "almost at regular interval security flaws are being detected". Let's have a look over the recent security issues:

1.4.0sr1 [2006-02-19]
A serious one, no doubt. Technically, it's the combination of two minor flaws that results in a big one. Needs a somewhat sophisticated attack to exploit, but the consequences are frightening.

1.3.11sr3 [2005-12-18]
Two minor flaws. The one about being able to post comments to stories you can't see could be considered merely an annoyance, but since it's bypassing our permission system, we filed it under security. Still, there's no way that this could be used to do any serious harm to your site.

The other issue is an "information leakage". It was possible to find out in which path your Geeklog install resides on your server. Not an immediate problem, but the information you could gather that way could come in handy for other attacks.

1.3.11sr2 [2005-10-08]
The important one in this release was the introduction of a speed limit on login attempts. This is to slow down dictionary attacks. A good password will always be a much more effective protection against those, but we shouldn't make the attacker's life any easier nonetheless.

All the other changes in this release were about spam protection. Spam is annoying but not a security issue per se and not something that can seriously damage your site.

1.3.11sr1 [2005-07-03]
That was another big one, no doubt.

So, let's see: We've had a serious issue right now, a medium-risk issue four months ago, and another serious issue seven months ago. That's not as good as I'd like it to be, but not that bad either. I don't want to use the old "at least we're not as bad as the others" excuse, but if you do compare the track record of other open source or commercial projects, you'll find us in good company. Try reading Bugtraq for a while to get a feel for the frequency of occurence of security issues in certain products.

To phrase it the other way around: It is because we do take security seriously that we release security updates relatively often. We'd rather release a fix for a minor issue ASAP than put our users and their sites at risk.


Now, the issue of updates. We always provide support for the current version plus the previous one (currently 1.4.0 and 1.3.11). We do provide upgrades that are usually just drop-in replacements, i.e. upload the fixed files and you're done. This, I would guess, works just fine for more than 90% of our users.

When you modify Geeklog's core code, obviously, you'll have more work to do to merge in those changes. We generally discourage modification of the core code and do our best to provide lots of hooks for custom code (plugin API, lib-custom.php, etc.). If you think there's a hook missing somewhere, talk to us and we'll see what we can do.

But you have to understand that you're on your own when you modify our code. Still, if you're able to modify the code, you should also be able to figure out our fixes. Our CVS web frontend, for example, has that handy diff feature that will highlight changes in the files.

If, to pick up your example, you insist on staying with your modified version of 1.3.11sr1 you can download the 1.3.11sr4 upgrade and compare the files in there with your copies. You'll find that the modifications are restricted to certain areas of the code (e.g. in lib-common.php), so with the PHP knowledge that you obviously have, it should be easy to merge your modifications and ours.

bye, Dirk

Thanks ! That was a helpful info and much in the positive spirit.

I am not sure if this has been already answered :

what is the *real* risk to an average webmaster ? has there been serious cases *actually* happening ?? ( if one does no upgrade )

Thanks & best regards .

Forgive me if I am speaking out of turn here as I am not a security expert. However, I've had a lot of experience with 'hackers' attacking websites that I either own, manage or helped get established.

Several of my earlier experiences with 'hackers' came with other php CMS systems (think large atomic bombs). My sites were selected through seemingly random google searches. It took the 'hacker' only a few seconds to destroy something I had worked on for months. Sadly, this happened more than once.

In today's world of highspeed internet and hugely accurate google results a 'hacker' can identify your site as a target by looking for things like "GL Version Test (1.3.11)" (12,200 hits). Then run some scripts against the sites that come up in the results.

The whole process may take the 'hacker' a few minutes as he goes from site to site plying a script someone else made to take advantage of a security exploit.

Maybe he will never make it to your site.

Maybe your site will be the first on his list.

How much more work are you going to have to do AFTER it has been hacked and destroyed. The DB wiped clean (when did you last do a complete backup? And have you ever tried to restore the site from backup?) and everything can be gone in seconds.

There is no rhyme or reason as to why these jerks do what they do. It will never make sense.

If you think you've worked hard on your site up to this point, wait until it gets screwed up by one of these exploits.

/Begin Public Service Announcement Mode

You NEED to find a way to upgrade to the most recent, most secure version of GL (period).

/End Public Service Announcement Mode

P.S. - I have had a lot of trouble with those annoying 'comment' spammers and 'referrer' spammers with GL and I determined that it was mostly because I was using the Visitor Stats plugin that showed up in google searches. I have about 7 different GL sites up and I've only had problems with those that show up in google. I changed the permission on the visitor stats block so it doesn't show up to anonymous browsers (and search engines).

Google is the enemy!

well ..... does it not give one clue ... a workaroundway since even the latest security patch does not *make* you really safe as tomorrow another Dick or Harry is going to find another hole just it has been happening with GL, albeit "less frequently"

If the risk is *real* the loss is *real* to an user how less it may happen compared to other cms ...

so as I was saying, easy workarounds ? what about confuse the search results ? like :

remove GL or similar words in entirity
- can some suggest which files to remove
- not submit or making robot text not to index certain files or whole stuff, instead making another "door" page for search submissions

locking my house is a good idea, purchasing better and newer locks is also very good but what about completely hiding / masking my house under some camoflag ???

That's all fine if you're defending against what I offered as an example.

You cannot rely on security through obscurity because eventually someone will discover that you're sitting there unpatched and vulnerable.

Good luck.

Just a note: Andy's search string doesn't return what you think it does. Try it and carefully check the results ...

The text "GL Version Test (1.3.11)" will never be picked up by a search engine, as it is part of the Admin block that is only displayed to admins and not to search engine bots, which are anonymous users.

We do, however, recommend that you remove the Geeklog version number from your footer.thtml, should you still have it there (like many old themes did). The robots.txt that we're now shipping with Geeklog also provides some mild protection, as it tells search engines not to index certain pages (although that's mostly targetted at spammers, not hackers).

Overall, however, Andy is right: Don't rely on security by obscurity. Upgrade already!

bye, Dirk