[imp] BUG: php 5 suhosin triggers MBOX_PREFIX separator

[azurIt]

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 at 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 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