Rasmus Lerdorf schrieb:
> Adding a check on every refcount increase is a bit
> scary for the performance folks. It may be that in most realworld cases
> this is an acceptable performance tradeoff. We have to balance the
> seriousness of the vulnerability against the performance cost of the
> fix.
i've heard (though not confirmed myself) that if php is running as a
loadable apache module it is possible to use such a local attack
vector to read from the apache parent's memory, and extract tasty
morcels such as unencrypted SSL keys. obviously this would have an
I don't know if it's possib
hi guys,
sorry to butt in here, but thought i'd have something to add/ask:
On Mon, 2007-05-21 at 15:49 -0500, Richard Lynch wrote:
>
> If I'm understanding this correctly, (and that's definitely debatable)
> there seems to be an awfully large "hole" there of being able to poke
> random bits of R
For the record: I dunno why you left, but the MOPB ombudsman-like
approach of a security audit is a GOOD THING, imho, so I would like to
see that work continue to YOPB :-)
Security audit is not just good, it's great. Everybody should have one
:) So I don't think there's any problem with MOPB a
On Mon, May 21, 2007 3:11 am, Stefan Esser wrote:
> For example to get around non-executable HEAP situation you first need
> to
> poke the right offsets in memory to "reenable" the dl() function (NOT
> possible
> with plain PHP code), find some writeable diskspace, dump a shared
> library
> there a
For example to get around non-executable HEAP situation you first need to
poke the right offsets in memory to "reenable" the dl() function (NOT
possible
with plain PHP code), find some writeable diskspace, dump a shared library
there and load it. From there you can execute whatever kernel exploit
why not let the choise to the php user ?
with configurable option ?
There's no way to make it configurable option, since it'd require having
2 separate engines in the language.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
PHP Internals - PHP Runtime
_
From: Nuno Lopes [mailto:[EMAIL PROTECTED]
... I would love to ear how other VMs handle the
problem, like the JVM, anyone?yes, me too!
_
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
I don't think they are "not important", just that they are not important
enough to want them fixed no matter the cost. Running shared hosted
server in a mode that relies on restricted code IMO is wrong anyway, and
for non-shared e
For the record the patch I had is this:
http://mega.ist.utl.pt/~ncpl/zend_stack_protection.txt (it shouldn't
apply cleanly due to some changes in zend_try some time ago).
Ah, this is different think - it's more like a nice error message, not
preventing stack depletion.
Knowing in advance if
I don't imagine how one really could calculate maximum depth without
solving the halting problem, so I must be missing something. I ask
somebody who knows what these patches are to send me a link - if there
were patches that do that automatically for any code I would very much
like to see them.
Ad
Am Sonntag, 20. Mai 2007 12:28 schrieb Stefan Esser:
> it is no secret that I am really sick and tired of this constant stream
> of nonsense and
> lies comming out of the mouths of PHP developers when it comes to
> security issues.
What I do not understand than is, why are you doing all this?
Yo
>> Well yes. I think to solve this "once and for all" a public statement by
>> the PHP group would be nice that says:
> "We are no longer wasting time fixing security problems in PHP4 that
> have already been addressed in the current version of PHP - PHP5 - So
> no further development time will be
Alexey Zakhlestin schrieb:
> the problem is, that, in this case, code is not broken. it is not an
> error to use large stack.
> it is an error to let someone use the low-level side-effects of a
> problem in a high-level language.
Uhmm you only look at the MOPB #2 issue. The main point of this whole
Stefan Esser wrote:
Stanislav Malyshev schrieb:
I am fully aware that it can be made faster. But a slow solution is
better than no solution at all.
Actually in many situations it isn't. Since as far as I can see the
problem can lead to real harm only in rather limited set of
situations, making
Stanislav Malyshev schrieb:
>> Well yes. I think to solve this "once and for all" a public statement by
>> the PHP group would be nice that says:
>
> I don't think they are "not important", just that they are not
> important enough to want them fixed no matter the cost. Running shared
> hosted serv
the problem is, that, in this case, code is not broken. it is not an
error to use large stack.
it is an error to let someone use the low-level side-effects of a
problem in a high-level language.
On 5/21/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Well yes. I think to solve this "once and
Well yes. I think to solve this "once and for all" a public statement by
the PHP group would be nice that says:
I don't think they are "not important", just that they are not important
enough to want them fixed no matter the cost. Running shared hosted
server in a mode that relies on restricte
Maybe I was a bit unspecific. If I recall correctly Nuno had some patch
(or was it someone else) that was keeping track of depth and maximum
stack size
and was deciding on the fly if another step deeper could crash. Of
I would very much like to know how he does that. If the solution does
not in
Stanislav Malyshev schrieb:
>> I am fully aware that it can be made faster. But a slow solution is
>> better than no solution at all.
>
> Actually in many situations it isn't. Since as far as I can see the
> problem can lead to real harm only in rather limited set of
> situations, making the engine
I am fully aware that it can be made faster. But a slow solution is
better than no solution at all.
Actually in many situations it isn't. Since as far as I can see the
problem can lead to real harm only in rather limited set of situations,
making the engine always considerably slower just to f
> The function call does strike me as completely unnecessary and the additional
> stack operations required are expensive. I'm willing to be that if the
> function was converted to a macro, the proposed solution would be a workable
> fix. Just my two cents; I'm not very experienced with the PHP
On Sun, 20 May 2007, David wrote:
> The function call does strike me as completely unnecessary and the
> additional stack operations required are expensive. I'm willing to be
> that if the function was converted to a macro, the proposed solution
> would be a workable fix. Just my two cents; I'm
bench.php is a totally unrealistic benchmark that has nothing todo with
real life PHP applications. Of course when you call a function several
It tests the engine speed. Of course, in life of PHP script there are
other things, that's why I said "and" - to put it in context.
million times the
the vast mayority of users will be happy with a more secure system and
will like accept a 0.0.0.0.0.0.0.0.0.1% slowdown in case it is slow..
Sure, if only we knew that's not 10% slowdown.
I sometimes wonder what it is real target of PHP, the masses or a
selected neglible group of users that r
> I don't imagine how one really could calculate maximum depth without
> solving the halting problem, so I must be missing something. I ask
> somebody who knows what these patches are to send me a link - if there
> were patches that do that automatically for any code I would very much
> like to se
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Dismantling the lies...
> no, no performance tests has been done over that patch, but as rasmus
> said. it is probably negible or acceptable for real world.. I only
> knows it works with real like code ( i tried ezpublish, phpmyadmin)
>
> Well, php test suite is a functional test, so if the patch is done
> correctly it'd pass of course. I'm moe worried about the performance -
> my experience shows that the guesses are often wrong when talked about
> performance effects in complicated code. If you would have time to run
> a benc
2007/5/21, Stanislav Malyshev <[EMAIL PROTECTED]>:
I'm moe worried about the performance -
the vast mayority of users will be happy with a more secure system and
will like accept a 0.0.0.0.0.0.0.0.0.1% slowdown in case it is slow..
I sometimes wonder what it is real target of PHP, the masses
no, no performance tests has been done over that patch, but as rasmus
said. it is probably negible or acceptable for real world.. I only
knows it works with real like code ( i tried ezpublish, phpmyadmin)
and passes the PHP test suite correctly ( or no worse than without the
patch)
Well, php tes
2007/5/21, Stanislav Malyshev <[EMAIL PROTECTED]>:
> at openSUSE, we also have a patch for this issue since a few weeks, as
> a vendor unfortunately we have to take care of things that people
> here dont want to fix...
>
> http://www.flyspray.org/patches/MOPB-01-abicompatible.patch.bz2
Did you
> You make things sound very black and white when they are usually grey.
>
You only don't realise how black things are.
> this is an acceptable performance tradeoff. We have to balance the
> seriousness of the vulnerability against the performance cost of the
>
Yeah well. Luckily since Suh
at openSUSE, we also have a patch for this issue since a few weeks, as
a vendor unfortunately we have to take care of things that people
here dont want to fix...
http://www.flyspray.org/patches/MOPB-01-abicompatible.patch.bz2
Did you perform the performance tests for this patch? What were the
In the other thread, where Stanislav spreads the usual lie/propaganda
that there is no help comming from me to the PHP developers, he also
claims
For the record - I never said that. I said that in that thread, as
in some of its predecessors, when it came from general discussion to the
substance
Stefan Esser wrote:
> The reason for this fix not being applied is not it's impossibility, but
> because the
> closed source extension developers (everyone knows who they are) don't want
> another binary compatibility break, because then their closed source
> extensions
> have to be shipped in yet
Cristian Rodriguez schrieb:
>> Here is the patch I created in approximately half an hour. A solution to
>> a problem
>
>> that is *NOT* fixable at the moment, according to Stanislav.
>
> at openSUSE, we also have a patch for this issue since a few weeks, as
> a vendor unfortunately we have to take
Here is the patch I created in approximately half an hour. A solution to
a problem
that is *NOT* fixable at the moment, according to Stanislav.
at openSUSE, we also have a patch for this issue since a few weeks, as
a vendor unfortunately we have to take care of things that people
here dont w
Hello,
it is no secret that I am really sick and tired of this constant stream
of nonsense and
lies comming out of the mouths of PHP developers when it comes to
security issues.
In the other thread, where Stanislav spreads the usual lie/propaganda that
there is no help comming from me to the PHP
38 matches
Mail list logo
