Lester,
I don't quite understand the relevance of PHPEclipse to the issue.
And I'm not sure how you judge "clogging up" PHP without seeing a patch
especially as I'm not sure how much PHP internals hacking you've done.
Andi
> -Original Message-
> From: Lester Caine [mailto:[EMAIL PROTEC
Wietse Venema wrote:
Ilia Alshanetsky:
And here is your first exploit, let's say we say
mysql_real_escape_string() takes tainted data and makes it untainted,
what happens when this "safe" data is passed to exec().
You need a malicous code writer to have an exploit. As far as I
know, PHP is
The main issue, as I already discussed with Andrei (sorry, our
discussions are stealth since I see him almost every day even though I
try hard to avoid him) is how we handle encoding errors if we jit at
runtime and process the entire array at that time. I agree that this is
architecturally the rig
On Fri, 2006-12-15 at 19:05 -0600, Richard Lynch wrote:
> On Fri, December 15, 2006 6:47 pm, Andi Gutmans wrote:
> > Time to turn it off in php.ini-dist in addition to
> > php.ini-recommended?
>
> +1
>
> Let the developers turn it ON for a dev box.
>
> This will, however, unleash a zillion quest
I think #2 is better than #1.
The current implementation of mbstring is based on the solution similar
to #1. It is simple and stable, but, #2 has more flexibility.
Rui
On Thu, 14 Dec 2006 21:59:44 +0100
Pierre <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Yesterday, Ilia, Andrei and I discussed the
I wouldn't worry about the specific interface of an explicit taint/untaint
(whether function, case or language construct). That can easily be adjusted
later on.
> -Original Message-
> From: Wietse Venema [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 15, 2006 6:02 PM
> To: PHP interna
It is not just the phpinfo() servers, it is very much a common case I
assure you.
Well, people leaving such things in their servers should deal with it
first, then get to talk about real security :) No solution can help a
person who deliberately configures his server wide open. We are talking
Jordan Moore wrote:
So, what if an ISP (webhost) enables taint functionality, and a
developer uses a PHP library that uses custom filter functions for
filtering data. Will this developer see messages displayed on his PHP
application even though filtering is being done?
Correctly implemented fil
On 15-Dec-06, at 7:23 PM, Stanislav Malyshev wrote:
Something that most servers do (almost 80% by recent stats).
http://www.nexen.net/images/stories/phpinfos/display_errors.png
You mean "most of the servers that allow strangers to read their
phpinfo()"? I'm not surprised. You think if the
Richard Lynch:
> On Fri, December 15, 2006 4:31 pm, Wietse Venema wrote:
> > Even if some taint check is to restrictive at some point in time,
> > the programmer can always overcome it with an explicit action.
>
> Would that require some sort of bogus string non-manipulation, or do
> you foresee a
On Fri, December 15, 2006 5:05 pm, Ilia Alshanetsky wrote:
> In theory, you need to consider that many ISPs and users will
> interpret taint mode == secure and enable it causing much grief to
> distributable application writers who need to accommodate every
> environment.
That accommodation consi
On Thu, December 14, 2006 2:59 pm, Pierre wrote:
#2 feels more right to me, fwiw...
There are just too many funky things out there sending wacko charset
headers that aren't matching reality, in my limited experience, that
not letting the application developer set up the conversion will just
end u
On Fri, December 15, 2006 7:12 pm, Jordan Moore wrote:
> So, what if an ISP (webhost) enables taint functionality, and a
> developer uses a PHP library that uses custom filter functions for
> filtering data. Will this developer see messages displayed on his PHP
> application even though filtering i
Hi,
I guess a taint mode would give users the impression that the data is
safe while it isn't safe.
As an example: $data = mysql_real_escape_sring($_GET['data']);
query(with $data); echo "Saved $data"; For the first part the data is
safe and the escape removes the taint flag. Having the taint mo
On Fri, December 15, 2006 5:32 pm, Ilia Alshanetsky wrote:
>
> On 15-Dec-06, at 6:21 PM, Andi Gutmans wrote:
>
>> Well you wouldn't have to use tainted mode of course. This can/
>> should be
>> turned off by default.
>
> safe_mode is/was off by default to, and yet a good chunk of hosts
> enabled it
On Fri, December 15, 2006 4:31 pm, Wietse Venema wrote:
> Even if some taint check is to restrictive at some point in time,
> the programmer can always overcome it with an explicit action.
Would that require some sort of bogus string non-manipulation, or do
you foresee a "untaint" function which d
On Fri, December 15, 2006 5:12 pm, Ilia Alshanetsky wrote:
> And here is your first exploit, let's say we say
> mysql_real_escape_string() takes tainted data and makes it untainted,
> what happens when this "safe" data is passed to exec(). You are going
> to need to deal with different levels of ta
So, what if an ISP (webhost) enables taint functionality, and a
developer uses a PHP library that uses custom filter functions for
filtering data. Will this developer see messages displayed on his PHP
application even though filtering is being done?
Jordan
--
PHP Internals - PHP Runtime Developm
On Fri, December 15, 2006 5:43 pm, Ilia Alshanetsky wrote:
> Consider E_NOTICE, it is a superb tool for finding out things like un-
> declared variables (which often cause all manner of exploits), and
> yet most developers keep it off because it gets in a way, even though
> it has 0 false positives
On Fri, December 15, 2006 6:47 pm, Andi Gutmans wrote:
> Time to turn it off in php.ini-dist in addition to
> php.ini-recommended?
+1
Let the developers turn it ON for a dev box.
This will, however, unleash a zillion questions on PHP-General and in
forums...
So be it.
--
Some people have a "g
Hello,
On 12/16/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
Time to turn it off in php.ini-dist in addition to php.ini-recommended?
I think so, and to "fix" what Hannes suggested earlier this week
(http://news.php.net/php.internals/26936).
--Pierre
ps: I shamelessly point you&co to my JIT/un
Time to turn it off in php.ini-dist in addition to php.ini-recommended?
> -Original Message-
> From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] On Behalf Of
> Ilia Alshanetsky
> Sent: Friday, December 15, 2006 4:04 PM
> To: Stanislav Malyshev
> Cc: PHP internals
> Subject: Re: [PHP-DEV]
Ilia Alshanetsky:
> And here is your first exploit, let's say we say
> mysql_real_escape_string() takes tainted data and makes it untainted,
> what happens when this "safe" data is passed to exec().
You need a malicous code writer to have an exploit. As far as I
know, PHP is not a platform for
Something that most servers do (almost 80% by recent stats).
http://www.nexen.net/images/stories/phpinfos/display_errors.png
You mean "most of the servers that allow strangers to read their
phpinfo()"? I'm not surprised. You think if they expose their phpinfo
you can make it worse by seeing
Now that that's done, what do we do with macros like this?
#define convert_to_ex_master(ppzv, lower_type, upper_type) \
if (Z_TYPE_PP(ppzv)!=IS_##upper_type) { \
SEPARATE_ZVAL_IF_NOT_REF(ppzv); \
convert_to_##lower_type(*ppzv);
On Fri, 2006-12-15 at 18:43 -0500, Ilia Alshanetsky wrote:
> On 15-Dec-06, at 6:27 PM, Stanislav Malyshev wrote:
>
> Not quite. If you have a function that let's say designed
> specifically to take unsafe data and make it safe for a particular
> use. For example htmlentities(value, ENT_QUOTES)
On 15-Dec-06, at 7:01 PM, Stanislav Malyshev wrote:
the harm. One simple exploit leading to information disclosure is
to pass it an array() causing the function to generate an error
exposing the script's path.
You mean when running with display_errors = on? Ouch.
Something that most serv
the harm. One simple exploit leading to information disclosure is to
pass it an array() causing the function to generate an error exposing
the script's path.
You mean when running with display_errors = on? Ouch.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.c
On 15-Dec-06, at 6:40 PM, Alain Williams wrote:
OK: so there may be a few cases where it won't work, that does not
mean
that there won't be great advantages for the majority of situations.
I'd wager there would be more then a few instances, but without code
its kinda hard to demonstrate.
On 15-Dec-06, at 6:28 PM, Stanislav Malyshev wrote:
I'd say you have pretty weird code if you do include $_POST
['VAR']; and yet people do exactly that.
And if we had tainting, people would know it's bad, and would know
why. :)
Bitmask identifying different taint modes.
Can you elabora
(I realize that I haven't got any karma here. Just want to offer a
users point of view. :))
I think this would make a great addition. Just not for educational
purposes, but also to help experienced developers avoid missing holes.
Ilia wrote:
safe_mode is/was off by default to, and yet a good c
On 15-Dec-06, at 6:27 PM, Stanislav Malyshev wrote:
So you claim that without taint mode it is not possible to write
safe PHP code?
Actually, I said exactly the opposite - if you write secure code,
you do not need it. If you are concerned about your code
potentially being buggy and do no
On Fri, Dec 15, 2006 at 06:32:06PM -0500, Ilia Alshanetsky wrote:
> I think people generally follow the path of least resistance and for
> compat purposes I suspect most application will simply create a quick
> wrapper to **untaint** all input data so they can use it within their
> applicati
On 15-Dec-06, at 6:21 PM, Andi Gutmans wrote:
Well you wouldn't have to use tainted mode of course. This can/
should be
turned off by default.
safe_mode is/was off by default to, and yet a good chunk of hosts
enabled it under the assumption it would make their setups secure.
I think havi
I'd say you have pretty weird code if you do include $_POST['VAR']; and
yet people do exactly that.
And if we had tainting, people would know it's bad, and would know why. :)
Bitmask identifying different taint modes.
Can you elaborate which modes do you propose?
--
Stanislav Malyshev, Zend
So you claim that without taint mode it is not possible to write safe
PHP code?
Actually, I said exactly the opposite - if you write secure code, you do
not need it. If you are concerned about your code potentially being
buggy and do not want to rely only on your own smarts to avoid it - you
Well the tool would point the developer at the data they have to
validate/filter. At that point the developer has to have a brain and needs
to know what he's doing with the data. Fortunately, if he has the right sets
of APIs in ext/filter which help him with this task, then it should be clear
to th
Well you wouldn't have to use tainted mode of course. This can/should be
turned off by default.
I think having such a mode would be of great help to many users though. It
would allow them to find any quirks in their data/input filtering and help
them focus on where they should do a better job. Of c
On 15-Dec-06, at 6:18 PM, Stanislav Malyshev wrote:
And here is your first exploit, let's say we say
mysql_real_escape_string() takes tainted data and makes it
untainted, what happens when this "safe" data is passed to exec().
You are going to
I'd say you have really weird code if you do
On 15-Dec-06, at 6:14 PM, Stanislav Malyshev wrote:
That's exactly it, PHP is popular because it is easy to use. You
take that away and quite frankly there is very little reason to
left to use PHP over C#, Python, etc...
Well, this is old :) Discussing every feature there are people that
And here is your first exploit, let's say we say
mysql_real_escape_string() takes tainted data and makes it untainted,
what happens when this "safe" data is passed to exec(). You are going to
I'd say you have really weird code if you do mysql_real_escape_string()
in order to pass the data to
On 15-Dec-06, at 6:11 PM, Stanislav Malyshev wrote:
All it means is extra work for developers with little or no
tangible benefits. I also wonder how taint will work with the
standard remove/add
Security is benefit. Of course, the developers that are sure they
write secure code anyway nee
That's exactly it, PHP is popular because it is easy to use. You take
that away and quite frankly there is very little reason to left to use
PHP over C#, Python, etc...
Well, this is old :) Discussing every feature there are people that say
"until PHP does foo-feature, it can not be considered
On 15-Dec-06, at 6:06 PM, Wietse Venema wrote:
Ilia Alshanetsky:
On 15-Dec-06, at 5:19 PM, Wietse Venema wrote:
Ilia Alshanetsky:
That means an additional element to a struct that has thousands of
instances in most scripts, this will be the first overhead
caused by
the memory footprint in
All it means is extra work for developers with little or no tangible
benefits. I also wonder how taint will work with the standard remove/add
Security is benefit. Of course, the developers that are sure they write
secure code anyway need not be bothered by tainting and can leave it off
foreve
On 15-Dec-06, at 6:02 PM, Alain Williams wrote:
Php is easy to write, that is good. Unfortunately this also means that
bad/simple/careless programmers can use php ... these are the ones who
cause many of the php script errors that cause problems.
That's exactly it, PHP is popular because it i
Ilia Alshanetsky:
> On 15-Dec-06, at 5:19 PM, Wietse Venema wrote:
> > Ilia Alshanetsky:
> >> That means an additional element to a struct that has thousands of
> >> instances in most scripts, this will be the first overhead caused by
> >> the memory footprint increase.
> >
> > There is no need for
On 15-Dec-06, at 5:31 PM, Wietse Venema wrote:
Ilia Alshanetsky:
On 15-Dec-06, at 4:16 PM, Stanislav Malyshev wrote:
Sounds awefuly like yet another safe_mode, something that
proclaims security, yet being unable to provide it.
Repeating my comments on that, I think that it can be done not
On Fri, Dec 15, 2006 at 05:31:57PM -0500, Wietse Venema wrote:
> Ilia Alshanetsky:
> >
> > On 15-Dec-06, at 4:16 PM, Stanislav Malyshev wrote:
> >
> > >> Sounds awefuly like yet another safe_mode, something that
> > >> proclaims security, yet being unable to provide it.
> > >
> > > Repeating my
On 15-Dec-06, at 4:58 PM, Stanislav Malyshev wrote:
Ok this is better, but it will break every single application out
there. I for one think that this is unacceptable.
Well, initially - yes. With some tweaking like using automatic
filters taint-safeguarding should not be too hard though (t
On 15-Dec-06, at 5:19 PM, Wietse Venema wrote:
Ilia Alshanetsky:
- Each ZVAL is marked tainted or not tainted (i.e. we don't taint
individual characters within substrings). Black and white is all.
In some future, someone may want to explore the possibility of
more than two shades. But n
Ok this is better, but it will break every single application out there.
I for one think that this is unacceptable.
Well, initially - yes. With some tweaking like using automatic filters
taint-safeguarding should not be too hard though (this would be one of
the milestones - if we can't make it
Ilia Alshanetsky:
>
> On 15-Dec-06, at 4:16 PM, Stanislav Malyshev wrote:
>
> >> Sounds awefuly like yet another safe_mode, something that
> >> proclaims security, yet being unable to provide it.
> >
> > Repeating my comments on that, I think that it can be done not like
> > safe_mode, if we
Ilia Alshanetsky:
> > - Each ZVAL is marked tainted or not tainted (i.e. we don't taint
> > individual characters within substrings). Black and white is all.
> > In some future, someone may want to explore the possibility of
> > more than two shades. But not now.
>
> That means an additiona
Hi Marc,
On 12/15/06, Marc Delling <[EMAIL PROTECTED]> wrote:
Hello, I'm Marc and I'm new to this list. Whew! That was easy!
I've read in the archive about a patch for supporting openssl pkcs12,
First, thanks for this patch :)
but nothing seems to be done so far. Since I was missing the sam
On 15-Dec-06, at 4:16 PM, Stanislav Malyshev wrote:
Sounds awefuly like yet another safe_mode, something that
proclaims security, yet being unable to provide it.
Repeating my comments on that, I think that it can be done not like
safe_mode, if we take different approach. Namely, not "mark
Sounds awefuly like yet another safe_mode, something that proclaims
security, yet being unable to provide it.
Repeating my comments on that, I think that it can be done not like
safe_mode, if we take different approach. Namely, not "mark unsafe,
accept otherwise" but "mark safe, deny otherwise
On 15-Dec-06, at 3:14 PM, Wietse Venema wrote:
This is a proposal to add basic Perl/Ruby like tainting support to
PHP: an option that is turned off by default, and that programmers
may turn on at runtime to alert them when they make the common
mistake of using uncleansed input with include, echo
Please allow me to introduce myself briefly: I'm Wietse Venema from
IBM Research, also known as the creator of the open source Postfix
mail system, co-author of the Coroner's toolkit and SATAN, and the
original author of TCP Wrapper. That doesn't mean everything I touch
becomes gold; if it did then
Hello Marc,
you cannot use c++ style comments '//', see CODING_STANDARDS.
Rest looks good on a first glimpse.
best regards
marcus
Friday, December 15, 2006, 6:27:13 PM, you wrote:
> Hello, I'm Marc and I'm new to this list. Whew! That was easy!
> I've read in the archive about a patch for su
> I know we had discussion about *fprintf() on IRC,
> but I'm still not clear on some stuff.
>
> Sara, could you please explain again why UG(unicode)
> should not be used as the selection for
> php_formatted_print/php_u_formatted_print? I
> bet a few of us are hazy on the streams Unicode/binary
>
Hello, I'm Marc and I'm new to this list. Whew! That was easy!
I've read in the archive about a patch for supporting openssl pkcs12,
but nothing seems to be done so far. Since I was missing the same
thing when trying to code a quick-and-dirty certificate management
webapp I decided to write
On 15-Dec-06, at 8:05 AM, Edin Kadribasic wrote:
Windows build is ready too:
Thanks.
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Windows build is ready too:
http://downloads.php.net/edink/php-5.2.1RC1-Win32.zip
http://downloads.php.net/edink/php-5.2.1RC1-win32-installer.msi
http://downloads.php.net/edink/pecl-5.2.1RC1-Win32.zip
http://downloads.php.net/edink/php-debug-pack-5.2.1RC1-Win32.zip
MD5 (php-5.2.1RC1-Win32.zip) =
64 matches
Mail list logo
