Re: [imp] BUG: php 5 suhosin triggers MBOX_PREFIX separator
Quoting Olivier oliv...@ablinux.com: Hi, apache 2.2.16 php 5.3.3 *with suhosin* horde 4.0.3 imp 5.0.3 In my syslog, I have a lot of this message: suhosin[2446]: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'view' (attacker 'XXX.XXX.XXX.XXX', file '.../services/ajax.php') And the search in dimp never respond ! It is the '\0' delimiter char of MAILBOX_PREFIX defined in imp/lib/Search.php which is triggered by suhosin. I suggest you to replace '\0' by '+'. On my server it seems to be ok. Olivier You didn't read docs/INSTALL: 2. The following PHP capabilities: .. Important:: Certain features in IMP 5 will not work with the suhosin **extension** (e.g. search mailboxes). You must disable the suhosin extension to use these features. It is reported that IMP 5 does work the suhosin **patch**. -- mike The Horde Project (www.horde.org) mrubi...@horde.org -- IMP mailing list Frequently Asked Questions: http://horde.org/faq/ To unsubscribe, mail: imp-unsubscr...@lists.horde.org
Re: [imp] BUG: php 5 suhosin triggers MBOX_PREFIX separator
Quoting Olivier oliv...@ablinux.com: suhosin[2446]: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'view' (attacker 'XXX.XXX.XXX.XXX', file '.../services/ajax.php') Still waiting for someone to tell me how a NULL character, by itself, is a security threat. Maybe suhosin should also filter out j, a, v, s, c, r, i, p, and t characters because they can be used to create XSS attacks. michael ___ Michael Slusarz [slus...@horde.org] -- IMP mailing list Frequently Asked Questions: http://horde.org/faq/ To unsubscribe, mail: imp-unsubscr...@lists.horde.org
Re: [imp] BUG: php 5 suhosin triggers MBOX_PREFIX separator
Quoting Rick Romero r...@havokmon.com: Quoting Michael M Slusarz slus...@horde.org: Quoting Olivier oliv...@ablinux.com: suhosin[2446]: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'view' (attacker 'XXX.XXX.XXX.XXX', file '.../services/ajax.php') Still waiting for someone to tell me how a NULL character, by itself, is a security threat. What if the variable is expected to be numeric and you start doing math on it? But what if the variable ends up being 0. That's a perfectly valid integer, but could cause problems if the application uses it as a divisor. Isn't the purpose of suhosin to try and catch the stuff developers didn't catch? But you can't break things that are supposed to work otherwise. NULL is a perfectly acceptable input in URL parameters. And, e.g. with the 0 value above, the interpreter CAN'T possibly catch/process all valid inputs. That is the duty of the application author. michael ___ Michael Slusarz [slus...@horde.org] -- IMP mailing list Frequently Asked Questions: http://horde.org/faq/ To unsubscribe, mail: imp-unsubscr...@lists.horde.org
Re: [imp] BUG: php 5 suhosin triggers MBOX_PREFIX separator
this can be disabled in suhosin: http://www.hardened-php.net/suhosin/configuration.html#suhosin.post.disallow_nul __ Od: Michael M Slusarz Komu: imp@lists.horde.org Dátum: 23.05.2011 21:00 Predmet: Re: [imp] BUG: php 5 suhosin triggers MBOX_PREFIX separator Quoting Rick Romero : Quoting Michael M Slusarz : Quoting Rick Romero : Quoting Michael M Slusarz : Quoting Olivier : suhosin[2446]: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'view' (attacker 'XXX.XXX.XXX.XXX', file '.../services/ajax.php') Still waiting for someone to tell me how a NULL character, by itself, is a security threat. What if the variable is expected to be numeric and you start doing math on it? But what if the variable ends up being 0. That's a perfectly valid integer, but could cause problems if the application uses it as a divisor. Isn't the purpose of suhosin to try and catch the stuff developers didn't catch? But you can't break things that are supposed to work otherwise. NULL is a perfectly acceptable input in URL parameters. And, e.g. with the 0 value above, the interpreter CAN'T possibly catch/process all valid inputs. That is the duty of the application author. I dunno. I agree with your last paragraph, it's not suhosin's job to be a substitute for proper input validation. But kinda I think that contradicts 'NULL is a perfectly acceptable input..'. I mean - Do you really design an application and say Yep, we're going to expect a user (or unknown entity) to send a NULL here ? Why not? That may be YOUR belief, or the way that you would code things, but the fact is *BOTH* PHP and the URL specs allow this to happen. So it is broken behavior to disallow this. Period. In our case, we need a way to indicate a mailbox is not an IMAP mailbox. I chose the method of including a null character in the mailbox string since this is the ONLY character not allowed in IMAP mailboxes (yes, all other control characters are allowed). It works great everywhere - as it should because it doesn't violate any spec or API - except when using suhosin. Suhosin = broken. Assuming it's coded 'properly' that variable should have been pre-set in code, and upon receiving a URL param with data outside the expected range (numerical, 0), promptly ignored it. Or am I wrong? You would be wrong. Why do you want to ignore proper URL form data? If someone sends you an encoded null character (%00), that's a character within the allowed range so why should it be treated any differently? What if I have a page that sends the first 16 bytes of an image provided to it to the server to do some kind of MIME Magic testing - preventing the need to send the whole file. This binary data may contain nulls. Who are you to tell me that this is a security violation? Just because null characters can be used for things such as buffer overruns in certain languages does not mean they are evil. You simply can't remove them from a data stream without knowing the context. I would be very wary of running something that supposedly increases security on your machine when the actual theory behind that code is this deeply flawed. michael ___ Michael Slusarz [slus...@horde.org] -- IMP mailing list Frequently Asked Questions: http://horde.org/faq/ To unsubscribe, mail: imp-unsubscr...@lists.horde.org -- IMP mailing list Frequently Asked Questions: http://horde.org/faq/ To unsubscribe, mail: imp-unsubscr...@lists.horde.org
Re: [imp] BUG: php 5 suhosin triggers MBOX_PREFIX separator
Yes, but is this the only edge effect of suhosin ? Olivier Le 23/05/2011 21:04, azurIt a écrit : this can be disabled in suhosin: http://www.hardened-php.net/suhosin/configuration.html#suhosin.post.disallow_nul __ Od: Michael M Slusarz Komu: imp@lists.horde.org Dátum: 23.05.2011 21:00 Predmet: Re: [imp] BUG: php 5 suhosin triggers MBOX_PREFIX separator Quoting Rick Romero : Quoting Michael M Slusarz : Quoting Rick Romero : Quoting Michael M Slusarz : Quoting Olivier : suhosin[2446]: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'view' (attacker 'XXX.XXX.XXX.XXX', file '.../services/ajax.php') Still waiting for someone to tell me how a NULL character, by itself, is a security threat. What if the variable is expected to be numeric and you start doing math on it? But what if the variable ends up being 0. That's a perfectly valid integer, but could cause problems if the application uses it as a divisor. Isn't the purpose of suhosin to try and catch the stuff developers didn't catch? But you can't break things that are supposed to work otherwise. NULL is a perfectly acceptable input in URL parameters. And, e.g. with the 0 value above, the interpreter CAN'T possibly catch/process all valid inputs. That is the duty of the application author. I dunno. I agree with your last paragraph, it's not suhosin's job to be a substitute for proper input validation. But kinda I think that contradicts 'NULL is a perfectly acceptable input..'. I mean - Do you really design an application and say Yep, we're going to expect a user (or unknown entity) to send a NULL here ? Why not? That may be YOUR belief, or the way that you would code things, but the fact is *BOTH* PHP and the URL specs allow this to happen. So it is broken behavior to disallow this. Period. In our case, we need a way to indicate a mailbox is not an IMAP mailbox. I chose the method of including a null character in the mailbox string since this is the ONLY character not allowed in IMAP mailboxes (yes, all other control characters are allowed). It works great everywhere - as it should because it doesn't violate any spec or API - except when using suhosin. Suhosin = broken. Assuming it's coded 'properly' that variable should have been pre-set in code, and upon receiving a URL param with data outside the expected range (numerical, 0), promptly ignored it. Or am I wrong? You would be wrong. Why do you want to ignore proper URL form data? If someone sends you an encoded null character (%00), that's a character within the allowed range so why should it be treated any differently? What if I have a page that sends the first 16 bytes of an image provided to it to the server to do some kind of MIME Magic testing - preventing the need to send the whole file. This binary data may contain nulls. Who are you to tell me that this is a security violation? Just because null characters can be used for things such as buffer overruns in certain languages does not mean they are evil. You simply can't remove them from a data stream without knowing the context. I would be very wary of running something that supposedly increases security on your machine when the actual theory behind that code is this deeply flawed. michael ___ Michael Slusarz [slus...@horde.org] -- IMP mailing list Frequently Asked Questions: http://horde.org/faq/ To unsubscribe, mail: imp-unsubscr...@lists.horde.org
Re: [imp] BUG: php 5 suhosin triggers MBOX_PREFIX separator
Almost everything (or maybe everything) in suhosin can be disabled. I believe it is possible to tune it so Horde will work ok. __ Od: Olivier Komu: imp@lists.horde.org Dátum: 23.05.2011 21:21 Predmet: Re: [imp] BUG: php 5 suhosin triggers MBOX_PREFIX separator Yes, but is this the only edge effect of suhosin ? Olivier Le 23/05/2011 21:04, azurIt a écrit : this can be disabled in suhosin: http://www.hardened-php.net/suhosin/configuration.html#suhosin.post.disallow_nul __ Od: Michael M Slusarz Komu: imp@lists.horde.org Dátum: 23.05.2011 21:00 Predmet: Re: [imp] BUG: php 5 suhosin triggers MBOX_PREFIX separator Quoting Rick Romero : Quoting Michael M Slusarz : Quoting Rick Romero : Quoting Michael M Slusarz : Quoting Olivier : suhosin[2446]: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'view' (attacker 'XXX.XXX.XXX.XXX', file '.../services/ajax.php') Still waiting for someone to tell me how a NULL character, by itself, is a security threat. What if the variable is expected to be numeric and you start doing math on it? But what if the variable ends up being 0. That's a perfectly valid integer, but could cause problems if the application uses it as a divisor. Isn't the purpose of suhosin to try and catch the stuff developers didn't catch? But you can't break things that are supposed to work otherwise. NULL is a perfectly acceptable input in URL parameters. And, e.g. with the 0 value above, the interpreter CAN'T possibly catch/process all valid inputs. That is the duty of the application author. I dunno. I agree with your last paragraph, it's not suhosin's job to be a substitute for proper input validation. But kinda I think that contradicts 'NULL is a perfectly acceptable input..'. I mean - Do you really design an application and say Yep, we're going to expect a user (or unknown entity) to send a NULL here ? Why not? That may be YOUR belief, or the way that you would code things, but the fact is *BOTH* PHP and the URL specs allow this to happen. So it is broken behavior to disallow this. Period. In our case, we need a way to indicate a mailbox is not an IMAP mailbox. I chose the method of including a null character in the mailbox string since this is the ONLY character not allowed in IMAP mailboxes (yes, all other control characters are allowed). It works great everywhere - as it should because it doesn't violate any spec or API - except when using suhosin. Suhosin = broken. Assuming it's coded 'properly' that variable should have been pre-set in code, and upon receiving a URL param with data outside the expected range (numerical, 0), promptly ignored it. Or am I wrong? You would be wrong. Why do you want to ignore proper URL form data? If someone sends you an encoded null character (%00), that's a character within the allowed range so why should it be treated any differently? What if I have a page that sends the first 16 bytes of an image provided to it to the server to do some kind of MIME Magic testing - preventing the need to send the whole file. This binary data may contain nulls. Who are you to tell me that this is a security violation? Just because null characters can be used for things such as buffer overruns in certain languages does not mean they are evil. You simply can't remove them from a data stream without knowing the context. I would be very wary of running something that supposedly increases security on your machine when the actual theory behind that code is this deeply flawed. michael ___ Michael Slusarz [slus...@horde.org] -- IMP mailing list Frequently Asked Questions: http://horde.org/faq/ To unsubscribe, mail: imp-unsubscr...@lists.horde.org -- IMP mailing list Frequently Asked Questions: http://horde.org/faq/ To unsubscribe, mail: imp-unsubscr...@lists.horde.org
Re: [imp] BUG: php 5 suhosin triggers MBOX_PREFIX separator
Quoting Olivier oliv...@ablinux.com: Yes, but is this the only edge effect of suhosin ? Olivier IMHO, suhosin is looking for things that PROBABLY shouldn't be happening. For the most part there won't be any issues, but the only way to guarantee the app works perfectly is to not interfere with it. You have the same risks when using any other web application firewall. Actually, I run suhosin on FreeBSD 7.2-stable and haven't run into any issues. PHP 5.2.14 with Suhosin-Patch 0.9.7 (cli) (built: Aug 29 2010 20:06:55) Rick Le 23/05/2011 21:04, azurIt a écrit : this can be disabled in suhosin: http://www.hardened-php.net/suhosin/configuration.html#suhosin.post.disallow_nul __ Od: Michael M Slusarz Komu: imp@lists.horde.org Dátum: 23.05.2011 21:00 Predmet: Re: [imp] BUG: php 5 suhosin triggers MBOX_PREFIX separator Quoting Rick Romero : Quoting Michael M Slusarz : Quoting Rick Romero : Quoting Michael M Slusarz : Quoting Olivier : suhosin[2446]: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'view' (attacker 'XXX.XXX.XXX.XXX', file '.../services/ajax.php') Still waiting for someone to tell me how a NULL character, by itself, is a security threat. What if the variable is expected to be numeric and you start doing math on it? But what if the variable ends up being 0. That's a perfectly valid integer, but could cause problems if the application uses it as a divisor. Isn't the purpose of suhosin to try and catch the stuff developers didn't catch? But you can't break things that are supposed to work otherwise. NULL is a perfectly acceptable input in URL parameters. And, e.g. with the 0 value above, the interpreter CAN'T possibly catch/process all valid inputs. That is the duty of the application author. I dunno. I agree with your last paragraph, it's not suhosin's job to be a substitute for proper input validation. But kinda I think that contradicts 'NULL is a perfectly acceptable input..'. I mean - Do you really design an application and say Yep, we're going to expect a user (or unknown entity) to send a NULL here ? Why not? That may be YOUR belief, or the way that you would code things, but the fact is *BOTH* PHP and the URL specs allow this to happen. So it is broken behavior to disallow this. Period. In our case, we need a way to indicate a mailbox is not an IMAP mailbox. I chose the method of including a null character in the mailbox string since this is the ONLY character not allowed in IMAP mailboxes (yes, all other control characters are allowed). It works great everywhere - as it should because it doesn't violate any spec or API - except when using suhosin. Suhosin = broken. Assuming it's coded 'properly' that variable should have been pre-set in code, and upon receiving a URL param with data outside the expected range (numerical, 0), promptly ignored it. Or am I wrong? You would be wrong. Why do you want to ignore proper URL form data? If someone sends you an encoded null character (%00), that's a character within the allowed range so why should it be treated any differently? What if I have a page that sends the first 16 bytes of an image provided to it to the server to do some kind of MIME Magic testing - preventing the need to send the whole file. This binary data may contain nulls. Who are you to tell me that this is a security violation? Just because null characters can be used for things such as buffer overruns in certain languages does not mean they are evil. You simply can't remove them from a data stream without knowing the context. I would be very wary of running something that supposedly increases security on your machine when the actual theory behind that code is this deeply flawed. michael ___ Michael Slusarz [slus...@horde.org] -- IMP mailing list Frequently Asked Questions: http://horde.org/faq/ To unsubscribe, mail: imp-unsubscr...@lists.horde.org -- IMP mailing list Frequently Asked Questions: http://horde.org/faq/ To unsubscribe, mail: imp-unsubscr...@lists.horde.org
Re: [imp] BUG: php 5 suhosin triggers MBOX_PREFIX separator
Quoting Rick Romero r...@havokmon.com: Actually, I run suhosin on FreeBSD 7.2-stable and haven't run into any issues. PHP 5.2.14 with Suhosin-Patch 0.9.7 (cli) (built: Aug 29 2010 20:06:55) The patch has been reported to work fine - apparently, it doesn't much with Zend internals. But this will all be moot soon. In no small part to avoid this whole mess, I have added code to pass around mailbox names base64 encoded in form data. A total PITA, but since a bunch of installations apparently ship suhosin by default, I deemed it worthy enough to (unfortunately) have to work around. This should be implemented by IMP 5.0.5 (it won't make it into the next IMP release since it hasn't been tested thoroughly yet). michael ___ Michael Slusarz [slus...@horde.org] -- IMP mailing list Frequently Asked Questions: http://horde.org/faq/ To unsubscribe, mail: imp-unsubscr...@lists.horde.org
