Hi all
I guess we should handle a bit better security issues. These bugs should be announced with a bit more details (like when it is exploitable, which versions are affected and simmilar details). I'd like to have something simmilar, like xine has:
http://xinehq.de/index.php/security/
I wrote how announcement could look like for latest issue. Comments?
Hi Michal, Good work! except I would remove the references to xine ;)
I can post this in a few hours, as a news item with a reference to Documentation.html where we already have a security section.
Marc
Michal C(ihar( a écrit:
Hi all
I guess we should handle a bit better security issues. These bugs should be announced with a bit more details (like when it is exploitable, which versions are affected and simmilar details). I'd like to have something simmilar, like xine has:
http://xinehq.de/index.php/security/
I wrote how announcement could look like for latest issue. Comments?
phpMyAdmnin security announcement
Announcement-ID: PSA-2004-3
Summary: When specifying specially formatted options to external MIME transformation, an attacker can execute any shell command restricted by privileges of httpd user.
Description: phpMyAdmin allows to use MIME transformations for displaying fields from database. These transformations are not enabled by default (administrator needs to prepare special table for keeping some information and specify it in configuration). One of these transformations allows to pipe field content through external program which needs to be hardcoded in php script. However user can specify parameters to that program and this parameter was not checked for shell meta characters, so attacker could pass there anything from redirection of output to executing any other command.
Severity: In default setup this feature is not enabled and many hosting providers run php in safe mode with disabled exec support, which both make them unaffected by this issue. User also need to be logged in into phpMyAdmin, what limites range of attackers to users of the server, who usually also can execute php code directly, so this possibility doesn't extend his privileges. However this could cause some harm, so we consider this as important.
Affected versions: All releases starting with 2.5.0 up to and including 2.6.0-pl1.
Unaffected versions: All releases older than 2.5.0. CVS HEAD has been fixed. The upcoming 2.6.0-pl2 release.
Solution: If you are vulnerable to this issue, easiest fix is to disable external transformation - just remove file libraries/transformations/text_plain__external.inc.php. The attached patch fixes the problem but should only be used by distributors who do not want to upgrade. Otherwise, we strongly advise everyone to upgrade to CVS HEAD or to the next version of xine-ui, which is to be released soon.
For further information and in case of questions, please contact the xine team. Our website is http://www.phpmyadmin.net/
Marc Delisle a écrit:
Hi Michal, Good work! except I would remove the references to xine ;)
I can post this in a few hours, as a news item with a reference to Documentation.html where we already have a security section.
Marc
Michal C(ihar( a écrit:
Hi all
I guess we should handle a bit better security issues. These bugs should be announced with a bit more details (like when it is exploitable, which versions are affected and simmilar details). I'd like to have something simmilar, like xine has:
http://xinehq.de/index.php/security/
I wrote how announcement could look like for latest issue. Comments?
phpMyAdmnin security announcement
Announcement-ID: PSA-2004-3
Summary: When specifying specially formatted options to external MIME transformation, an attacker can execute any shell command restricted by privileges of httpd user.
Description: phpMyAdmin allows to use MIME transformations for displaying fields from database. These transformations are not enabled by default (administrator needs to prepare special table for keeping some information and specify it in configuration). One of these transformations allows to pipe field content through external program which needs to be hardcoded in php script. However user can specify parameters to that program and this parameter was not checked for shell meta characters, so attacker could pass there anything from redirection of output to executing any other command.
Severity: In default setup this feature is not enabled and many hosting providers run php in safe mode with disabled exec support, which both make them unaffected by this issue. User also need to be logged in into phpMyAdmin, what limites range of attackers to users of the server, who usually also can execute php code directly, so this possibility doesn't extend his privileges. However this could cause some harm, so we consider this as important.
Affected versions: All releases starting with 2.5.0 up to and including 2.6.0-pl1.
Unaffected versions: All releases older than 2.5.0. CVS HEAD has been fixed. The upcoming 2.6.0-pl2 release.
Solution: If you are vulnerable to this issue, easiest fix is to disable external transformation - just remove file libraries/transformations/text_plain__external.inc.php. The attached patch fixes the problem but should only be used by distributors who do not want to upgrade. Otherwise, we strongly advise everyone to upgrade to CVS HEAD or to the next version of xine-ui, which is to be released soon.
For further information and in case of questions, please contact the xine team. Our website is http://www.phpmyadmin.net/
I am not sure if we should talk about "CVS HEAD" in such a message. Maybe just talk about latest CVS version?
Marc
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On Thu 14. 10. 2004 14:41, Marc Delisle wrote:
I am not sure if we should talk about "CVS HEAD" in such a message. Maybe just talk about latest CVS version?
It just makes clear it is not fixed in other branches where the bug still exists.
Hi All!
Summary: When specifying specially formatted options to external MIME transformation, an attacker can execute any shell command restricted by privileges of httpd user.
But it's not that "any shell command" can be executed? I thought that only output from the allowed programms can be redirected; thus you can actually only overwrite files with privileges of httpd user, right? I thought "|" and ";" are escaped by the shellarg-command, so that no other program could be spawned...?
(Sorry, haven't had the time to investigate your fix)
Regards, Garvin.
On Thu 14. 10. 2004 16:00, Garvin Hicking wrote:
Hi All!
Summary: When specifying specially formatted options to external MIME transformation, an attacker can execute any shell command restricted by privileges of httpd user.
But it's not that "any shell command" can be executed? I thought that only output from the allowed programms can be redirected; thus you can actually only overwrite files with privileges of httpd user, right? I thought "|" and ";" are escaped by the shellarg-command, so that no other program could be spawned...?
(Sorry, haven't had the time to investigate your fix)
As well as redirection, you can include there $(rm -rf /) or `rm -rf /` and it will work.
On Thu 14. 10. 2004 14:25, Marc Delisle wrote:
Good work! except I would remove the references to xine ;)
Oops, sure, it was just an example :-). Fixed version attached.
I can post this in a few hours, as a news item with a reference to Documentation.html where we already have a security section.
I'd drop it and replace all these stuff with link to security section on our web. Simply documentation can't cover bugs that will appear later, so you usually need actual information for security issues.
Michal C(ihar( a écrit:
On Thu 14. 10. 2004 14:25, Marc Delisle wrote:
Good work! except I would remove the references to xine ;)
Oops, sure, it was just an example :-). Fixed version attached.
I can post this in a few hours, as a news item with a reference to Documentation.html where we already have a security section.
I'd drop it and replace all these stuff with link to security section on our web. Simply documentation can't cover bugs that will appear later, so you usually need actual information for security issues.
So you think that users, reading the security information in a document that is clearly labeled as being for 2.6.0-pl2, will conclude that there won't be any bugs or security announcements later? I am not sure to agree with you.
Besides, we have localized versions of the doc for some languages. It would be interesting to have the localized version of the security alerts too.
Also, I find it important that the documents we produce be in the CVS, especially for matters about security.
But I am not against a new Security section, with relevant links.
Marc
On Thu 14. 10. 2004 15:17, Marc Delisle wrote:
So you think that users, reading the security information in a document that is clearly labeled as being for 2.6.0-pl2, will conclude that there won't be any bugs or security announcements later? I am not sure to agree with you.
No, but users usually don't need to know which bugs were in previous versions, but what bugs are in version they use. So they anyway need to look for such thing on our web. These issues should be archived, but they are IMHO not needed to be in documentation (which anyway should be somehow structured, it is getting too large).
Besides, we have localized versions of the doc for some languages. It would be interesting to have the localized version of the security alerts too.
Well till now I thought we have just these partly translated old unmaintained documents, but it looks like you're translating regularly french version. Anyway I'd like to keep security alerts separately as I don't see any use in having this in documentation. (In how many other projects have you seen such section in documentation?)
Also, I find it important that the documents we produce be in the CVS, especially for matters about security.
When you make security announcement you are not supposed to change it later so version control is not needed at all.
But I am not against a new Security section, with relevant links.
At least something :-)
Michal C(ihar( a écrit:
On Thu 14. 10. 2004 15:17, Marc Delisle wrote:
So you think that users, reading the security information in a document that is clearly labeled as being for 2.6.0-pl2, will conclude that there won't be any bugs or security announcements later? I am not sure to agree with you.
No, but users usually don't need to know which bugs were in previous versions, but what bugs are in version they use. So they anyway need to look for such thing on our web. These issues should be archived, but they are IMHO not needed to be in documentation (which anyway should be somehow structured, it is getting too large).
Michal,
I think the doc *is* structured but too large. You mean it should be splitted in smaller documents? It could be done. They only thing I miss in smaller documents is the ability to search using my browser's facilities, in case a notion is covered in more than one document.
Once in a while we discuss about this, also about the doc source format, the possible generation of one HTML file or many small, a formal way of translating the doc, etc.
Besides, we have localized versions of the doc for some languages. It would be interesting to have the localized version of the security alerts too.
Well till now I thought we have just these partly translated old unmaintained documents, but it looks like you're translating regularly french version.
I am lucky to have a volunteer from France who is maintaining this doc.
Anyway I'd like to keep security alerts separately as I don't see any use in having this in documentation. (In how many other projects have you seen such section in documentation?)
Well, at least I hope their doc has pointers about security matters.
Ok you have convinced me. Maybe other devs can comment too about this issue?
Also, I find it important that the documents we produce be in the CVS, especially for matters about security.
When you make security announcement you are not supposed to change it later so version control is not needed at all.
I was not thinking about version control but about backup. Right now we do not have a regular backup system for the shell server's htdocs directory. That's why I opened a pma_localized_docs structure in CVS.
But I am not against a new Security section, with relevant links.
At least something :-)
he he he :)
Hi
On Thu 14. 10. 2004 16:05, Marc Delisle wrote:
I think the doc *is* structured but too large. You mean it should be splitted in smaller documents? It could be done. They only thing I miss in smaller documents is the ability to search using my browser's facilities, in case a notion is covered in more than one document.
Yes, sorry, bad wording. It should be split to logical parts, so you should not need to look over all of them, first idea I get (I didn't even check if I mentioned all from current doc):
- installation and configuration - known problems (part of current FAQ) - tips (part of current FAQ) - project information (FAQ 7, credits, ...)
Once in a while we discuss about this, also about the doc source format, the possible generation of one HTML file or many small, a formal way of translating the doc, etc.
Well is here anybody who has actively used docbook or something like that?
Michal C(ihar( a écrit :
Hi
On Thu 14. 10. 2004 16:05, Marc Delisle wrote:
I think the doc *is* structured but too large. You mean it should be splitted in smaller documents? It could be done. They only thing I miss in smaller documents is the ability to search using my browser's facilities, in case a notion is covered in more than one document.
Yes, sorry, bad wording. It should be split to logical parts, so you should not need to look over all of them, first idea I get (I didn't even check if I mentioned all from current doc):
- installation and configuration
- known problems (part of current FAQ)
- tips (part of current FAQ)
- project information (FAQ 7, credits, ...)
Good idea.
Once in a while we discuss about this, also about the doc source format, the possible generation of one HTML file or many small, a formal way of translating the doc, etc.
Well is here anybody who has actively used docbook or something like that?
Not me sorry.
For the more urgent matter (the new Security section), do you want to do it, or do you want me to do it? (with your proposed text)
Marc
On Sun 17. 10. 2004 21:07, Marc Delisle wrote:
Michal C(ihar( a écrit :
Hi
On Thu 14. 10. 2004 16:05, Marc Delisle wrote:
Once in a while we discuss about this, also about the doc source format, the possible generation of one HTML file or many small, a formal way of translating the doc, etc.
Well is here anybody who has actively used docbook or something like that?
Not me sorry.
Neither do I. Lets wait for others, but when we won't have anybody with experiences, I doubt we could effectively used that.
For the more urgent matter (the new Security section), do you want to do it, or do you want me to do it? (with your proposed text)
I will do Security section update tomorrow.
On Sun 17. 10. 2004 21:13, Michal Čihař wrote:
I will do Security section update tomorrow.
Sorry, no time today, I hope Tuesday will be better...
On Sun 17. 10. 2004 21:13, Michal Čihař wrote:
On Sun 17. 10. 2004 21:07, Marc Delisle wrote:
For the more urgent matter (the new Security section), do you want to do it, or do you want me to do it? (with your proposed text)
I will do Security section update tomorrow.
I've prepared:
http://www.phpmyadmin.net/home_page/security.php (accessible also as http://www.phpmyadmin.net/security)
And I'm ready to point documentation to this. Comments?
The code reads announcements from /home/groups/p/ph/phpmyadmin/htdocs/security/announcements. To include new one in page, just add there new file.
Thanks Michal,
is it just me? The formatting of the pages containing the full text of alerts is not correct, it's off the box limits.
I will read more carefully the text today but right now it seems ok. Good idea to have a name scheme for the alerts.
Marc
Michal C(ihar( a écrit:
On Sun 17. 10. 2004 21:13, Michal C(ihar( wrote:
On Sun 17. 10. 2004 21:07, Marc Delisle wrote:
For the more urgent matter (the new Security section), do you want to do it, or do you want me to do it? (with your proposed text)
I will do Security section update tomorrow.
I've prepared:
http://www.phpmyadmin.net/home_page/security.php (accessible also as http://www.phpmyadmin.net/security)
And I'm ready to point documentation to this. Comments?
The code reads announcements from /home/groups/p/ph/phpmyadmin/htdocs/security/announcements. To include new one in page, just add there new file.
On Tue 19. 10. 2004 16:29, Marc Delisle wrote:
is it just me? The formatting of the pages containing the full text of alerts is not correct, it's off the box limits.
I actually don't face any problems (Firefox 1.0PR), but it might depend of fonts etc. Feel free to change layout of that page.
Michal C(ihar( a écrit:
On Tue 19. 10. 2004 16:29, Marc Delisle wrote:
is it just me? The formatting of the pages containing the full text of alerts is not correct, it's off the box limits.
I actually don't face any problems (Firefox 1.0PR), but it might depend of fonts etc. Feel free to change layout of that page.
Hi Michal,
have a look at http://www.phpmyadmin.net/security I made a security2.php where I removed <pre></pre>, and added some HTML to the announcements. Now they display correctly in Netscape 7 and IE 6.
If this ok I will add the menu link. Please chmod g+w security.php
Marc
On Wednesday 20 October 2004 15:56, Marc Delisle wrote:
have a look at http://www.phpmyadmin.net/security I made a security2.php where I removed <pre></pre>, and added some HTML to the announcements. Now they display correctly in Netscape 7 and IE 6.
When html, so please also use links :-). Anyway in this case we will need plain text for email announcements and html for web.
If this ok I will add the menu link. Please chmod g+w security.php
done, sorry
Michal C(ihar( a écrit:
On Wednesday 20 October 2004 15:56, Marc Delisle wrote:
have a look at http://www.phpmyadmin.net/security I made a security2.php where I removed <pre></pre>, and added some HTML to the announcements. Now they display correctly in Netscape 7 and IE 6.
When html, so please also use links :-).
Done :)
Anyway in this case we will need plain text for email announcements and html for web.
Usually with some cut&paste I produce plain text from web. I have left your original documents in security/announcement-text in case.
If this ok I will add the menu link. Please chmod g+w security.php
done, sorry
No problem. Header link added.
Marc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi there,
Marc Delisle wrote:
have a look at http://www.phpmyadmin.net/security
I like that new security page. But imho, we should resort the issue listing and move the most recent one to the top.
Regards,
AMT
Alexander M. Turek a écrit:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi there,
Marc Delisle wrote:
have a look at http://www.phpmyadmin.net/security
I like that new security page. But imho, we should resort the issue listing and move the most recent one to the top.
Yes it would make sense to be in the order you describe.
Marc
On Wednesday 20 October 2004 20:39, Marc Delisle wrote:
Alexander M. Turek a écrit:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi there,
Marc Delisle wrote:
have a look at http://www.phpmyadmin.net/security
I like that new security page. But imho, we should resort the issue listing and move the most recent one to the top.
Yes it would make sense to be in the order you describe.
Done :-)
--On Thursday, October 14, 2004 12:14 PM +0200 "Michal?iha?" michal@cihar.com wrote:
I'd like to have something simmilar, like xine has:
Also look at the security pages for BIND at http://www.isc.org/ and Sendmail at http://www.sendmail.org/. They've had lots of security issues in the past and are major pieces of Internet infrastructure, so they've had lots of opportunity to learn how to present this information.
-
Alexander M. Turek -
Garvin Hicking -
Kenneth Porter -
Marc Delisle -
Marc Delisle
-
Michal Čihař