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
