PART 2
------------------------------------------
1. There are several critical security issues through which SOMEONE
MIGHT HACK AND GET THE FULL CONTROL OF THE SYSTEM. Fortunately these
could only be achieved by forms. However it means that the border
between editor, admin, and superadmin group is void - all potential
formmakers could be the superadmins.

   1) Above all, the login command has an auto value that enables a
member to login without checking password. This enables all formakers
to login the superadmin account by simply adding an "auto". It should
be fixed as soon as possible! By simply modifying the BOLTXlogin
function:

   old: if ((($pass1 == $pass2 || $pass1 == crypt($pass2, $BOLTcrypt))
&& ($pass1 != '')) || ($value == 'auto' )){
   new: if ((($pass1 == $pass2 || $pass1 == crypt($pass2, $BOLTcrypt))
&& ($pass1 != ''))){

   2) When saving data via a form, the system does not properly check
auth.data so anyone can save any data from any page, including the
password of superadmin anywhere. Fortunately saving data can only be
achieved by using form commands. Anywahy, this can be fixed by
modifying a missense line in BOLTauth and after that all attempts of
saving a data must pass the check of site.auth.data.

   old: $check = substr($check, strlen($page) + 2);
   new: $check = substr($check, strlen($page) + 1);

   3) Another leak is that saving a multi-line data is available and
everything except < are stored as original. If someone takes the
advantage and save a multiline data with "\n~\n" into it, he could
hack the admin password. For a symptom relief, I modified by replacing
"\n~" with "\n%7e" so that is still show ~ when achieving data via
{:data} variables.

   Besides, only the first line of a multiline data will be stored in
the index. This does not make security concerns but just annoying.
Thus this problem should be investigated further.

   4) To improve the security and to prevent the users from
accidentally or intentionally sending commands by [text] or other non-
[session] form fields, I modified several lines in markups.php and
engine.php. Now, only [session] would be regarded as commands, and any
form fields with duplicated name will be ignored. For example:

   [form][text msg_1 'test'][text msg_2 'test2'][submit][session msg_1
'blah'][form]

   In the previous versions it displayed 'test' 'test2'. In the
current version it only displays 'blah', since text msg_1 is
duplicated to session, its value is totally ignored.

   5) Also, the Crypt plugin in the solutions of official site adds a
new group called "change_password". So admin's password could be
hacked via it. Adding @owner to password data auth instead would be
better.

2. I don't know if locking superadmins in auth.commands/functions is
what you meant to. But this is dangerous if someone creates a
site.auth.commands without setting something like *: @admin, and he
locks himself from the site. Also, if no group.* pages exists,
superadmins are not considered to be in group admin and editor so that
they cannot pass the auth check of *: @admin.

   Anyway, I modified BOLTFmemberships in functions.php so that
superadmins always have admin,editor,member,guest memberships. It
would be more resonable, I think.

   old: if (! is_array($groups)) return;
   new: if (empty($groups)) $groups = Array();

3. Fixed a missense line in initialization routine in engine.php so
that config blackList works correctly without whitelist set:

   old: if ($BOLTwhiteList != '' && strpos(BOLTloadpage
($BOLTblackList), $BOLTvar['$ip']) !== false) {print_r
($IPblockedHTML);die();}
   new: if ($BOLTblackList != '' && strpos(BOLTloadpage
($BOLTblackList), $BOLTvar['$ip']) !== false) {print_r
($IPblockedHTML);die();}

   However I still think it's not good to write it this way, which may
lock the superadmin himself.

4. Fixed a missense line in markup so that /* */ do not delete a
following char after it.

   old: MarkUp('pre', 'comments', '/\/\*(.*?)\*\/([^\/]|$)/s',
'');  // / * comments * /
   new: MarkUp('pre', 'comments', '/\/\*(.*?)\*\/(?=[^\/]|$)/s',
'');  // / * comments * /

5. Fixed a missense in system page action.search so that it shows the
last query input after submitting the form. I also simplified the
param name from myquery to q.

6. Added a BOLTescape to BOLTMstyles so that <a href="http://
www.google.com.tw">something</a> no more displayed mistakingly:

   if (! isset($args['href'])) $args['href'] = $args[1];
   $args['href'] = BOLTescape($args['href'],false);       //added

7. Modified search functions BOLTcheckNest1 - 3 to allow several
complicated searching patterns:

   1) with '(' started: (aaa && bbb) || ccc
   2) with ')' ended: aaa && bbb)))
   3) multi-bracket: ((aaa && bbb))
   4) space-seperated (it ought to be but there's a missense bug): aaa
bbb ccc

   However I think the alogrithm could be more improved, such as
loading index as a cache instead loading for each matching word, and
to allow a pattern like "aaa && bbb || ccc" with 'or' prior than 'and'
or so...

8. Added more system messages to messages and language file.

9. Changed code.script back to site.script and the related scripts.
Also fixed several missenses so that [(script)] works properly.

10.Fixed a mistake of 3.3.2f while parsing [messages] before getting
zones so that function messages are not showed.

# OTHER NOTICES

1. Besides, I made one more mistake. I found that site.auth.commands/
functions list pages with membergroup and/or available commands/
functions. Very special huh?

2. The return value of Xvalidate seems unreasonable. I thought it
should be just like Xif.

3. It seems unreasonable that Xrename multi-in and single-out, we
could not rename multi-pages into a single page could we?

--

You received this message because you are subscribed to the Google Groups 
"BoltWire" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/boltwire?hl=en.


Reply via email to