You don't... for that would be a profoundly stupid feature, defeating
the point of safe mode.
And I suspect [EMAIL PROTECTED] would be a better place for this
question
--- Original Message ---
From:Shashwat Nagpal [EMAIL PROTECTED]
To: [EMAIL
Thanks Mike, but I m facing a problem in uploading files through PHP
and i don't have xs to php.ini so i was wondering if something can help b4 i
ask server ppl.
Cheers!
Shashwat
Mike Hall [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
You don't... for that
On Fri, May 17, 2002 at 03:46:42AM +0300, Zeev Suraski wrote:
In a perfect world, ISPs would have used chroot'd environments always,
running either CGI's
We do. On earth.
Kristian
--
Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel
Tel: +49 431 386 435 00, Fax: +49 431 386 435
At 04:38 PM 5/13/2002, Jason T. Greene wrote:
I do, for two simple reasons:
- Misperception about what it's supposed to do - it does NOT secure your
environment, people expect it to. That's a 'marketing' issue, but we
should realize that these kinds of issues are at least as important
On Mon, 2002-05-13 at 03:13, Zeev Suraski wrote:
Jason,
He has a point in the sense that it's trivially easy to starve a PHP based
web server from within, safe mode enabled or not. What you describe as the
automated way in which the web server will overcome this attack is not
realistic
On Mon, 2002-05-13 at 04:11, Zeev Suraski wrote:
At 11:42 13/05/2002, veins wrote:
He has a point in the sense that it's trivially easy to starve a PHP based
web server from within, safe mode enabled or not. What you describe as
the
automated way in which the web server will overcome
I very much agree : )
-Jason
On Mon, 2002-05-13 at 03:42, veins wrote:
He has a point in the sense that it's trivially easy to starve a PHP based
web server from within, safe mode enabled or not. What you describe as
the
automated way in which the web server will overcome this attack is
On Mon, 2002-05-13 at 09:54, Ilia A. wrote:
Now you are really starting to stretch it. I am sure the ratio of
customers that have db backends are much smaller than general webhosting
customers
PHP is very commonly used with a database (MySQL). I'd venture to say that 70%
of people who
On Mon, May 13, 2002 at 08:38:13AM -0500, Jason T. Greene wrote :
I get the feeling that you are mainly arguing the marketing perspective.
: )
I completely agree that safe mode is badly named. However, I still find
uid checking, and restricting process spawning very useful
Someone
Rasmus Lerdorf wrote:
PHP being a web server scripting language is a unique case, for example
consider that once apache 2.0 becomes stable, safe_mode will become
obsolete, on the other hand the situation described here will become
quite deadly if some sort of threaded mode is used. So FD
Jason,
He has a point in the sense that it's trivially easy to starve a PHP based
web server from within, safe mode enabled or not. What you describe as the
automated way in which the web server will overcome this attack is not
realistic - pretty quickly, the web server would hit the maximum
At 11:42 13/05/2002, veins wrote:
He has a point in the sense that it's trivially easy to starve a PHP based
web server from within, safe mode enabled or not. What you describe as
the
automated way in which the web server will overcome this attack is not
realistic - pretty quickly, the
On 12 May 2002 23:42:21 +0200
Stig S. Bakken [EMAIL PROTECTED] wrote:
Well, as long as there is exec(2), there is a way. How many users do
Lycos Europe provide sandboxed PHP for?
heya,
We provide php for roughly 5 000 000 users, and it's growing everyday by 5000
approximately.
Chrooted
Not for every user, but you can at least chroot people away to the same
dir where they can not do local server hacks. I was _not_ suggesting
that you set up five million chroot environments. :-)
But, you said yourself that you bailed out on safe mode and went for a
cgi setup. So that means
IMHO this is the path we should pursue for PHP 5.0.
- Stig
On Mon, 2002-05-13 at 00:53, Shane Caraveo wrote:
FastCGI can provide the security needed in shared environments, without
loosing all the performance. I don't beleive it is fast as direct
server plugins, but there are other
I don't like safe mode and I don't use it on any of my systems and manage to
convince most of my customers not to use it either. However, I happen to
write distributable software written in PHP and had on more then 1 occassion
came across systems with safe_mode enabled. While writing the code
On May 13, 2002 04:42 am, veins wrote:
He has a point in the sense that it's trivially easy to starve a PHP
based web server from within, safe mode enabled or not. What you
describe as
the
automated way in which the web server will overcome this attack is not
realistic - pretty
Now you are really starting to stretch it. I am sure the ratio of
customers that have db backends are much smaller than general webhosting
customers
PHP is very commonly used with a database (MySQL). I'd venture to say that 70%
of people who actively use PHP use it with MySQL or another
Rasmus Lerdorf wrote:
Heh, I am certain that most ISPs admins are not subscribed to the
development list of every software they are running, monitoring such
lists would be near impossible due to large cumulative volume of email. I
am sure some IPSs will do exactly what you suggest and
PHP being a web server scripting language is a unique case, for example
consider that once apache 2.0 becomes stable, safe_mode will become
obsolete, on the other hand the situation described here will become quite
deadly if some sort of threaded mode is used. So FD limit would because
quite
Jason Greene wrote:
while(1) fopen(rand(), w);
After a few seconds depending on system speed system will run out of file
pointers. I am sure you can see how that would be BAD.
You are _extremely_ incorrect. The previously mentioned code would open
1 file descriptor repeatedly until
On May 11, 2002 06:56 pm, Chand wrote:
The solution we've chosen is to have a cgi php binary instead of a
module for security stuff. The main reason to do so was to have the
user-created file have the user's uid. We had to suid the php binary and
setuid() the process to the script's uid, of
I'm +1 on removing safe mode in PHP 5, and encourage the use of
system-level sandboxes/prisons instead.
- Stig
On Sat, 2002-05-11 at 17:39, Ilia A. wrote:
In the process of writing an installer in PHP for one of my projects I've come
in contact with a number of servers running PHP with
But for really large shared hosts, I don't think that is feasible. How
are you going set up 100,000 prisons on a server?
I'm +1 on removing safe mode in PHP 5, and encourage the use of
system-level sandboxes/prisons instead.
- Stig
On Sat, 2002-05-11 at 17:39, Ilia A. wrote:
In the
Well, as long as there is exec(2), there is a way. How many users do
Lycos Europe provide sandboxed PHP for?
- Stig
On Sun, 2002-05-12 at 23:37, Rasmus Lerdorf wrote:
But for really large shared hosts, I don't think that is feasible. How
are you going set up 100,000 prisons on a server?
Ok, but dropping to CGI is kind of crappy. Especially on a really busy
server.
On 12 May 2002, Stig S. Bakken wrote:
Well, as long as there is exec(2), there is a way. How many users do
Lycos Europe provide sandboxed PHP for?
- Stig
On Sun, 2002-05-12 at 23:37, Rasmus Lerdorf wrote:
Instead of just giving up on the problem, perhaps we should go into full
attack mode. I see a couple of choices (and there are probably others):
1. Review and push open_basedir as the PHP-based jail mechanism
2. Pitch in and get Apache 2's perchild mpm up to snuff. There are
all sorts of
It may not be the fastest solution, but certainly a secure one. It is up to
each admin to decide whether they want speed or security, I am sure the
security minded ISPs probably would prefer a small performance loss over
security integrity of their customer's data.
Ilia
On May 12, 2002
On Sun, May 12, 2002 at 02:52:24PM -0700, Rasmus Lerdorf wrote:
...
2. Pitch in and get Apache 2's perchild mpm up to snuff. There are
all sorts of other issues associated with this option though, like
needing to make sure all the stuff we link against is threadsafe.
Actually this
FastCGI can provide the security needed in shared environments, without
loosing all the performance. I don't beleive it is fast as direct
server plugins, but there are other benefits...such as running PHP
single threaded to avoid thread issues. It would be nice to see it
become a standard
2. Pitch in and get Apache 2's perchild mpm up to snuff. There are
all sorts of other issues associated with this option though, like
needing to make sure all the stuff we link against is threadsafe.
Actually this isn't as bad as it sounds. I've been doing some of the
work
while(1) fopen(rand(), w);
After a few seconds depending on system speed system will run out of file
pointers. I am sure you can see how that would be BAD.
You are _extremely_ incorrect. The previously mentioned code would open
1 file descriptor repeatedly until the script hit max
However, quite frankly, this is a lame attack, because all it will do is
consume file descriptors for only the CHILD process the script is
running in. The script will then hit the fd limit of the child process
(most systems around 255 is the default) This will not hurt the process,
because
On Sun, 2002-05-12 at 22:46, Ilia A. wrote:
However, quite frankly, this is a lame attack, because all it will do is
consume file descriptors for only the CHILD process the script is
running in. The script will then hit the fd limit of the child process
(most systems around 255 is the
Really, what is that line?
sleep(1000);
If you insist on being creative you can use file locking or sockets to get the
process in to un-interuptible sleep.
I would take a bet that it probably has
nothing to do with safe mode, and would work regardless of it being in
the language..
I
On Sun, 2002-05-12 at 23:38, Ilia A. wrote:
Really, what is that line?
sleep(1000);
If you insist on being creative you can use file locking or sockets to get the
process in to un-interuptible sleep.
I would take a bet that it probably has
nothing to do with safe mode, and
disable_functions = sleep
Ah but you forgot usleep, and flock() and socket_set_limit etc...
Soon enough you'll disable every function.
And when you do, I'll still be able to deadlock a PHP process by making it
excute a query on a locked SQL table, thus end up waiting forever for the
lock to
On Mon, 2002-05-13 at 00:41, Ilia A. wrote:
disable_functions = sleep
Ah but you forgot usleep, and flock() and socket_set_limit etc...
Soon enough you'll disable every function.
Not likely, and I wouldn't disable every single function. You complained
about the ability, I provided you with
If the safe_mode like functionality remains it should simply block all file
system and shell execution code since with it most of that code becomes
useless anyway.
It already does this. You can only execute things in the
safe_mode_exec_dir.
-Rasmus
--
PHP Development Mailing List
There are numerous ways to bypass it, rely on file system utils if they are in
the path,
Won't work.
make the script copy itself and then write stuff as webserver,
You always write stuff as web server
install a small script into cgi-bin directory that will do the same thing
That's not
On May 11, 2002 11:35 am, you wrote:
There are numerous ways to bypass it, rely on file system utils if they
are in the path,
Won't work.
make the script copy itself and then write stuff as webserver,
You always write stuff as web server
What is the point of limiting the script's
What is the point of limiting the script's write access if it can just bypass
that by making a copy of itself? This merely adds an annoyance step for the
programmer.
If user joe makes a copy of his script so it now is owned by nobody, it
still doesn't let him read user bob's scripts.
At 20:17 11/05/2002, Rasmus Lerdorf wrote:
Ideally every ISP would use it and each virtual host would have such a
directory. In reality I've set to see a SINGLE ISP that has used that
option.
In fact I didn't know about it myself until you told me about on IRC.
Well, it is well
Zeev Suraski wrote:
At 20:17 11/05/2002, Rasmus Lerdorf wrote:
Ideally every ISP would use it and each virtual host would have such a
directory. In reality I've set to see a SINGLE ISP that has used
that option.
In fact I didn't know about it myself until you told me about on IRC.
That's not really a PHP issue. Many ISP's turn off cgi-bin access so
in those cases that won't work.
Cerainly some ISPs do that, but most do offer cgi-bin directories in
addition to PHP, because many of their customers rely on perl/c etc..
scripts that can be run via cgi-bin.
Yes, but safe_mode guards against one user getting at another's user's
data. So again, I fail to see your point here.
No offence but this bullshit.
On a system with safe_mode
?php
show_source(/etc/passwd);
?
Works!! What data did you protect?!
None in this case, but that has
None in this case, but that has nothing to do with the problem. That is
obviously a bug. Did you submit it?
Bug Report #17155 :)
The fact is that the problem cannot be
solved purely by UNIX-level permissions. Things like safe-mode or
open_basedir are needed.
And the ISP that is on the
Heh, I am certain that most ISPs admins are not subscribed to the development
list of every software they are running, monitoring such lists would be near
impossible due to large cumulative volume of email. I am sure some IPSs will
do exactly what you suggest and disable the function, but
On Sat, 2002-05-11 at 19:27, Zeev Suraski wrote:
At 20:17 11/05/2002, Rasmus Lerdorf wrote:
Ideally every ISP would use it and each virtual host would have such a
directory. In reality I've set to see a SINGLE ISP that has used that
option.
In fact I didn't know about it myself until
On Mon, 2 Jul 2001, Jan Lehnardt wrote:
Hi,
has this been recognized already? a quick look on the archives said no.
Yes, this is valid. I will fix this tonight. (The first problem)
Derick
snip
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
List-Id:
50 matches
Mail list logo
