Message-ID: <033b01c38d32$78215f00$3200000a@pluto>
From: jkuperus at planet.nl (jelmer)
Subject: Re: I have fixes for the Geeklog vulnerabilities

Dirk,

Ok let me get this straight, basicly what your saying is,
He's correct on one point the xss issue, and the others might possibly
affect mysql 4.1" (it does)
and then you go about and tell him how he wasted everybodys time
So if it affects only 1% of your userbase its not an issue and you shouldn't
be reporting it ?
even on mysql 3 its probably posible to constuct some url that will suck up
a lot of resources

on your site you claim Three members of the Geeklog development team have
now been trying to reproduce
these issues and failed, wouldn't your time have been better spend *fixing*
these issues,
it's hardly rocket science. why wait until someone comes up with a clever
way to exploit it. It's obviously
a risk why wait until it becomes a threat

IMHO you've got the wrong attitude. Anyway I am not done yet
I don't normally "do" sql injection but beeing anoyed with your response as
I was i took a quick
look at this geeklog, and I was stunned at how insecure it was

- It by default stores the password hash in a cookie, you cant turn that off
- you dont have to enter your old password in order to change it

this means that any xss issue in this site will lead to compromises of
accounts, you can steal the
hash and userID place it in your cookie, log in and voila, if you do this
you have to be *EXTREMELY*
wary of xss issues, well your not, you can find these all over the place

all the classics just work like

<img src="javascript:alert()">

<b style="background-image: url(javascript:alert(document))">test</b>

in the forum, I wont even bother listing all the issues

parameters passed in urls that get inserted into queries get sanitized
hardly anywhere ,
I attached a python script that should crack any users account  who ever
posted to the forum's in under half an hour,
just get the hash stuff it and the acomanying user id in a cookie, get to
the site and change the password
The exploit is rather messy and I haven't tested it too thorougly but it
should work (i think :) )  note this is a seperate issue as the ones
reported by Lorenzo. but again these issues all over the place


--jelmer




----- Original Message ----- 
From: "Dirk Haun" <dirk@...n-online.de>
To: <full-disclosure@...ts.netsys.com>
Sent: Sunday, October 05, 2003 11:03 PM
Subject: [Full-Disclosure] Re: I have fixes for the Geeklog vulnerabilities


> Lorenzo Hernandez Garcia-Hierro wrote:
>
> >Due to the completely incorrect treatment and work of the Geeklog
> >development team , that they don't developed fixes for THEIR product
>
> As a member of the Geeklog Development Team, I'd like to point out that
> the poster of the above lines did not bother to contact us, both with his
> original findings, nor with these patches. Talk about incorrect treatment.
>
> Furthermore, of the original findings (posted here and on BugTraq a week
> ago), only the Shoutbox issue has been confirmed (and a patch is
> available on the Geeklog website).
>
> None of the supposed SQL injection issues that Lorenzo Hernandez Garcia-
> Hierro claims to have found could be confirmed by us or members of the
> Geeklog community. We can only assume that he only noticed that when
> attempting to inject SQL into URLs, Geeklog would produce SQL errors and
> from that he seems to have deduced that Geeklog was vulnerable for SQL
> injections. When asked to explain his findings, he couldn't (or wouldn't)
> come up with a working example either.
>
> Now, there's no doubt that Geeklog could do a better job in filtering
> these attempts. Work on that is currently under way - which we would have
> told Lorenzo Hernandez Garcia-Hierro if he had bothered to contact us.
>
> Potential problems that we have found so far:
>
> - the SQL error message displayed by Geeklog could, in theory, leak
> sensitive information
> - sites where the PHP magic_quotes setting is OFF are slightly more prone
> to the (alleged) injections then when it's ON
> - sites running on MySQL 4.1 (which is currently in alpha state and not
> ready for production use) are at a higher risk since MySQL 4.1 allows
> concatenation of SQL requests (which previous versions didn't)
>
> We have informed our users about these issues on the Geeklog homepage and
> will continue to do so. We value security very highly, but we prefer to
> handle it in a non-sensationalist way. We would have prefered to come up
> with a solution to the problems and then post a detailed analysis of the
> problems here (and on BugTraq). With his failure to contact the
> developers, Lorenzo Hernandez Garcia-Hierro has yet again caused more
> confusion than actually helping the situation.
>
> Overall, this is a textbook example of how NOT to handle security issues.
> By not contacting the developers, posting a report full of inaccuracies,
> and, in the end, mostly non-working examples, Lorenzo Hernandez Garcia-
> Hierro has caused uncertainty and confusion amongst the Geeklog users and
> basically wasted everyone's time, including that of the developers.
>
> Dirk Haun,
> Maintainer of the Geeklog 1.3.x branch,
> Geeklog Development Team
>
>
> -- 
> http://www.geeklog.net/
> http://geeklog.info/
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: geeklog.py
Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031008/07bbdbcd/geeklog.ksh

Powered by blists - more mailing lists