[imp] BUG: php 5 suhosin triggers MBOX_PREFIX separator

[Michael M Slusarz]

Quoting Rick Romero <rick at havokmon.com>:

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Rick Romero <rick at havokmon.com>:
>>
>>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>>
>>>> Quoting Olivier <olivier at 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.
>
> 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]