Stefan Esser writes here:
http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html
that allow_url_include (and allow_url_fopen) can be easily worked around
- i.e. extrenally-supplied code executed on server - by using php: and
data: URLs. I think if we want allow_url_include have any value than we
should fix it... What do you think?
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
Stefan Esser writes here:
http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.htmlthat allow_url_include (and allow_url_fopen) can be easily worked around
- i.e. extrenally-supplied code executed on server - by using php: and
data: URLs. I think if we want allow_url_include have any value than we
should fix it... What do you think?
Yeah, we probably should. Had a chat with Wez about it too. Here is
the patch. I think this catches the cases we are interested in:
http://lerdorf.com/php/is_url.diff
If someone could doublecheck it against those attacks it would be helpful.
-Rasmus
On Sat, 04 Nov 2006 12:40:01 -0800, in php.internals
rasmus@lerdorf.com (Rasmus Lerdorf) wrote:
Yeah, we probably should. Had a chat with Wez about it too. Here is
the patch. I think this catches the cases we are interested in:http://lerdorf.com/php/is_url.diff
If someone could doublecheck it against those attacks it would be helpful.
Would requests to a smbserver, e.g.
\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It
seems like smbserver requests are regarded as part of the default
filesystem wrapper.
--
- Peter Brodersen
Would requests to a smbserver, e.g.
\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It
seems like smbserver requests are regarded as part of the default
filesystem wrapper.
Good point. Generally I'd say it belongs to the OS, but I'm not sure if
you can restrict this from OS side?
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
I think it'd be wrong to consider networked file system as non-local.
Mostly because many times there are no ways to identify them reliable
and the fact this is a perfectly valid usage that if disallowed by
default would break a large number of applications.
On Sat, 04 Nov 2006 12:40:01 -0800, in php.internals
rasmus@lerdorf.com (Rasmus Lerdorf) wrote:Yeah, we probably should. Had a chat with Wez about it too. Here is
the patch. I think this catches the cases we are interested in:http://lerdorf.com/php/is_url.diff
If someone could doublecheck it against those attacks it would be
helpful.Would requests to a smbserver, e.g.
\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It
seems like smbserver requests are regarded as part of the default
filesystem wrapper.--
- Peter Brodersen
--
Ilia Alshanetsky
I think it's a fair assumption that a random host specified in that
way be treated as suspicious and lumped in under the
disable-includes-by-default category.
If someone discovers that it breaks their app, when they read the docs
for allow_url_include it should be made very clear what the
implications are and what should be done prior to turning it on.
So i have no problem with disallowing includes for paths beginning
with a double backslash on windows, when allow_url_include is
disabled.
--Wez.
I think it'd be wrong to consider networked file system as non-local.
Mostly because many times there are no ways to identify them reliable
and the fact this is a perfectly valid usage that if disallowed by
default would break a large number of applications.On Sat, 04 Nov 2006 12:40:01 -0800, in php.internals
rasmus@lerdorf.com (Rasmus Lerdorf) wrote:Yeah, we probably should. Had a chat with Wez about it too. Here is
the patch. I think this catches the cases we are interested in:http://lerdorf.com/php/is_url.diff
If someone could doublecheck it against those attacks it would be
helpful.Would requests to a smbserver, e.g.
\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It
seems like smbserver requests are regarded as part of the default
filesystem wrapper.--
- Peter Brodersen
--
Ilia Alshanetsky
I think it's a fair assumption that a random host specified in that
way be treated as suspicious and lumped in under the
disable-includes-by-default category.
What's random? Non localhost/127.0.0.1 ?
If someone discovers that it breaks their app, when they read the docs
for allow_url_include it should be made very clear what the
implications are and what should be done prior to turning it on.So i have no problem with disallowing includes for paths beginning
with a double backslash on windows, when allow_url_include is
disabled.--Wez.
I think it'd be wrong to consider networked file system as non-local.
Mostly because many times there are no ways to identify them reliable
and the fact this is a perfectly valid usage that if disallowed by
default would break a large number of applications.On Sat, 04 Nov 2006 12:40:01 -0800, in php.internals
rasmus@lerdorf.com (Rasmus Lerdorf) wrote:Yeah, we probably should. Had a chat with Wez about it too.
Here is
the patch. I think this catches the cases we are interested in:http://lerdorf.com/php/is_url.diff
If someone could doublecheck it against those attacks it would be
helpful.Would requests to a smbserver, e.g.
\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It
seems like smbserver requests are regarded as part of the default
filesystem wrapper.--
- Peter Brodersen
--
Ilia Alshanetsky
--
Ilia Alshanetsky
Hi,
On Sun, 5 Nov 2006 11:23:03 -0500, in php.internals ilia@prohost.org
(Ilia Alshanetsky) wrote:
I think it's a fair assumption that a random host specified in that
way be treated as suspicious and lumped in under the
disable-includes-by-default category.What's random? Non localhost/127.0.0.1 ?
Actually any smb server that is requested thorugh PHP's means of
fetching a resource (\smbserver...) instead of a device mount in the
operating system (e.g. Z:\ ...).
--
- Peter Brodersen
What's to say /drive/smb or letter:// is not an SMB device? Also why
break perfectly valid applications that perform operations on
networked file systems?
Hi,
On Sun, 5 Nov 2006 11:23:03 -0500, in php.internals ilia@prohost.org
(Ilia Alshanetsky) wrote:I think it's a fair assumption that a random host specified in that
way be treated as suspicious and lumped in under the
disable-includes-by-default category.What's random? Non localhost/127.0.0.1 ?
Actually any smb server that is requested thorugh PHP's means of
fetching a resource (\smbserver...) instead of a device mount in the
operating system (e.g. Z:\ ...).--
- Peter Brodersen
Ilia Alshanetsky
Ilia Alshanetsky wrote:
What's to say /drive/smb or letter:// is not an SMB device? Also why
break perfectly valid applications that perform operations on networked
file systems?
We are only talking about marking them as is_url which doesn't have
anything to do with performing normal operations on networked
filesystems. How many real apps rely on being able to execute code via
an smb include? The exact same argument could me made for a localhost
http or ftp include which we also disallow. The fact that someone can
map a remote machine to a local drive actually means that they can make
sure their app works because then they have pre-configured which hosts
are valid hosts for this use. If a bad guy can mount remote filesystems
onto your server, then you have bigger problems.
-Rasmus
Ilia Alshanetsky wrote:
What's to say /drive/smb or letter:// is not an SMB device? Also why
break perfectly valid applications that perform operations on
networked
file systems?We are only talking about marking them as is_url which doesn't have
anything to do with performing normal operations on networked
filesystems. How many real apps rely on being able to execute code
via
an smb include?
Quite a few since many "real apps" will happily install on an SMB
share in a linux or windows environment. While this is an uncommon
practice on linux I've seen this done many times in the Windows
environment. In linux I have seen this date frequently for backup
purposes (managed by PHP app) where php would create a backup and
write it to the storage machine via SMB. Quite a few big hosters now
offer access to SAN via SMB for backup purposes.
The exact same argument could me made for a localhost
http or ftp include which we also disallow. The fact that someone can
map a remote machine to a local drive actually means that they can
make
sure their app works because then they have pre-configured which hosts
are valid hosts for this use.
Not all users can mount the smb system due to permission restrictions
or simple lack of knowhow on how to do that. While latter can be
solved, solving the former is quite a bit trickier.
Ilia Alshanetsky
The exact same argument could me made for a localhost
http or ftp include which we also disallow.
For http allowing localhost access is dangerous simply because the
person could make the script request itself making a very nasty
request loop that will instantly result in a denial of service that
requires nothing short of a web server restart to resolve.
Ilia Alshanetsky
Ilia Alshanetsky wrote:
The exact same argument could me made for a localhost
http or ftp include which we also disallow.For http allowing localhost access is dangerous simply because the
person could make the script request itself making a very nasty request
loop that will instantly result in a denial of service that requires
nothing short of a web server restart to resolve.
I still think disallowing anything that in any way looks like it could
be a remote include, even if under the covers it isn't, is what we
should be doing here when allow_url_include is disabled. The chance of
false positives doesn't change anything.
-Rasmus
Ilia Alshanetsky wrote:
What's to say /drive/smb or letter:// is not an SMB device? Also why
break perfectly valid applications that perform operations on
networked
file systems?We are only talking about marking them as is_url which doesn't have
anything to do with performing normal operations on networked
filesystems. How many real apps rely on being able to execute code
via
an smb include? The exact same argument could me made for a localhost
http or ftp include which we also disallow. The fact that someone can
map a remote machine to a local drive actually means that they can
make
sure their app works because then they have pre-configured which hosts
are valid hosts for this use. If a bad guy can mount remote
filesystems
onto your server, then you have bigger problems.
Maybe I'm just being stupid (again) but it seems like all of this is
kinda pointless...
I mean, if you're dumb enough to include() source code from some
random computer you don't control/trust, what do you really expect as
the outcome?
I realize that a lot of idiots did:
include $path;
with register_globals on as part of their code, and allow_url_include
is trying to stem the tide of disasters that caused...
But, really, can somebody be both smart enough to get SMB to even
work, then manage to mount somebody else's untrusted drive or be dumb
enough to let somebody else mount their own SMB drive, and then
include() it i their PHP code? How likely is this scenario?
And how many Real Uses are going to be impacted by dis-allowing SMB
shares? Does anybody need this feature?
Somebody posted that large ISPs are using SMB shares -- Perhaps asking
them if this would kill them, or if they could manage to mount
everything as a named drive. They're probably the ones most at-risk
and with the best understanding of the Real World issues/risks.
It's entirely possible, yea, even likely, that I'm "missing" something
fundamental here, but it seems like you're trying to block something
that only somebody really smart could intentionally open up to "prove"
how insecure PHP is, rather than an actual Security Issue.
PS
I found it interesting that the CAPTCHA on the blog that started this
thread doesn't work...
And the comments box doesn't scroll properly when you type too much.
[Which I'm sure some here think I type too much anyway... ;-)]
PPS
Since I will most likely never be responsible for an SMB share as a
repository for source code in a production environment, I don't have a
personal stake in this one, as interesting as it as an academic
exercise in "Security". :-)
+0.00001
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
But, really, can somebody be both smart enough to get SMB to even
work, then manage to mount somebody else's untrusted drive or be dumb
enough to let somebody else mount their own SMB drive, and then
include() it i their PHP code? How likely is this scenario?
AFAIK, in order to use \IP\share\file you do not need to do anything
for the client machine on windows - it would work out of the box
provided target computer allows anonymous SMB and TCP/IP access to it is
available. You do not need to mount it or anything. It would take some
skill to set the SMB server, but not much more than setting http
server.
Setting it as a drive letter, however, requires some client effort, so I
think it's where the line should be drawn - letter OK, \IP not OK. It's
also something we can easily do :)
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Ilia Alshanetsky wrote:
What's to say /drive/smb or letter:// is not an SMB device? Also why
break perfectly valid applications that perform operations on networked
file systems?
Well, it's the same as asking why break valid apps that perform
operations on URL. Because of security policy - i.e., if we choose to
have security policy that disallows running code with non-local origin
influenced by user data - we must do it full nine yards, not "we won't
give it to you by http, but you are welcome to do it by smb". Now, if it
would be not allowed by default by Windows (AFAIK it is allowed) or
there's known way to restrict that from Windows (which I don't know of)
- then we may defer this task to the OS, but if there's none, then I
don't see how http here would differ from smb... If we say including
file from http source is not OK, then why would including file from smb
source ok?
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Ilia Alshanetsky wrote:
What's to say /drive/smb or letter:// is not an SMB device? Also
why break perfectly valid applications that perform operations on
networked file systems?Well, it's the same as asking why break valid apps that perform
operations on URL.
I guess it is a question of frequency, as a rule a valid use of
require/include on a URL is quite unusual. From my experience, I do
not believe the same could be said about smb.
Because of security policy - i.e., if we choose to have security
policy that disallows running code with non-local origin influenced
by user data - we must do it full nine yards, not "we won't give it
to you by http, but you are welcome to do it by smb".
This is a valid point, but at the same time we need to consider the
consequences marking of smb:// as url will have on PHP applications
and weather this is something to be done in a patch level release.
Exploitation wise all of the hacks I've seen for remote code
execution were based on http as that provides the best degree of
anonymity for a hacker, a freehosting page somewhere sending php code
via text file. Use of SMB requires a more tricky infrastructure in a
form of an open smb share, usually meaning an exploited win32 box
that accepts incoming smb connections.
Now, if it would be not allowed by default by Windows (AFAIK it is
allowed) or there's known way to restrict that from Windows (which
I don't know of) - then we may defer this task to the OS, but if
there's none, then I don't see how http here would differ from
smb... If we say including file from http source is not OK, then
why would including file from smb source ok?
A firewall rule can be used to block outgoing smb connections quite
easily on both linux and windows.
Ilia Alshanetsky
I guess it is a question of frequency, as a rule a valid use of
require/include on a URL is quite unusual. From my experience, I do not
believe the same could be said about smb.
How many apps really need to import includes from foreighn systems which
aren't mounted as drive letters? I don't think anybody does (or should)
build an applications like that.
This is a valid point, but at the same time we need to consider the
consequences marking of smb:// as url will have on PHP applications and
weather this is something to be done in a patch level release.
Sure, we need to consider that - I think that's exactly what we are
doing now :) My assessment would be people usually don't do that
purposefully, but you and everybody on the list are welcome to give
examples to the contrary of course.
Exploitation wise all of the hacks I've seen for remote code execution
were based on http as that provides the best degree of anonymity for a
SMB can be as anonymous as HTTP. The reason why HTTP is used more
because you can easily buy HTTP hosting solution and SMB hosting would
probably cost more, and because HTTP is much more known and easy to set
up right to the script kiddies of all kinds. But once people figure out
something can be hacked through SMB means, they would write a script to
do it and script kiddies would do it as easily as anything. Once writing
an exploit was are that few could master, now there are ready-made
rootkits for any vulerability out there for anybody to use.
Use of SMB requires a more tricky infrastructure in a form of an open
smb share, usually meaning an exploited win32 box that accepts incoming
smb connections.
"Pwned" windows boxes are not unheard of, to say the least. :) And any
unix can do smb as good as windows, thanks to samba team ;)
A firewall rule can be used to block outgoing smb connections quite
easily on both linux and windows.
Yes, sure - though standard config does not block that AFAIK and the
whole point of allow_url_include is to protect such configs as far as I
understand.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Well, it looks like the overall consensus is that we add this
restriction, so let's add in it. It seems I am the only one somewhat
against it...
I guess it is a question of frequency, as a rule a valid use of
require/include on a URL is quite unusual. From my experience, I
do not believe the same could be said about smb.How many apps really need to import includes from foreighn systems
which aren't mounted as drive letters? I don't think anybody does
(or should) build an applications like that.This is a valid point, but at the same time we need to consider
the consequences marking of smb:// as url will have on PHP
applications and weather this is something to be done in a patch
level release.Sure, we need to consider that - I think that's exactly what we are
doing now :) My assessment would be people usually don't do that
purposefully, but you and everybody on the list are welcome to give
examples to the contrary of course.Exploitation wise all of the hacks I've seen for remote code
execution were based on http as that provides the best degree of
anonymity for aSMB can be as anonymous as HTTP. The reason why HTTP is used more
because you can easily buy HTTP hosting solution and SMB hosting
would probably cost more, and because HTTP is much more known and
easy to set up right to the script kiddies of all kinds. But once
people figure out something can be hacked through SMB means, they
would write a script to do it and script kiddies would do it as
easily as anything. Once writing an exploit was are that few could
master, now there are ready-made rootkits for any vulerability out
there for anybody to use.Use of SMB requires a more tricky infrastructure in a form of an
open smb share, usually meaning an exploited win32 box that
accepts incoming smb connections."Pwned" windows boxes are not unheard of, to say the least. :) And
any unix can do smb as good as windows, thanks to samba team ;)A firewall rule can be used to block outgoing smb connections
quite easily on both linux and windows.Yes, sure - though standard config does not block that AFAIK and
the whole point of allow_url_include is to protect such configs as
far as I understand.--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/--
Ilia Alshanetsky
Hi,
At first I didn't think there would be an easy solution as it isn't
possible to distinguish between requests to a "local" SMB server and
an "outside" server. Both are network requests.
But on the other hand, requesting a file specific via network
protocols in PHP such as SMB or HTTP or FTP really shouldn't be any
different. One is asking PHP to perform the network operation to fetch
a foreign resource.
The key is that administrators would be able to map the needed SMB
servers as local devices (just as one would mount a NFS share or for
that sake make an FTP mount) thorugh the operating/file system.
In that case requesting e.g. Z:\file.txt though a device on a SMB
server share (or a NFS share or a FTP share or ...) would be perfectly
fine. In that case it would be the operating/file system that is
performing the network operation (based on central server
administration) and not some random PHP code (possibly based on user
input).
Of course, those rare cases where one would actually need to fetch
files through arbitrary external hosts through PHP one could just turn
on allow_url_include.
On Sun, 5 Nov 2006 08:13:18 -0800, in php.internals kingwez@gmail.com
("Wez Furlong") wrote:
I think it's a fair assumption that a random host specified in that
way be treated as suspicious and lumped in under the
disable-includes-by-default category.If someone discovers that it breaks their app, when they read the docs
for allow_url_include it should be made very clear what the
implications are and what should be done prior to turning it on.So i have no problem with disallowing includes for paths beginning
with a double backslash on windows, when allow_url_include is
disabled.--Wez.
I think it'd be wrong to consider networked file system as non-local.
Mostly because many times there are no ways to identify them reliable
and the fact this is a perfectly valid usage that if disallowed by
default would break a large number of applications.On Sat, 04 Nov 2006 12:40:01 -0800, in php.internals
rasmus@lerdorf.com (Rasmus Lerdorf) wrote:Yeah, we probably should. Had a chat with Wez about it too. Here is
the patch. I think this catches the cases we are interested in:http://lerdorf.com/php/is_url.diff
If someone could doublecheck it against those attacks it would be
helpful.Would requests to a smbserver, e.g.
\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It
seems like smbserver requests are regarded as part of the default
filesystem wrapper.--
- Peter Brodersen
--
Ilia Alshanetsky
--
--
- Peter Brodersen
I develop solely on and for our Windows network. I regularly use
includes on 2 different servers via \ rather than a mapped drive.
I can see that adding \ to the list of restrictions would be an issue for me.
But also, it is a trivial ini update to remove the problem. And it
DOES make PHP more secure.
So, +1 to add \ to the list of restrictions.
Not so sure it would be as easy for shared host ISPs on Windows to fix
this though.
Hi,
At first I didn't think there would be an easy solution as it isn't
possible to distinguish between requests to a "local" SMB server and
an "outside" server. Both are network requests.But on the other hand, requesting a file specific via network
protocols in PHP such as SMB or HTTP or FTP really shouldn't be any
different. One is asking PHP to perform the network operation to fetch
a foreign resource.The key is that administrators would be able to map the needed SMB
servers as local devices (just as one would mount a NFS share or for
that sake make an FTP mount) thorugh the operating/file system.In that case requesting e.g. Z:\file.txt though a device on a SMB
server share (or a NFS share or a FTP share or ...) would be perfectly
fine. In that case it would be the operating/file system that is
performing the network operation (based on central server
administration) and not some random PHP code (possibly based on user
input).Of course, those rare cases where one would actually need to fetch
files through arbitrary external hosts through PHP one could just turn
on allow_url_include.On Sun, 5 Nov 2006 08:13:18 -0800, in php.internals kingwez@gmail.com
("Wez Furlong") wrote:I think it's a fair assumption that a random host specified in that
way be treated as suspicious and lumped in under the
disable-includes-by-default category.If someone discovers that it breaks their app, when they read the docs
for allow_url_include it should be made very clear what the
implications are and what should be done prior to turning it on.So i have no problem with disallowing includes for paths beginning
with a double backslash on windows, when allow_url_include is
disabled.--Wez.
I think it'd be wrong to consider networked file system as non-local.
Mostly because many times there are no ways to identify them reliable
and the fact this is a perfectly valid usage that if disallowed by
default would break a large number of applications.On Sat, 04 Nov 2006 12:40:01 -0800, in php.internals
rasmus@lerdorf.com (Rasmus Lerdorf) wrote:Yeah, we probably should. Had a chat with Wez about it too. Here is
the patch. I think this catches the cases we are interested in:http://lerdorf.com/php/is_url.diff
If someone could doublecheck it against those attacks it would be
helpful.Would requests to a smbserver, e.g.
\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It
seems like smbserver requests are regarded as part of the default
filesystem wrapper.--
- Peter Brodersen
--
Ilia Alshanetsky
--
--
- Peter Brodersen
--
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
I develop solely on and for our Windows network. I regularly use
includes on 2 different servers via \ rather than a mapped drive.I can see that adding \ to the list of restrictions would be an issue
for me.But also, it is a trivial ini update to remove the problem. And it
DOES make PHP more secure.So, +1 to add \ to the list of restrictions.
Not so sure it would be as easy for shared host ISPs on Windows to fix
this though.
This seems to be more of a network setup issue, rather than a PHP issue.
If you haven't blocked access to remote SMB servers in your network, you
are asking for trouble. If you have a rogue SMB box or mount on your
network, PHP is the least of your problems.
You can pretty much guarantee that if people are including URLs, they are
either asking for trouble or looking for it.
Blocking network mounts seems to be too much of an edge case for it to be
included as a feature in allow_url_include, as it might have valid uses
while URLs does not.
You could add a allow_remote_include option, but that would require
another INI option, and those aren't so popular :)
My two cents
// Tom
Stefan Esser writes here:
http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.htmlthat allow_url_include (and allow_url_fopen) can be easily worked around -
i.e. extrenally-supplied code executed on server - by using php: and
data: URLs. I think if we want allow_url_include have any value than we
should fix it... What do you think?
I don't usually intervene in discussions nor rudenesses here, but this time
I felt I had to write this.. I'm pretty tired and reading such pathetic
posts is frustrating..
Well in first place I think Stefan should define in which side he is. He
pretends to be a PHP developer, but he doesn't act as one, as it posted a
message in his blog saying that a product that he supposedly helps to make
is insecure.. This is not really ethical, IMHO.
If he found some problem (security related or not), the first thing he would
have to do was to warn the PHP team (or fix it directly), not to release a
public advisory, nor an exploit, nor a slashdot/digg/... post, nor
whatever..
But yes, I agree with Ramus' patch.
Would requests to a smbserver, e.g.
\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It
seems like smbserver requests are regarded as part of the default
filesystem wrapper.
Well, this is a windows only problem. open_basedir will block it, but
probably it won't be blocked by anything else as it is handled as a local
file by the OS. However, we can/should also think in this problem.
Nuno
Nuno,
there is a simple answer to your email:
stick your anti Esser propaganda deep into some place noone is
interested in.
Before I posted about this, I brought this topic up MONTHS before PHP
5.2 was released. Even before this patch made it into PHP 5.2 from PHP 6
tree.
And now please die or just shut the fuck up. I am sick of morons like
you who believe they can attack me without knowing the facts.
Stefan Esser
Nuno,
there is a simple answer to your email:
stick your anti Esser propaganda deep into some place noone is
interested in.
I was already expecting this kind of answer from you, but you clearly don't
know me.
The previous e-mail wasn't a personal attack nor an attack to your business,
nor I was doing any type of propaganda against you.
I really appreciate your effort in researching new security problems in PHP
itself and in its usage. I personally also like to analyze the PHP code when
I have some free time as you do, which is a task that most developers
doesn't usually like.
Before I posted about this, I brought this topic up MONTHS before PHP
5.2 was released. Even before this patch made it into PHP 5.2 from PHP 6
tree.
I didn't know that, really. But in theory I'm also a PHP developer (although
not very active) and I didn't receive any information about that.
So, I don't know who knew that. But if the security team was aware of that,
I present my excuses to you.
And now please die or just shut the fuck up. I am sick of morons like
you who believe they can attack me without knowing the facts.
If people doesn't know the facts, just explain the things to them nicely. No
violence is needed, IMHO.
Nuno
Hi Nuno,
I was already expecting this kind of answer from you, but you clearly
don't know me.
The previous e-mail wasn't a personal attack nor an attack to your
business, nor I was doing any type of propaganda against you.
Calling my actions unethical and my posts pathetic is kinda a personal
attack in the real world.
I didn't know that, really. But in theory I'm also a PHP developer
(although not very active) and I didn't receive any information about
that.
So, I don't know who knew that. But if the security team was aware of
that, I present my excuses to you.
The fact that allow_url_fopen does not affect php://input was not only
brought up by me before but is actively used by skript kiddies for years.
And I really don't like to repeat myself 1000 times.
When I brought this up the response I got was: "Yeah whatever. Stopping
a few URLs is better than stopping none."If people doesn't know the facts, just explain the things to them
nicely. No violence is needed, IMHO.
Well PHP developers discuss on IRC how to kill me best by shooting me in
my back. I am just answering in the same tone.
Stefan