[imp] BUG: php 5 suhosin triggers MBOX_PREFIX separator

[azurIt]

this can be disabled in suhosin:
http://www.hardened-php.net/suhosin/configuration.html#suhosin.post.disallow_nul


 
 ______________________________________________________________
 > Od: "Michael M Slusarz" 
 > Komu: imp at 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 [slusarz at horde.org] 
 
 -- 
 IMP mailing list 
 Frequently Asked Questions: http://horde.org/faq/ 
 To unsubscribe, mail: imp-unsubscribe at lists.horde.org