Hi,
2012/4/9 Arvids Godjuks <arvids.godj...@gmail.com>:
> 8 апреля 2012 г. 8:16 пользователь Yasuo Ohgaki <yohg...@ohgaki.net>написал:
>
>> 2012/4/8 Ángel González <keis...@gmail.com>:
>> > On 07/04/12 22:48, Yasuo Ohgaki wrote:
>> >> Hi,
>> >>
>> >> The only valid reason for removing <?php from PHP script would be
>> >> security.
>> >>
>> >> Since the null byte detection for fopen, remote/local script inclusion
>> >> became much harder than before. However, it's still possible and very
>> >> easy compare to other languages. Script execution is critical security
>> >> problem and it's worth to make it better.
>> >>
>> >> If there is a switch that turns off PHP's template engine nature, PHP
>> >> could be more secure than now.
>> >>
>> >> php.ini
>> >> template_mode = on ; INI_ALL On by default
>> >>
>> >> php -t foo.php # template mode by default
>> >> php -T foo.php # template mode off
>> >>
>> >> People has option to make their code a little secure than now
>> >> or stick with current behavior.
>> >>
>> >> Regards,
>> > How does it help security?
>> > If any, requiring '<?php' before executable code makes easier to filter
>> > out malicious files on apps with uploads in case there's a local
>> > inclusion vulnerability somewhere.
>> >
>>
>> Attackers may inject PHP script almost anything/anywhere since
>> PHP code may be embed anywhere in a file.
>>
>> For example, malicious PHP script may be in GIF something like
>>
>> gif89a ...any data.. <?php exec('rm -rf /') ?>
>>
>> and all attacker have to do is include/require the data somehow.
>> Attacker cannot do that this for other languages, since they are
>> not a embedded language. I know case that attackers may inject
>> malicious perl/ruby script in data files, but PHP is too easy
>> compare to these languages.
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
> Improperly configured WEB server is not the reason to change the most basic
> part of the language that will break every damn application out there.
This is not an configuration issue, but a security vulnerability that
can simply closed by disabling embed mode.
As I mentioned already, injecting malformed PHP scripts into files
is too easy compare to other languages. This could be improved
by simple modification and we can maintain compatibility with it.
I don't see anything wrong here.
Yet another PHP script injection example.
There are many applications that store user inputs in $_SESSION.
Attacker can inject PHP script into $_SESSION, then locally include
it. This is easy since attacker knew their session ID and path to
session file is can be guessed easily. All attacker has to do is
finding a vulnerable include()/require() to attack.
Regards,
--
Yasuo Ohgaki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
