I looked at this but briefly. The script says your vulnerable no matter what you enter. Not that this proves anything one way or the other. But I refrain from further comments until the jury is in. It smacks of another not so long ago report using the same script nearly word for word that fails on every site I tested at that time.
The weblinks and downloads reports actually concern me more. As they deal with direct injections. And should be fairly easily patched if they aren't already in 6.6 Oh thats right we can't download those fixes because they aren't important enough to release. </sarcasm>
Serously we aren't ignoring these posts but it takes time to test on various systems and frankly lately time is hard to come by for most of us.
One thing you can count on if this is exploitable someone will run it against a major nuke site to get our attention.
it's bugtraq smearing PHP-Nuke's name again. Ignore it, it's a load of c***
AI
NooN Nuke Cadet
Joined: May 30, 2003
Posts: 3
Posted:
Thu Jun 05, 2003 10:25 am
ArtificialIntel wrote:
it's bugtraq smearing PHP-Nuke's name again. Ignore it, it's a load of c***
AI
So we can just ignore it? I run 6.0 site, and just warried about any news that have something to do with exploids and admins password hashes etc...
But if you say - "this is BS" - i will belive you, not that guy who has published this article.
crashoverride
Joined: Jan 31, 2004
Posts: 0
Posted:
Thu Jun 05, 2003 10:37 am
like AI said in the announcement he created just after he responded to this topic, BugTraq dont' seem to know basic SQL syntax and PHP coding, so why anybody trusts their reports is beyond me.
They keep pulling up vunerabilities saying "they can do this, they can do that, they can bla bla bla". An example of which was a certain bit of code not so long ago where they could supposidly hack a site and grab passwords for the admin accounts (there's a topic in the security forum if you want to know specifics), and they were saying it was because of a lack of single quotes ('s) that was causing the error.
However, in SQL, if a variable isn't encased in single quotes, then the SQL server only accepts integers as the input, not text or anything else. In essence, adding hte quotes would introduce the vunerability, not remove it. - good from a site that's supposed to report errors, no?
Anyway. Like I said, details are available in other topics.
CO
MikeMiles Lieutenant
Joined: May 29, 2003
Posts: 231
Posted:
Thu Jun 05, 2003 7:37 pm
BugTraq is just a notification/moderation mechanism whose content comes from outside contributors. BugTraq doesn't verify and validate any reported exploits, and they aren't in a position to do so. That's the project developers responsibility. From my experience on a few open source projects, the contributors are usually quite responsible and contact the developers first with their finds. Through communication, the invalid ones usually never make the list. People will often wait in submitting their find until the developers have a chance to fix it within a reasonable time. For the projects which have a security mailbox and are responsive, they hardly have any entries on BugTraq because they they release security fixes right away when something is found.
In the last report on phpNuke, the submitter said he contacted FB but received no response. If FB would just respond back to these people to verify their finds or explain why they aren't exploits of phpNuke's code, then it would weed out inaccuracies. Shoot, he doesn't even take the time to update BugTraq on whether anything was fixed or invalid. Others have to do it instead.
The one bad thing about BugTraq though is it's a great repository for the script kiddies to use. If it didn't exist, they still would cause havoc but would have to work to figure out the exploits themselves.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
