Quoting Olivier <oliv...@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@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
