[imp] BUG: php 5 suhosin triggers MBOX_PREFIX separator

[Rick Romero]

Quoting Olivier <olivier at 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 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