Re: PHP security flamewar (was: Apache codered looming???)
In a message dated: Thu, 07 Mar 2002 00:03:30 EST Benjamin Scott said: I note that Perl's CGI module has an identical feature (the ability to set language variables from an HTML form). Still does, AFAIK. I'm not trying to compare Perl to PHP here, just point out that tools that allow you to do stupid things are not limited to PHP. Ahm, why is this a stupid thing? How else do you get data into a CGI from a web page? Just because you're taking data in from the outside and setting a variable to the value entered in a form isn't, in and of itself, a stupid thing. It's what you do, or rather, don't do with that data after you have it that makes it dangerous. Once you take tainted data in, you must jump through hoops to de-taint it. Just blindly accepting the value from an HTML form and using it as is is stupid, but that's a programming practice that's stupid, not a language design issue. Please clarify if I'm misunderstanding what you're talking about. * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: (Fwd) Re: HTML Code
In a message dated: Thu, 07 Mar 2002 01:37:52 EST Dave M. said: Reson our system administrator told me he wouldn't use Linux, he does like Netscape! I'm assuming that should read doesn't like Netscape, right? And who can blame him, Netscape is archaic, slow, and bug-ridden! However, there are plenty of alternatives. Opera is available for Linux, as is Mozilla, Galeon, Konqueror, etc. Unfortunately, he can't get IE on Linux, and when you tell him that, he's likely to say that he won't use Linux because he can't use IE. So, here's what you do. Show him Opera on Windows. Get him using that and wait until he's really used to it. After a month or so, let him see *you* using Opera on Linux. But don't make it so it seems planned or contrived. It really would work best if he walked in on you using Opera and suddenly noticed that Hey, that's not Windows! My wife discovered Opera a month or two ago. Before that she was exclusively an IE user because, believe it or not, Netscape is worse on Windows than on Linux. Now she uses Opera almost exclusively. Once she's done with grad school, I'm going to move her over to Linux w/ KDE (3.0 should be out by then!). I doubt she'll ever go back after that :) Oh well, just my $.002 :) * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: PHP security flamewar (was: Apache codered looming???)
On Thu, 7 Mar 2002, at 7:54am, [EMAIL PROTECTED] wrote: I note that Perl's CGI module has an identical feature (the ability to set language variables from an HTML form). Please clarify if I'm misunderstanding what you're talking about. Using this feature, an HTML form variable called foo results in a language variable called $foo (in Perl, at least). So the attacker submits the form with extra variables that do things like change your path, shell, internal authentication variables, etc., etc. Basically, the attacker can modify your program's state at will. -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: PHP security flamewar (was: Apache codered looming???)
In a message dated: Thu, 07 Mar 2002 08:36:13 EST Benjamin Scott said: Using this feature, an HTML form variable called foo results in a language variable called $foo (in Perl, at least). So the attacker submits the form with extra variables that do things like change your path, shell, internal authentication variables, etc., etc. Basically, the attacker can modify your program's state at will. I don't think that's true. Yes, you can set variables like that, but you can also turn that off and state explicity what variables get set from the HTML form. Also, things like path, shell, and other environmental variables are all set using the global %ENV hash, which *should* be cleared out and set to known, safe, and accepted defaults. Perl also has taint-checking available which should always be used for stuff like this. While I agree that Perl has many of the features you're complaining about, it is also completely possible to use them in a safe and consistent manner without getting into trouble. Again, it comes down to safe programming practices. If you know what you're doing, you're fine, if you don't, then you shouldn't be trying to pass as someone who does. Cars are completely safe if used properly. There are a lot of people on the road who claim to be and attempt to pass for someone who knows what they're doing and don't. Because of them, the rest of us pay exhorbitant insurance rates :) -- Seeya, Paul * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Linux Rescue Boot CD
On Wed, 2002-03-06 at 23:36, Benjamin Scott wrote: On Wed, 6 Mar 2002, at 3:18pm, Brian Chabot wrote: What would you all reccommend for a Linux rescue CD? I tend to either use a Red Hat install CD in rescue mode (boot with rescue at the boot prompt), or the LinuxCare BBC (Bootable Business Card) CD. I concur with Ben: the BBC CD-ROM is the one I like, though it takes a little bit of getting used to (I guess it's Debian, and I'm not a Debian-head -- sorry, Paul!). Note, however, that the BBC distribution has branched from Linuxcare. Check it out at http://www.lnx-bbc.org/ . And it -is- small enough (and then some!) to fit on those spiffy small 150 MB CD-ROMs they have at CompUSA (or, indeed, the 50 MB business card CD-ROMs). -Ken * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: PHP security flamewar (was: Apache codered looming???)
On Thu, 7 Mar 2002, at 8:40am, [EMAIL PROTECTED] wrote: Using this feature, an HTML form variable called foo results in a language variable called $foo (in Perl, at least). So the attacker submits the form with extra variables that do things like change your path, shell, internal authentication variables, etc., etc. Basically, the attacker can modify your program's state at will. I don't think that's true. Yes, you can set variables like that, but you can also turn that off and state explicity what variables get set from the HTML form. Ummm... huh? That is what I said. It is a bad idea to use these features, but they are there, for many different platforms. Also, things like path, shell, and other environmental variables are all set using the global %ENV hash, which *should* be cleared out and set to known, safe, and accepted defaults. Which won't matter much if anyone on the web can reset them for you. :-) While I agree that Perl has many of the features you're complaining about, it is also completely possible to use them in a safe and consistent manner without getting into trouble. Uhhh... yah. That was my point. I agree with everything you said in this message, except for the I don't think that's true part, since I was saying the same thing you are. :-) -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: PHP security flamewar (was: Apache codered looming???)
In a message dated: Thu, 07 Mar 2002 10:33:41 EST
Benjamin Scott said:
Also, things like path, shell, and other environmental variables are all
set using the global %ENV hash, which *should* be cleared out and set to
known, safe, and accepted defaults.
Which won't matter much if anyone on the web can reset them for you. :-)
I don't believe these can be set from a web form. Usually, when
doing CGI with perl, one uses CGI.pm or something similar, and sets
up the variables allowed to be modified like:
my ($foo) = $q-param(foo);
And that's the only way $foo gets created, you have to at least
explicitly assign to it. I'm not sure how some variable can
automagically come into existence through form and have malicious
content assigned to it. The programmer must state which fields get
assigned to which variables.
It is possible to enter things into a form like:
Name: $ENV{'PATH'}='/etc'
or something like that, but unless you then did an eval on that form
variable, nothing's ever going to happen with it. And if you're
eval'ing external code like that, you *really* better know what
you're doing. (I've never, ever used 'eval'. Mostly because I don't
understand how to and I'm petrified of the ramifications if I tried :)
I agree with everything you said in this message, except for the I don't
think that's true part, since I was saying the same thing you are. :-)
Well all right then! As long as that's the case, have it your way ;)
--
Seeya,
Paul
*
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*
Re: PHP security flamewar (was: Apache codered looming???)
On Thu, 7 Mar 2002, at 10:54am, [EMAIL PROTECTED] wrote: I don't believe these can be set from a web form. From the Perl CGI(3) manual page: This creates a series of variables in the 'R' namespace. For example, $R::foo, @R:foo. For keyword lists, a variable @R::keywords will appear. If no namespace is given, this method will assume 'Q'. WARNING: don't import anything into 'main'; this is a major security risk They do, at least, warn you about it. :-) -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: PHP security flamewar (was: Apache codered looming???)
In a message dated: 07 Mar 2002 11:03:59 EST Mark Komarinski said: Nope. You can have variables pre-set when the script starts from both perl and PHP. I have to use it since I have forms that send a variable number of variables to the controlling script. It's a lot easier to just pull the variables out of thin air than set up all the code to figure out how many variables have been passed, create them and populate them. Mark, can you provide an example of this in perl? I don't do a lot of web/CGI programming, so I'm not clear on how/when you would want to use this. Thanks, -- Seeya, Paul * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: PHP security flamewar (was: Apache codered looming???)
In a message dated: Thu, 07 Mar 2002 11:11:59 EST Benjamin Scott said: From the Perl CGI(3) manual page: This creates a series of variables in the 'R' namespace. For example, $R::foo, @R:foo. For keyword lists, a variable @R::keywords will appear. If no namespace is given, this method will assume 'Q'. WARNING: don't import anything into 'main'; this is a major security risk They do, at least, warn you about it. :-) I'm confused as to how this would work. The man page is talking about the invocation of a specific method, i.e. the 'import_names()' method. It sounded like things just happened, when in fact, you must invoke this method intentionally. Which, if you do, is fine, provided you also take the time to de-taint everything before you do something potentially dangerous with that data. -- Seeya, Paul * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: PHP security flamewar (was: Apache codered looming???)
The example in PHP that I have is a recipe server that has a variable number of ingredients. You can add more than the default (5) and then pass them back to the server and have it added. This made some real fun on both ends, with me having to create variables like ingred0 through ingred10. It made for fun. I do remember doing it with CGI.pm, but it was more for convenience than any other reason. -Mark On Thu, 2002-03-07 at 11:11, [EMAIL PROTECTED] wrote: In a message dated: 07 Mar 2002 11:03:59 EST Mark Komarinski said: Nope. You can have variables pre-set when the script starts from both perl and PHP. I have to use it since I have forms that send a variable number of variables to the controlling script. It's a lot easier to just pull the variables out of thin air than set up all the code to figure out how many variables have been passed, create them and populate them. Mark, can you provide an example of this in perl? I don't do a lot of web/CGI programming, so I'm not clear on how/when you would want to use this. Thanks, -- Seeya, Paul * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: PHP security flamewar (was: Apache codered looming???)
OK, does anyone else see this? Paul and Ben are saying exactly the same thing: It's a matter of bad programming, not a bad programming language. Now, the truly amazing thing is that Paul and Ben actually agree on something. The slightly less astounding fact is that they are *STILL* arguing, despite the fact that they agree... Anywho PHP, like Perl, like C, like any other language will have security holes as long as people write sloppy code. It is a fact of nature. Yes, PHP has some problems. However, those problems aren't an issue until someone goes and does something stupid like write bad code that leaves the hole vulnerable. The same is true for Perl (see http://www.coconut-palm-software.com/~perlintro/cgi-security.html). A great example is Matt's Script Archive. Great programs. *BD* programming. There are all sorts of holes in most of the Perl scripts found there. This is why there are 200 Perl-related vulnerability checks in Nessus. There is no such thing as a secure language. The language of and by itself does nothing. It is not secure or insecure. It is the person writing the code. Thus buffer overflows, stack-smashing, elevated rights, etc. C-Ya, Kenny Quoting [EMAIL PROTECTED]: In a message dated: Thu, 07 Mar 2002 00:03:30 EST Benjamin Scott said: I note that Perl's CGI module has an identical feature (the ability to set language variables from an HTML form). Still does, AFAIK. I'm not trying to compare Perl to PHP here, just point out that tools that allow you to do stupid things are not limited to PHP. Ahm, why is this a stupid thing? How else do you get data into a CGI from a web page? Just because you're taking data in from the outside and setting a variable to the value entered in a form isn't, in and of itself, a stupid thing. It's what you do, or rather, don't do with that data after you have it that makes it dangerous. Once you take tainted data in, you must jump through hoops to de-taint it. Just blindly accepting the value from an HTML form and using it as is is stupid, but that's a programming practice that's stupid, not a language design issue. Please clarify if I'm misunderstanding what you're talking about. * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * - There's nothing you shouldn't speak of if you've got something to say, and there's no one to be scared of, just get them out of your way. -- The Alarm * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
