phpwiki-talk

Re: [Phpwiki-talk] phpwiki-1.3.13 released

[John S. <jst...@gm...>]

Hi Reini,
All the links I try to download the latest release from are broken.  Are you
sure this has gone out?
Cheers

Re: [Phpwiki-talk] Change background color for preformatted text

[Reini U. <ru...@x-...>]

ENABLE_MARKUP_COLOR = true (default)
something like:
<pre>
 %color=red%red test%%
 black
 %color=yellow%yellow test%%
 black
</pre>
------

2007/6/4, Sabri LABBENE <sab...@st...>:
> Hi all,
> I want to make prefomatted text (inside pre or verbatim tags) display in a colored area (light yellow for example). This will make wiki pages look nicer.
> I've been trying to do it for too long without results. Phpwiki parsers seems complex to me and I can't figure out how to add something like 'style="backgroud-color:#FDFDF7"' to transformed pre tags.
>
> Can someone help me to figure out how this could be done.
>
> Thanks,
> -- Sabri.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>


-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

[Phpwiki-talk] Change background color for preformatted text

[Sabri L. <sab...@st...>]

Hi all,
I want to make prefomatted text (inside pre or verbatim tags) display in =
a colored area (light yellow for example). This will make wiki pages =
look nicer.
I've been trying to do it for too long without results. Phpwiki parsers =
seems complex to me and I can't figure out how to add something like =
'style=3D"backgroud-color:#FDFDF7"' to transformed pre tags.

Can someone help me to figure out how this could be done.=20

Thanks,
-- Sabri.

Re: [Phpwiki-talk] URL parameters not updated after saving a wiki

[Reini U. <ru...@x-...>]

Sabri LABBENE schrieb:
>  
> Sabri LABBENE wrote:
>> Reini Urban wrote:
>>> it's not easy.
>>> if so I would have done it years ago. (around 2003)
>>>
>>> you can search the archives how jeff tried to get rid of it, and/or i 
>>> introduced it again somehow.
>> Ok. Personally I tried to remove/unset it but I can't. 
>> Unfortunately this parameter causes problems for me... Anyway, 
>> I'll try to live with it until I'll get a solution to remove it.
> 
> In editpage.php (function savePage()) at line ~317 there is a :
>     //$request->setArg('action', false);
> When I uncommented that line, 'action=edit' parameter has gone but only
> once. I edit another time then save and the parameter stay there as before +
> a Notice:
> 
> In template 'head':51: Notice: Undefined index: action:
> 
>     * $action = $args['action'];

This is easy to fix :)

Ok, I just checked the logic.

Whenever you have the theme signature defined or a save warning,
the action=edit will be sticky, because then we do no redirect.

Without signature and no warning the request is redirected and the 
action=edit will be gone.

We need it to support more than one submit button.
We have Save, Preview and lateron maybe Changes and Upload.
For the later three we need "edit", unless we do some js tricks
to submit the form from the button, enabling edit only there. This is 
what we wanted to avoid.

But I'll test that idea.
-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://helsinki.at/  http://spacemovie.mur.at/

[Phpwiki-talk] phpwiki-1.3.13 released

[Reini U. <ru...@x-...>]

I released 1.3.13 today and will install it tomorrow at the sf.net site. 
Under http://phpwiki.sf.net/phpwiki/ as usual.
I'll also import all the old pages.

You want to check the TODO.
Mediawiki import and Creole Markup is what I'm working on right now.
The next releases will come quicker.
-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://helsinki.at/  http://spacemovie.mur.at/

Re: [Phpwiki-talk] URL parameters not updated after saving a wiki

[Sabri L. <sab...@st...>]

 
Sabri LABBENE wrote:
>Reini Urban wrote:
>>it's not easy.
>>if so I would have done it years ago. (around 2003)
>>
>>you can search the archives how jeff tried to get rid of it, and/or i 
>>introduced it again somehow.
>
>Ok. Personally I tried to remove/unset it but I can't. 
>Unfortunately this parameter causes problems for me... Anyway, 
>I'll try to live with it until I'll get a solution to remove it.

In editpage.php (function savePage()) at line ~317 there is a :
    //$request->setArg('action', false);
When I uncommented that line, 'action=edit' parameter has gone but only
once. I edit another time then save and the parameter stay there as before +
a Notice:

In template 'head':51: Notice: Undefined index: action:

    * $action = $args['action'];

>>2007/5/31, Sabri LABBENE <sab...@st...>:
>>> Hi all,
>>>
>>> If I edit a page in Phpwiki then save it. The 'action=edit' 
>>url parameter still there. Can some one tell how to remove/unset it?
>>--
>>Reini Urban
>>http://phpwiki.org/              http://murbreak.at/
>>http://spacemovie.mur.at/   http://helsinki.at/
>>
>>---------------------------------------------------------------
>>----------
>>This SF.net email is sponsored by DB2 Express Download DB2 
>Express C - 
>>the FREE version of DB2 express and take control of your XML. No 
>>limits. Just data. Click to get it now.
>>http://sourceforge.net/powerbar/db2/
>>_______________________________________________
>>Phpwiki-talk mailing list
>>Php...@li...
>>https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>>
>
>
>---------------------------------------------------------------
>----------
>This SF.net email is sponsored by DB2 Express Download DB2 
>Express C - the FREE version of DB2 express and take control 
>of your XML. No limits. Just data. Click to get it now.
>http://sourceforge.net/powerbar/db2/
>_______________________________________________
>Phpwiki-talk mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

Re: [Phpwiki-talk] URL parameters not updated after saving a wiki

[Sabri L. <sab...@st...>]

Reini Urban wrote:
>it's not easy.
>if so I would have done it years ago. (around 2003)
>
>you can search the archives how jeff tried to get rid of it, 
>and/or i introduced it again somehow.

Ok. Personally I tried to remove/unset it but I can't. Unfortunately this
parameter causes problems for me... Anyway, I'll try to live with it until
I'll get a solution to remove it.

Thanks,
-- Sabri.

>2007/5/31, Sabri LABBENE <sab...@st...>:
>> Hi all,
>>
>> If I edit a page in Phpwiki then save it. The 'action=edit' 
>url parameter still there. Can some one tell how to remove/unset it?
>--
>Reini Urban
>http://phpwiki.org/              http://murbreak.at/
>http://spacemovie.mur.at/   http://helsinki.at/
>
>---------------------------------------------------------------
>----------
>This SF.net email is sponsored by DB2 Express Download DB2 
>Express C - the FREE version of DB2 express and take control 
>of your XML. No limits. Just data. Click to get it now.
>http://sourceforge.net/powerbar/db2/
>_______________________________________________
>Phpwiki-talk mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

Re: [Phpwiki-talk] URL parameters not updated after saving a wiki

[Reini U. <ru...@x-...>]

it's not easy.
if so I would have done it years ago. (around 2003)

you can search the archives how jeff tried to get rid of it, and/or i
introduced it again somehow.

2007/5/31, Sabri LABBENE <sab...@st...>:
> Hi all,
>
> If I edit a page in Phpwiki then save it. The 'action=edit' url parameter still there. Can some one tell how to remove/unset it?
-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

[Phpwiki-talk] URL parameters not updated after saving a wiki

[Sabri L. <sab...@st...>]

Hi all,

If I edit a page in Phpwiki then save it. The 'action=3Dedit' url =
parameter still there. Can some one tell how to remove/unset it?

Thanks,
-- Sabri.

[Phpwiki-talk] URL parameters not updated after saving a wiki

[Sabri L. <sab...@st...>]

Sabri LABBENE wrote:
>Hi all,
>
>If I edit a page in Phpwiki then save it. The 'action=edit' 
>url parameter still there. Can some one tell how to remove/unset it?

Any comments on the subject ?

Regards,
Sabri.

Re: [Phpwiki-talk] phpwiki rename page clarification.

[Reini U. <ru...@x-...>]

AlJeux schrieb:
> Hi Reini,
> 
> Thank you for answering so quickly to my question.
> 
> My question was only related to the second part of the code, not all the 
> code.
> 
> If I comment the following code (the one working with $newpage), the
> renaming bug is fixed.
> 
> (code in WikiDB.php in the rename_page func)
> === begin ===
>  $links = $newpage->getBackLinks();
>  while ($linked_page = $links->next()) {
>     WikiPlugin_WikiAdminSearchReplace::replaceHelper($this,
>                                      $linked_page->getName(),
>                                      $from, $to);
> }
> === end ===
> 
> Is it safe to comment these lines ?
> 
> As I said, I don't understand so I'm afraid of making a mistake.

Yes, it's save to comment out, because the 
WikiAdminSearchReplace::replaceHelper call is broken anyway.
You might end with too many renamed pages.

I'll try to fix it before the release.

BTW: I already uploaded the release but found another bug yesterday. 
php-5.2.x sessions still don't work.
-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://helsinki.at/  http://spacemovie.mur.at/

Re: [Phpwiki-talk] phpwiki rename page clarification.

[AlJeux <al...@fr...>]

Hi Reini,

Thank you for answering so quickly to my question.

My question was only related to the second part of the code, not all the 
code.

If I comment the following code (the one working with $newpage), the
renaming bug is fixed.

(code in WikiDB.php in the rename_page func)
=== begin ===
  $links = $newpage->getBackLinks();
  while ($linked_page = $links->next()) {
     WikiPlugin_WikiAdminSearchReplace::replaceHelper($this,
                                      $linked_page->getName(),
                                      $from, $to);
}
=== end ===

Is it safe to comment these lines ?

As I said, I don't understand so I'm afraid of making a mistake.

Best Regards,
Alain.

Re: [Phpwiki-talk] phpwiki rename page clarification.

[Reini U. <ru...@x-...>]

aljeux schrieb:
> Message body follows:
> 
> Hello,
> 
> Please, excuse me to contact directly, but as you seems the
> author of the lines, I think it's better to ask you directly.
> 
> I am a gforge developer running a gforge with phpwiki 1.3
> inside for projects.
> 
> When renaming a page, I've found a strange thing.
> 
> How to reproduce:
> 
> Create a link: PageAlain
> Create the page with the default text.
> Rename the page (with links) to: PageAlainTwo
> 
> => The page is renamed but now the links are named
> 'PageAlainTwoTwo'.
> 
> I have noticied that the code responsible for this is in
> lib/WikiDB.php
> In this code, there is a section:
> 
> if ($updateWikiLinks) {
>    require_once('lib/plugin/WikiAdminSearchReplace.php');
>    $links = $oldpage->getBackLinks();
>    while ($linked_page = $links->next()) {
>       WikiPlugin_WikiAdminSearchReplace::replaceHelper($this,
>                                                      
> $linked_page->getName(),
>                                                       $from,
> $to);
>    }
>    $links = $newpage->getBackLinks();
>    while ($linked_page = $links->next()) {
>       WikiPlugin_WikiAdminSearchReplace::replaceHelper($this,
>                                                       
> $linked_page->getName(),
>                                                       
> $from, $to);
>    }
> }
> 
> To solve the problem, I am tempted to comment the second
> part of the code (the one renaming link to the new page) but
> as I don't understand what is it for, I am quite reserved.
> 
> Can you help me to understand it's goal ?
> 
> Many thanks for for time,
> Alain Peyrat.

Hi Alain, better use the phpwiki-talk mailinglist.

this code does renaming all pagenames in all backlinked pages,
and is only executed if $updateWikiLinks is true.

Generally it is not good to do that automatically also,
because the old pagename detection is not strict enough.

-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://helsinki.at/  http://spacemovie.mur.at/

[Phpwiki-talk] (no subject)

[Sabri L. <sab...@st...>]

Hi all,

If I edit a page in Phpwiki then save it. The 'action=3Dedit' url =
parameter still there. Can some one tell how to remove/unset it?

Thanks,
-- Sabri.=20

Re: [Phpwiki-talk] Montreal 07 Outcome

[Mark M. <ma...@ic...>]

Please stop sending emails to jef...@ic...






-----Original Message-----
From: php...@li...
[mailto:php...@li...] On Behalf Of Reini Urban
Sent: Saturday, May 19, 2007 7:34 PM
To: Discussion on PhpWiki features, bugs, development.
Subject: [Phpwiki-talk] Montreal 07 Outcome

http://www.rocococamp.info/FutureWikiProjectsCollaboration

-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

[Phpwiki-talk] Montreal 07 Outcome

[Reini U. <ru...@x-...>]

http://www.rocococamp.info/FutureWikiProjectsCollaboration

-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

[Phpwiki-talk] rocococamp montreal

[Reini U. <ru...@x-...>]

So see some of there. This Friday to Sunday in Montreal.

   http://www.rocococamp.info/InvitationList

Hi Crao people!

[Phpwiki-talk] Notification preferences storage ??!!??

[Sabri L. <sab...@st...>]

Hi all,

I have some questions related to monitoring preferences storage and user =
pages that phpwiki creates if a user sets some preferences. It will be =
great if someone could provide some explanations on the subject.

First I want to know how monitoring data is stored in Phpwkii when users =
and preferences are stored in wiki pages?

I found the monitoring data in pref table and in 'global_data' wiki page =
!
Then, I want to know where phpwiki find the monitoring data after a page =
change for example.

Then is it possible to remove a monitoring data from 'global_data' page =
?

If I rename a user then his monitoring data will not change and the =
notification emails keep sent to the old user adress. So, what is the =
procedure for user rename without altering monitoring data.

Any help will be too much appreciated.

Thanks,
-- Sabri.

Re: [Phpwiki-talk] LDAP Config (Correction)

[Frank P. L. <fr...@th...>]

I changed LDAP_SEARCH_FIELD to uid and now do not get the  
(nosuchuser) tag in the debug message:

DEBUG: ALLOW_ANON_EDIT = false, ALLOW_BOGO_LOGIN = false,  
ALLOW_USER_PASSWORDS = true, ENABLE_PAGEPERM = true, USER_AUTH_ORDER:  
=> LDAP => Forbidden, USER_AUTH_POLICY: first-only,  
PASSWORD_LENGTH_MINIMUM: 0

Still a little confounded.  Been trying to get slapd to push out its  
debug messages on the LDAP server, in case it's my end.  Again, any  
ideas would be helpful.  I'm slowly making (some) progress (I think).

--Frank



On Apr 19, 2007, at 1:00 PM, Leef wrote:

>
> Hi Folks, I've been looking and trying several different Wikis to  
> use in
> conjunction with.  I finally settled on phpWiki a week ago - so I'm  
> pretty
> much a noob at phpwiki.
>
> I am trying to get it to authenticate against our LDAP server.  (an  
> OsX
> Tiger server (10.4.8) running Open Directory)
>
> It would seem that have successfully been able to bind to the LDAP  
> server
> however I am now getting new debug messages above.  I've read  
> through the
> talks in the forum online and they've been very helpful getting me  
> this far
> but now I'm lost.
>
> DEBUG: ALLOW_ANON_EDIT = false, ALLOW_BOGO_LOGIN = false,
> ALLOW_USER_PASSWORDS = true, ENABLE_PAGEPERM = true,  
> USER_AUTH_ORDER: =>
> LDAP (nosuchuser) => Forbidden, USER_AUTH_POLICY: first-only,
> PASSWORD_LENGTH_MINIMUM: 0
>
> Any thoughts or ideas?  Perhaps I have overlooked something small?
> Thank you in advance.
>
> --Frank
>
>
> config.ini
> USER_AUTH_ORDER = LDAP
> USER_AUTH_POLICY = first-only
> ;ENABLE_USER_NEW = false
> ;ENABLE_PAGEPERM = false
>
> LDAP_AUTH_HOST = "ldap://10.10.1.10"
> LDAP_BASE_DN = "cn=users,dc=Name,dc=local"
> LDAP_SET_OPTION = "LDAP_OPT_PROTOCOL_VERSION=3:LDAP_OPT_REFERRALS=0"
> LDAP_AUTH_USER = "uid=root,cn=users,dc=Name,dc=local"
> LDAP_AUTH_PASSWORD = somePassHere
> LDAP_SEARCH_FIELD = memberUID
> ;LDAP_OU_USERS = ou=Users
> ;LDAP_OU_GROUP = ou=Groups
>
>
> -- 
> View this message in context: http://www.nabble.com/LDAP-Config- 
> tf3608405.html#a10082231
> Sent from the phpwiki-talk mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

[Phpwiki-talk] LDAP Config

[Leef <fr...@th...>]

Hi Folks, I've been looking and trying several different Wikis to use in
conjunction with.  I finally settled on phpWiki a week ago - so I'm pretty
much a noob at phpwiki.

I am trying to get it to authenticate against our LDAP server.  (an OsX
Tiger server (10.4.8) running Open Directory) 

It would seem that have successfully been able to bind to the LDAP server
however I am now getting new debug messages above.  I've read through the
talks in the forum online and they've been very helpful getting me this far
but now I'm lost.

DEBUG: ALLOW_ANON_EDIT = false, ALLOW_BOGO_LOGIN = false,
ALLOW_USER_PASSWORDS = true, ENABLE_PAGEPERM = true, USER_AUTH_ORDER: =>
LDAP (nosuchuser) => Forbidden, USER_AUTH_POLICY: first-only,
PASSWORD_LENGTH_MINIMUM: 0

Any thoughts or ideas?  Perhaps I have overlooked something small?  
Thank you in advance.

--Frank


config.ini
USER_AUTH_ORDER = LDAP
USER_AUTH_POLICY = first-only
;ENABLE_USER_NEW = false
;ENABLE_PAGEPERM = false

LDAP_AUTH_HOST = "ldap://10.10.1.10"
LDAP_BASE_DN = "cn=users,dc=Name,dc=local"
LDAP_SET_OPTION = "LDAP_OPT_PROTOCOL_VERSION=3:LDAP_OPT_REFERRALS=0"
LDAP_AUTH_USER = "uid=root,cn=users,dc=Name,dc=local"
LDAP_AUTH_PASSWORD = somePassHere
LDAP_SEARCH_FIELD = memberUID
;LDAP_OU_USERS = ou=Users
;LDAP_OU_GROUP = ou=Groups


-- 
View this message in context: http://www.nabble.com/LDAP-Config-tf3608405.html#a10082231
Sent from the phpwiki-talk mailing list archive at Nabble.com.

[Phpwiki-talk] Fwd: Critical phpwiki c99shell exploit

[Reini U. <ru...@x-...>]

VGhpcyBidWd0cmFxIGFuc3dlciBzaG93cyBhIGxpbmsgdG8gYSBzY3JlZW4gc2hvdCBvZiB0aGUg
Yzk5IHNoZWxsLgoKICBodHRwOi8vd3d3LmhvbmV5bmV0Lm9yZy9wYXBlcnMvd2ViYXBwLwoKU28g
cGhwMywgcGhwNCBhbmQgcGhwNSBzaG91bGQgYmUgYmxvY2tlZCBub3cuCgpCdXQgdW50aWwgZnVy
dGhlciBhbmFseXNpcyBJIHdvdWxkIGNvbXBsZXRlbHkgZGlzYWJsZSB0aGUgVXBMb2FkIHBsdWdp
biBmb3IKdW5zZWN1cmUgdXNlcnMuCgotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0t
LS0tLS0KRnJvbTogSmFtaWUgUmlkZW4gPGphbWllLnJpZGVuQGdtYWlsLmNvbT4KRGF0ZTogMTIu
MDQuMjAwNyAxODo1OQpTdWJqZWN0OiBSZTogQ3JpdGljYWwgcGhwd2lraSBjOTlzaGVsbCBleHBs
b2l0ClRvOiBidWd0cmFxQHNlY3VyaXR5Zm9jdXMuY29tLCAicnVyYmFuQHgtcmF5LmF0IiA8cnVy
YmFuQHgtcmF5LmF0PgoKCk9uIDEyIEFwciAyMDA3IDEzOjE0OjE0IC0wMDAwLCBydXJiYW5AeC1y
YXkuYXQgPHJ1cmJhbkB4LXJheS5hdD4gd3JvdGU6Cj4gVmlhIHRoZSBQaHB3aWtpIDEuMy54IFVw
TG9hZCBmZWF0dXJlIHNvbWUgaGFja2VycyBmcm9tIHJ1c3NpYSB1cGxvYWRlZCBhIHBocDMgb3Ig
cGhwNCBmaWxlLAo+IGluc3RhbGwgYSBiYWNrZG9vciBhdCBwb3J0IDgwODEgYW5kIGhhdmUgYWNj
ZXNzIHRvIHlvdXIgd2hvbGUgZGlzYyBhbmQgb3ZlcnRha2UgdGhlIHNlcnZlci4KPgo+IEEgdXJs
IGluIHRoZSBmaWxlIGlzIGh0dHA6Ly9jY3RlYW0ucnUvcmVsZWFzZXMvYzk5c2hlbGwKPgo+IFRo
ZSB1cGxvYWRlZCBmaWxlIGhhcyBhIHBocCwgcGhwMyBvciBwaHA0IGV4dGVuc2lvbiBhbmQgbG9v
a3MgbGlrZSBhIGdpZiB0byB0aGUgbWltZSBtYWdpYy4KPiBTbyBhcGFjaGUgdXN1YWxseSBhY2Nl
cHRzIGl0Lgo+Cj4gVG8gZml4IHRoaXMgcGhwd2lraSBpc3N1ZSBhdCBmaXJzdCBtb3ZlIHRoZSBs
aWIvcGx1Z2luL1VwTG9hZC5waHAgZmlsZSBvdXQgb2YgdGhpcyBkaXJlY3RvcnkuCj4KPiBZb3Ug
Y2FuIGZpeCBpdCBieSBhZGRpbmcgdGhvc2UgdHdvIGxpbmVzIHRvIHlvdXIgbGlzdCBvZiBkaXNh
bGxvd2VkIGV4dGVuc2lvbnM6Cj4gICBwaHAzCj4gICBwaHA0Cj4gQ3VycmVudGx5IG9ubHkgInBo
cCIgaXMgZGlzYWxsb3dlZC4KClNvbWUgcGVvcGxlIGFsc28gbWFwIC5waHA1IC0gZ29vZ2xlIGZv
ciAiQWRkVHlwZQphcHBsaWNhdGlvbi94LWh0dHBkLXBocDUgLnBocDUiIGFuZCAiQWRkVHlwZSBh
cHBsaWNhdGlvbi94LWh0dHBkLXBocAoucGhwNSIgLSBhbmQgZ29vZG5lc3Mga25vd3Mgd2hhdCBl
bHNlLgoKVGhpcyB3b3VsZCBiZSBtdWNoIGJldHRlciByZS13cml0dGVuIHRvIHVzZSBrbm93biBz
YWZlIGV4dGVuc2lvbnMsIG9yCnRoZSBhZG1pbiBuZWVkcyB0byBjYXJlZnVsbHkgY29tcGFyZSB0
aGUgZGlzYWxsb3dlZCBsaXN0IGFnYWluc3QKaGlzL2hlciBodHRwZCBjb25maWcuCgooSWYgdGhl
cmUncyBhbnlvbmUgd2hvIGRvZXNuJ3Qga25vdyBjOTlzaGVsbCwgaXQncyBzb3J0IG9mIGEgaGVs
cGVyCmFwcCBmb3IgZG9pbmcgdGhpbmdzIG9uIHNlcnZlcnMgLSB0aGUga2luZCBvZiB0aGluZ3Mg
eW91IHByb2JhYmx5CmRvbid0IHdhbnQgZG9uZSAtIGFuZCBpcyBvZnRlbiB1c2VkIGluIGNvbmp1
bmN0aW9uIHdpdGggcmVtb3RlIGZpbGUKaW5jbHVkZSBhdHRhY2tzIHRvIGV4ZWN1dGUgc2hlbGwg
Y29tbWFuZHMuIFRoZXJlJ3MgYSBzY3JlZW5zaG90IGluCkFwcGVuZGl4IEIgYXQgaHR0cDovL3d3
dy5ob25leW5ldC5vcmcvcGFwZXJzL3dlYmFwcC8gLiAiRGVmYWNpbmcgVG9vbAoyLjAgYnkgcjN2
M25nNG5zIiBhbmQgcjU3c2hlbGwgYXJlIHNpbWlsYXIgdXRpbGl0aWVzIHlvdSBtYXkgaGF2ZSBj
b21lCmFjcm9zcy4pCgpjaGVlcnMsCiBKYW1pZQoKUFMuIEkgY2FuJ3Qgc2VlIHdoZXJlIGl0IGNo
ZWNrcyBpZiB0aGUgZmlsZSBpcyBhIEdJRiwgYnV0IGl0J3Mgbm90CmhhcmQgdG8gZm9vbCBzb21l
IHByb2dyYW1zLCBhbmQgSSBkb24ndCBsaWtlIHRoZSBpZGVhIG9mIGd1ZXNzaW5nIGZpbGUKdHlw
ZXMgYmFzZWQgb24gY29udGVudHMuIEl0J3Mgbm90IHNhZmUuCgo9PSBmb28ucGhwID09CkdJRjg5
YSFeQCJeQAo8P3BocAogIGVjaG8gImZvbyI7Cj8+Cj09PT09PT09PT09CgokIGZpbGUgZm9vLnBo
cApmb28ucGhwOiBHSUYgaW1hZ2UgZGF0YSwgdmVyc2lvbiA4OWEsIDMzIHggMzQKClRoZSBvdXRw
dXQgb2YgdmlzaXRpbmcgaHR0cDovL2xvY2FsaG9zdC9mb28ucGhwIHVuZGVyIGFwYWNoZSBpcwon
R0lGODlhIe+/vSLvv70gZm9vJy4KLS0KSmFtaWUgUmlkZW4gLyBqYW1lc3JAZXVyb3BlLmNvbSAv
IGphbWllQGhvbmV5bmV0Lm9yZy51awpVSyBIb25leW5ldCBQcm9qZWN0OiBodHRwOi8vd3d3LnVr
aG9uZXluZXQub3JnLwotLSAKUmVpbmkgVXJiYW4KaHR0cDovL3BocHdpa2kub3JnLyAgICAgICAg
ICAgICAgaHR0cDovL211cmJyZWFrLmF0LwpodHRwOi8vc3BhY2Vtb3ZpZS5tdXIuYXQvICAgaHR0
cDovL2hlbHNpbmtpLmF0Lwo=

Re: [Phpwiki-talk] IMPORTANT More UpLoad hacks

[Harold H. <ha...@ha...>]

> 2007/4/12, Harold Hallikainen <ha...@ha...>:
>> > 2007/4/12, Sabri LABBENE <sab...@st...>:
>> >> Reini Urban wrote:
>> >> >Via the Phpwiki 1.3.x UpLoad feature some hackers from russia upload
>> a
>> >> >php3 or php4 file,
>> >> >install a backdoor at port 8081 and have access to your whole
>> >> >disc and overtake the server.
>> >> >
>> >> >See http://ccteam.ru/releases/c99shell
>> >>
>> >> I think that the URL is wrong.
>> >
>> > This url obviously worked in 2006. Now it is gone.
>> >
>> > I submitted a critical security alert to CERT and it will be in the
>> > cve reports of mitre.org
>> > also then (hopefully).
>>
>> As the one who was attacked, I can give you the IP addresses of the
>> attackers. Second, instead of disallowed extensions, I think it would be
>> much safet to have a list of ALLOWED extensions. I see this as a todo in
>> the upload plugin.
>
> Hm, I will think about it. Other opinions?
>
>> I have set my upload directory as read only and require users to now
>> email
>> me stuff to post.
>>
>> As to how much was visible to the hackers (and I have the code for their
>> script), it SEEMS that it would only be what user apache could see,
>> which
>> would be stuff it owns and stuff that is world readable. Is that
>> correct?
>
> Well not really. The c99shell script tries in various ways to get more
> access.
> At first it compiles and installs a backdoor at port 8081 and then
> with shell access it's normally quite easy for an experienced hacker
> to get root.
>
> --
> Reini Urban


THANKS for the support on this issue! I did an updatedb, then did locate
c99. The only stuff that comes up is this:

/usr/include/boost/numeric/interval/detail/c99sub_rounding_control.hpp
/usr/include/boost/numeric/interval/detail/c99_rounding_control.hpp
/usr/share/man/man1p/c99.1p.gz
/usr/bin/c99


In addition, port 8081 is blocked at the router (for incoming requests).
So, I'm hoping I'm ok!

I really think an approved filetype list for uploads would be nice. It
seems a lot easier than trying to anticipate everything bad that someone
will try.

THANKS for the support on this!

Harold

-- 
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

Re: [Phpwiki-talk] IMPORTANT More UpLoad hacks

[Reini U. <ru...@x-...>]

2007/4/12, Harold Hallikainen <ha...@ha...>:
> > 2007/4/12, Sabri LABBENE <sab...@st...>:
> >> Reini Urban wrote:
> >> >Via the Phpwiki 1.3.x UpLoad feature some hackers from russia upload a
> >> >php3 or php4 file,
> >> >install a backdoor at port 8081 and have access to your whole
> >> >disc and overtake the server.
> >> >
> >> >See http://ccteam.ru/releases/c99shell
> >>
> >> I think that the URL is wrong.
> >
> > This url obviously worked in 2006. Now it is gone.
> >
> > I submitted a critical security alert to CERT and it will be in the
> > cve reports of mitre.org
> > also then (hopefully).
>
> As the one who was attacked, I can give you the IP addresses of the
> attackers. Second, instead of disallowed extensions, I think it would be
> much safet to have a list of ALLOWED extensions. I see this as a todo in
> the upload plugin.

Hm, I will think about it. Other opinions?

> I have set my upload directory as read only and require users to now email
> me stuff to post.
>
> As to how much was visible to the hackers (and I have the code for their
> script), it SEEMS that it would only be what user apache could see, which
> would be stuff it owns and stuff that is world readable. Is that correct?

Well not really. The c99shell script tries in various ways to get more access.
At first it compiles and installs a backdoor at port 8081 and then
with shell access it's normally quite easy for an experienced hacker
to get root.

-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

Re: [Phpwiki-talk] IMPORTANT More UpLoad hacks

[Harold H. <ha...@ha...>]

> 2007/4/12, Sabri LABBENE <sab...@st...>:
>> Reini Urban wrote:
>> >Via the Phpwiki 1.3.x UpLoad feature some hackers from russia upload a
>> >php3 or php4 file,
>> >install a backdoor at port 8081 and have access to your whole
>> >disc and overtake the server.
>> >
>> >See http://ccteam.ru/releases/c99shell
>>
>> I think that the URL is wrong.
>
> This url obviously worked in 2006. Now it is gone.
>
> I submitted a critical security alert to CERT and it will be in the
> cve reports of mitre.org
> also then (hopefully).
> --
> Reini Urban
> http://phpwiki.org/              http://murbreak.at/
> http://spacemovie.mur.at/   http://helsinki.at/
>


As the one who was attacked, I can give you the IP addresses of the
attackers. Second, instead of disallowed extensions, I think it would be
much safet to have a list of ALLOWED extensions. I see this as a todo in
the upload plugin.

I have set my upload directory as read only and require users to now email
me stuff to post.

As to how much was visible to the hackers (and I have the code for their
script), it SEEMS that it would only be what user apache could see, which
would be stuff it owns and stuff that is world readable. Is that correct?

THANKS!

Harold

-- 
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

Re: [Phpwiki-talk] IMPORTANT More UpLoad hacks

[Reini U. <ru...@x-...>]

2007/4/12, Sabri LABBENE <sab...@st...>:
> Reini Urban wrote:
> >Via the Phpwiki 1.3.x UpLoad feature some hackers from russia upload a
> >php3 or php4 file,
> >install a backdoor at port 8081 and have access to your whole
> >disc and overtake the server.
> >
> >See http://ccteam.ru/releases/c99shell
>
> I think that the URL is wrong.

This url obviously worked in 2006. Now it is gone.

I submitted a critical security alert to CERT and it will be in the
cve reports of mitre.org
also then (hopefully).
-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/