I drank tea, drank Chinese tea, and drank Japanese tea:
while each thinking of person's situation.

I built up new topic for speaking it having been made think by this matter.
Where is the problem? (report, advisory, and the mediation of the security bug)

Please give the discussion and the suggestion.

Thanks,

And I think whether there was incomplete preparation for reception
of the security report in the XOOPS community in Japan.
Though the vender was in other countries in this case,
It was a user in Japan that used it, and used it on the site in Japan.
We have the receipt entrance and bug-tracking, it corresponds to the
security and the function demand to the XOOPS core and appending modules.
Even if the function demand of the module made by the third party is spoken
in our forum, we don't have the receipt entrance of the security to them.
The report can be able to forget in many cases or are reported
directly by the vender if lucky. It is difficult for the user
to report in the language that is not the mother tongue.
There are such circumstances, too.

# Moreover, a lot of Japanese know the event that a certain Japanese
# was arrested by the police recently because of crossing of the way
# of the security report (If you want to learn it in detail, please
# look for by the key words of "Office" and "ACCS".)

The fate of the delivered report is various.
- It will not have been.
- Time hangs in the answer.
- The fix is quietly done on the vender site.
- It is made public only in a local XOOPS community.
- It is likely to be likely to be notified indirectly or directly
on this site by the vender himself or the third party.

Even if it is a module made by the third party, I want the flow
united a little more. It is easy to use for the developer
and each reporter, and is the certain one.

I think CVE, CERT/CC, and BugTraq to be the unsuitable one
in such a usage.

In the beginning first of all,
I apologize my having a part of the cause causing confusion
by the topic of the matter.
I think that there was being possible to miss each other
of the button from the first start.

In Japan, in the beginning, the security hole is first
made public by SorceForge.JP. Because this matter was
grandly reported by the mass communication in Japan,
We had to behave before a new cracker appeared.
It was said that conformity was top priority in above all.

On the other hand, worldwide,
To some men though this security hole was the already-known one,
it is one month ago in the vicinity that it had been discovered.
Even if late on the third the second, many people did not have
the influence. We were sure to use for that time, and it to be
better to prepare advisory a complete correction.

There is a story that the attempt of the cracking by a similar way
increased actually after that topic in this site.
It is that we were at first anxious.
It is equivalent to increasing the number of new crackers
that the security hole is made public. I think that it is clearly
shown and I am put.

In the range that I understand,
(There is a gap on the first or less at the date because local time has mixed.)

This security hole was reported by the third party in the forum on a certain site on January 17.
(you can find google's cache)
Module author's wjue recognized this problem on the same day.
And, corrected new version 1.2.2 is released on January 28.

A part of site where it does it and back and forth and this module was used:
- SourceForge.jp : on January 21
http://sourceforge.jp/forum/forum.php?forum_id=4153
- Deg-fanclubsued.de : on February 5.
http://www.myxoops.org/modules/newbb/viewtopic.php?topic_id=1899&forum=13
The crackings were tried. The falsification was actually done for Sorceforge.JP.

This report has been submitted addressed to the server manager by the third party on February 3.
Though it seemed to have taken measures on the same day,
there was no report in XOOPS Japanese team at this point.

This matter was suddenly posted in the Sorceforge.JP forum on February 13.
And all users of Sorceforge.JP also got the report by mail.
It was reported in the Slashdot.JP and a part of mass communication in response to this.
-http://slashdot.jp/article.pl?sid=04/02/13/0821250&topic=92
-http://internet.watch.impress.co.jp/cda/news/2004/02/13/2089.html
-http://www.itmedia.co.jp/enterprise/0402/13/epn04.html

We (XOOPS Japanese team) began investigating panicking, it tempered with the influence level to XOOPS in Japan, and it announced to public by news in the exception on February 13.
-http://www.xoopscube.jp/modules/news/article.php?storyid=195
And, because the part where the correction was insufficient was discovered by 1.2.2 when investigating,
The report was submitted from Onokazu to Module author's wjue.
Therefore, we think the posted patch code to be a temporary, to the private patch.

GIJOE - he is not member of XOOPS Japanese team - started this thread on February 13.
(It is the February 14 actually considerable from announcing to public of Japanese team.)
If GIJOE did not start up this thread, I will have been setting up the thread of this matter first.

The following settlement is in this thread.

# I'm tired to write...

I want to say,
- Do not say that someone is bad.
(Excluding the crackers)
- Let's discuss the problem in the entire XOOPS community.
(I think that the bug tracking and advisory of security are insufficient.)
- A lot of sites where the hole remains still exist.
(Shut your hole early by fix! )

I'm sorry for making you fear. It is likely not to become a problem in a lot of cases.
As wjue and other people say: There might not be worry if it is "register_globals = OFF".

However, I know there are users who are setting it to "ON" to operate another program.
In that case, if they are carefully setting a value proper
in each individual directory, it doesn't become a problem.

We noticed that it is possible to actually happen when still various factors twine.
It is useless only to pray.

I don't know whether he concealed the onokazu's post.
I also think that I have times of the fall in the point
that the link that corresponded immediately afterwards was not shown.
Quote:
It was recognized, "Use of XOOPS" with the first report to our regret in Japan.
This was a very insufficient report though this was not a mistake.
Actually, this problem happens only because the file that corresponds
even if there is no XOOPS is put from a browser on an accessible place.
When the manager is setting PHP beforehand carefully, damage gets off very small.
It alone might not have the influence either.

And, only the content is not stolen, and it is serious in the point
where the falsification - a new security hole is set - is possible.
It is already a reality.
If you use agenda-x and other contents of XOOPS continuously,
it is necessary that you stop them, and move to "temporarily" far-off.
And you should confirm they are not falsified.
I think that such information disclosure to the user
of Agenda-X version 1.2.1 former is at present insufficient.

I separately think that we should discuss about the safety of version 1.2.2 above.
And I hope to be able to offer the topic of the method of safe operation
to not only the module developer but also the operation side then.

It is so. In the great factor in this matter a loose setting
of non-safe mode, the mistake is not found.
# And, I strongly felt that it was not possible to tell various attention
# of an environmental setting in the XOOPS.jp site.

However, it is suddenly posted that crack was done by using XOOPS in SF.jp
and it is submitted to slashdot.jp.
I was considerably surprised because there is no preliminary information, too.

Yesterday, it was posted in the forum that the site of SourceForge.JP had been cracked.
http://sourceforge.jp/forum/forum.php?forum_id=4153
(Japanese)
There was no report to XOOPS japan team before this notice.
And it was making abruptly public for the user.

When this notice was received and the investigation began,
the security hole remained in the corrected one the other (Reported to the vender),
and there must be a possibility that contents have already been falsified by using this hole (1.2.1 former).
Therefore, the post to the XOOPS community had been performed
before information finished being settled.

Being possible to say now,

1. Isolate a pertinent module from web browsers more temporarily than accessible places.
2. Confirm whether there are signs that the cracking was tried to the access log.
3. If signs are discovered, you must confirm whether contents are falsified at once.
(In this case, you must examine the interruption of temporary service.)
4. If it can be confirmed not to be falsified, the service is restarted with a pertinent module isolated.
5. Please wait for the continued information.

It is insufficient only in them.

Because even if they are effective for the cracking in the FUTURE,
they are invalid to the cracking that has ALREADY been done.

The cracker can NEWWRITE/REWRITE the file by using this hole
within the scope of authority of the PHP script.
There is a possibility that the BACK-DOOR has already been made somewhere.
You should confirm no falsification of the file that has been installed
by making good use of the file attribute (timestamp might be camouflaged)
and the diff-tool etc.

Check the request to the following files from your site log
so that you may find signs of the cracking.

- modules/agendax/addevent.inc.php
- modules/agendax/i18n.php
- modules/agendax/config.inc.php
- modules/agendax/admin/admin_header.php

If the request remains in the log, you may think the some crackings have been done.
Because the HTTP request is not necessary for these files, it doesn't usually remain in the log.

The looseness of the server setting for PHP became the factor of the expansion in this case, too.
Please reconfirm the setting of your site once now.
http://www.php.net/manual/en/features.safe-mode.php
- safe_mode
- safe_mode_include_dir
- safe_mode_exec_dir