Antony Dovgal wrote:
> On 20.05.2007 12:15, Sebastian Nohn wrote:
>> Antony Dovgal wrote:
>>
> Any chance to get GDB backtrace?
>>>
>>> Aha.. I see..
>>> Could you please try the patch attached?
>>
>> Works.
>
> Fixed, thanks for the heads up.
Don't mention it. It was easy with
http://conflue
On Sat, May 19, 2007 4:42 am, Cristian Rodriguez wrote:
>>2007/5/18, Stanislav Malyshev <[EMAIL PROTECTED]>:
>> Sane hosters do not rely on general-purpose language to provide
>> security, they use OS and hardware designed for exactly that
>> purpose. ;)
>
> unfortunately hosters has to equilibrate
On Sat, May 19, 2007 3:00 am, Stefan Esser wrote:
>
>> If you are aware of some security problems in current PHP sources
>> you
>> are as always welcome to report them and they will be fixed. I think
>> everybody here as always are thankful for any help we can get.
> Ohh BTW. I am aware of many sec
Why is it that you all fight worse than my 3rd year old cousins? I
don't hold any authority or figure what so ever, but I watch
internals as a developer to be forewarned, but really, all I see is a
bunch of children fighting with each other.
Stefan has made contributions and has helped...
Marcus Boerger wrote:
>
> yes
>
I will submit it to bugs.php.net
>
> in the same manner i guess it makes no sense tocommunicate further? :-)
>
> this is a general consideration, people should stop sending these non
> applicable message stubs. They render open source unuseable.
>
Yeah, as much
thing is that I don't see macros ZVAL_SAFE_REF_ADD and ZVAL_SAFE_REF_SET
used anywhere, so probably there's no need for them.
My bad - they are used of course, I just looked into the wrong place.
I would however rename ZVAL_SAFE_REF to something like ZVAL_SAFE_ADDREF.
Also, comparing values to 0
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
Hello Ralph,
Monday, May 21, 2007, 9:32:27 PM, you wrote:
> Is this a problem or not?
> The following will produce this notice:
> Strict Standards: Declaration of Z_Concrete::__get() should be
> compatible with that of Z_Abstract::__get() in xxx on line 16
> error_reporting(E_ALL | E_STRICT)
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
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
I tested this patch on bench.php - surprisingly, no substantial
per
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
On Sat, May 19, 2007 4:00 am, Stefan Esser wrote:
> Antony is very fast with assigning bugs to persons that have nothing
> todo with them.
> I believe there is still a bug assigned to me because in Antony's
> world
> I am responsible for it, while infact
> my commit was in a version AFTER the one t
On Fri, May 18, 2007 12:03 pm, Derick Rethans wrote:
> On Fri, 18 May 2007, Rasmus Lerdorf wrote:
>
>> Stanislav Malyshev wrote:
>> > Looks like we have a precedence bug in the parser rules there.
>> > Fortunately it's quite easy to fix, for example writing the rules
>> as:
>> >
>> > |'+'
On Fri, May 18, 2007 6:47 pm, Cristian Rodriguez wrote:
> 2007/5/18, Greg Beaver <[EMAIL PROTECTED]>:
>
>> > include $_GET['dumb'];
>> ?>
>>
>
> What about permanently removing this (mis) "feature" ?? , Im yet to
> hear any valid reason or example to continue to permit this remote
> include thingy,
On Fri, May 18, 2007 10:51 am, Greg Beaver wrote:
> The solution:
> =
> Add a new function: stream_wrapper_set_local()
So, basically, your function would be similar to:
"I'm removing the safety from the gun with which I might shoot myself
in the foot."
:-) :-) :-)
Would it be applie
They are not documented and I am testing configurations that might
break
scripts. If I test things and want to make code portable,
configuration is
not supposed to be rational. I can set option with ini_set(), if I
understand what option does and it fixes the issue.
http://www.php.net/unicode
Is this a problem or not?
The following will produce this notice:
Strict Standards: Declaration of Z_Concrete::__get() should be
compatible with that of Z_Abstract::__get() in xxx on line 16
The only difference is that the former has an interface as a parent, the
latter does not. Is this a
On Mon, May 21, 2007 9:57 am, Stefan Walk wrote:
> On 21/05/07, Tomas Kuliavas <[EMAIL PROTECTED]> wrote:
>> Latin capital letter A with diaeresis is 00C4. Not C4.
>
> Pay attention in maths, leading zeroes don't change a number.
Pay attention to documentation. Leading zeros change a number.
O
The attached patch fixes CVE-2007-1285 (nesting variables in input
crash) for 4.x branch - release notes say it's fixed but in fact it
never was.
Objections?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
Index: main/main.c
>> 0xC4 and 0x85 are hex codes for latin small letter a with ogonek in
>> utf-8. ą
>>
>> > var_dump("ą" == "\xC4\x85");
>> echo "ą\n";
>> echo "\xC4\x85";
>> ?>
>>
>> If script is written in utf-8, I expect bool(true) on var_dump() line.
>
> var_dump("ą" == b"\xC4\x85");
>
> This will give you what
On May 19, 2007, at 11:13 PM, Tomas Kuliavas wrote:
0xC4 and 0x85 are hex codes for latin small letter a with ogonek in
utf-8. ą
If script is written in utf-8, I expect bool(true) on var_dump() line.
var_dump("ą" == b"\xC4\x85");
This will give you what you want, if the script is written
This is by design. If you prefer to work with actual bytes, use
binary strings or literals. In unicode strings \xC4 is actually a
codepoint (UTF-16 codepoint) specifying character U+00C4.
-Andrei
On May 19, 2007, at 8:48 AM, Tomas Kuliavas wrote:
strlen("\xC4\x85") = 2. strlen((binary)"\xC
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
Hi everyone,
We ran into some annoyance bugs with 5.2.2 version of the installer,
mostly related to Apache and IIS configuration. I've posted an
"unofficial" re-spin of the installer from the original PHP 5.2.2
binaries; does anyone have an objection to putting that on
php.net/downloads as well?
>> Latin capital letter A with diaeresis is 00C4. Not C4.
>
> Pay attention in maths, leading zeroes don't change a number.
they do, if it is not a number.
'00C4' + '0085' = '00C40085'
'C4' + '85' = 'C485'
'00C40085' != 'C485'
--
Tomas
--
PHP Internals - PHP Runtime Development Mailing Lis
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
On 21/05/07, Tomas Kuliavas <[EMAIL PROTECTED]> wrote:
Latin capital letter A with diaeresis is 00C4. Not C4.
Pay attention in maths, leading zeroes don't change a number.
I wrote two 8bit values. Not two 16bit ones. Interpreter tries to outsmart
me and thinks that I want 00C4, when I write C
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
On 21.05.2007 14:15, Lester Caine wrote:
Antony Dovgal wrote:
Want to help me with that (or maintainers with bugs in their extensions)?
I'd gladly accept both, even though bugfixes are much more welcome =)
I'm trying to get up to speed to do work on the interbase/firebird package,
The half do
Antony Dovgal wrote:
Want to help me with that (or maintainers with bugs in their extensions)?
I'd gladly accept both, even though bugfixes are much more welcome =)
I'm trying to get up to speed to do work on the interbase/firebird package,
The half dozen bugs there have been around for long e
PHP 6 Bug Database summary - http://bugs.php.net
Num Status Summary (44 total including feature requests)
===[*General Issues]==
26771 Suspended register_tick_funtions crash under threaded webservers
27372 Verified parse error loadin
PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (632 total including feature requests)
===[*Directory/Filesystem functions]
40661 Open cwd is reset when shutdown handler runs
===
test
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
>> 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
On 21.05.2007 11:55, Lester Caine wrote:
Well, there's a reason - not every developer watches bugs closely.
Thanks to great work by Antony, there's somebody who does that, but we
can't realistically expect every maintainer to do that, so assigning
bugs is the means to alert the developer that t
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
Stanislav Malyshev wrote:
I don't see ANY reason bugs should be assigned by anybody other than
the person who is ACTUALLY working on it?
*IF* someone has time or has found a fix for a problem, THEY assign
the bug to them selves and put up the fix.
Well, there's a reason - not every developer w
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
On 20.05.2007 12:15, Sebastian Nohn wrote:
Antony Dovgal wrote:
Any chance to get GDB backtrace?
Aha.. I see..
Could you please try the patch attached?
Works.
Fixed, thanks for the heads up.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
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
49 matches
Mail list logo
