| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <OFFD30122A.789CCA02-ON86256DB9.005B86BA-86256DB9.005D909F@equitable-of-iowa.com>
From: Chris.Kulish at us.ing.com (Chris.Kulish@...ing.com)
Subject: Re: I have fixes for the Geeklog
vulnerabilities
Let me start off by saying that I am NOT a geeklog developer. I would also
like to mention, like any project, alot of this code was inherited by the
developers and they have been working hard to squash security bugs when
notified properly. Give the developers a chance to keep their users
secure.
Comments in line:
-----
Chris Kulish
Systems Engineer
ING Advisors Network
chris.kulish@...ing.com
Ph. 515.698.7583
Fx. 515.698.3583
"There's more to living than only surviving"
"Maybe I'm not there, but I'm still trying"
-- The Offspring
-----
jelmer
<jkuperus@...net. To: "Dirk Haun" <dirk@...n-online.de>, full-disclosure@...ts.netsys.com,
nl> bugtraq@...urityfocus.com
cc: (bcc: Chris Kulish/BDN/ING-FSI-NA)
10/07/2003 07:23 Subject: Re: [Full-Disclosure] Re: I have fixes for the Geeklog vulnerabilities
PM
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
---
First, if you cant reproduce a problem, how can you expect to fix it? It's
not rocket science, you are correct. Even so, why not approach it
properly?
---
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
---
I've been annoyed at the disclosure as well. People need to contact the
developers *FIRST*, before running at the mouth, for a number of reasons.
To confirm the installation environment of the elleged security breach. To
let the authors attempt to reproduce it accordingly. To not compromise the
userbase that can't do anything about it until the programmers are done.
Shall I go on? Yes, geeklog has security issues, name one piece of
software that doesnt.
---
- 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
---
And 90% of geeklog sites are non-ssl, so what's your point? The username
and password pairs are already transmitted in cleartext. Remember what
geeklog is geared towards, blogging. This isn't a HIPPA qualified
application, nor was it meant to be.
---
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
---
And did you contact the developers about this before emailing the security
lists? Let's *ALL* be responsible about discloser. It's not just the
developers that have to be repsonsible about security
---
--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
(See attached file: geeklog.py)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: geeklog.py
Type: application/octet-stream
Size: 4517 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031008/89045f7e/geeklog.obj
Powered by blists - more mailing lists