disagree with a few things in perlsec

[el_roachmeister]

I disagree with a few things in perlsec relating to "Protecting your
program", namely these two paragraphs:

First of all, however, you can't take away read permission, because the
source code has to be readable in order to be compiled and interpreted.
(That doesn't mean that a CGI script's source is readable by people on
the web, though.) So you have to leave the permissions at the socially
friendly 0755 level. This lets people on your local system only see
your source.

Some people mistakenly regard this as a security problem. If your
program does insecure things, and relies on people not knowing how to
exploit those insecurities, it is not secure. It is often possible for
someone to determine the insecure things and exploit them without
viewing the source. Security through obscurity, the name for hiding
your bugs instead of fixing them, is little security indeed.
=======================================

If you are concerned about security you why are you going to let people
on your local system see your source? The default should be 700. You
would only need 755 if you have a definite need to do so.

Security is not a black and white issue. No script on this planet is
100% secure. It is all about reducing your probablity of being hacked.
Anything you do to make it more difficult for a script to be hacked
will increase the "security" of the script. Even if you write the
"perfectly secure" script, there are other ways into your program
beside your script. A hacker could just decide to break into your web
hosting account directly.

Security by obscurity is very helpful in reducing your risks. The
perlsec makes it sounds like it has no effect on protecting it. I
suggest perslec either eliminate any comments about security by
obscurity since that really has nothing to do with perl anyways. Or
they should be more realistic about what it really means.

The convenience store in the bad neighborhood will always get robbed
day in and day out, while the billions of dollars sitting in bank
accounts that nobody knows exists will remain untouched.

 

[A. Sinan Unur]

(e-mail address removed) wrote in @g14g2000cwa.googlegroups.com:

The convenience store in the bad neighborhood will always get robbed
day in and day out, while the billions of dollars sitting in bank
accounts that nobody knows exists will remain untouched.

This is as bad an analogy as I have ever heard. The reason bank accounts is
not being robbed is not because nobody knows where the bank is or that the
bank has accounts, but because of security mechanisms that assume people
know the location of the bank and the money.

But, then, your posting history does tell us something:

http://tinyurl.com/5nzcp

Sinan

 

[xhoster]

I disagree with a few things in perlsec relating to "Protecting your
program", namely these two paragraphs:

First of all, however, you can't take away read permission, because the
source code has to be readable in order to be compiled and interpreted.
(That doesn't mean that a CGI script's source is readable by people on
the web, though.) So you have to leave the permissions at the socially
friendly 0755 level. This lets people on your local system only see
your source.

Some people mistakenly regard this as a security problem. If your
program does insecure things, and relies on people not knowing how to
exploit those insecurities, it is not secure. It is often possible for
someone to determine the insecure things and exploit them without
viewing the source. Security through obscurity, the name for hiding
your bugs instead of fixing them, is little security indeed.
=======================================

If you are concerned about security you why are you going to let people
on your local system see your source? The default should be 700. You
would only need 755 if you have a definite need to do so.

The unwritten assumption made by perlsec is that you need other people
to be able to run your code.

Xho

 

[el_roachmeister]

(e-mail address removed) wrote in @g14g2000cwa.googlegroups.com:


This is as bad an analogy as I have ever heard. The reason bank accounts is
not being robbed is not because nobody knows where the bank is or that the
bank has accounts, but because of security mechanisms that assume people
know the location of the bank and the money.

I do not have hard facts to prove the analogy true so consider this
case. A wealthy person hides a treasure on an island. The probability
of it being found is proportional to the number of people that know
about it. Therefore the security measures to secure the treasure are
proportional to the number of people who know it exists. This the
principle I am trying to get accross, which perhaps my analogy did not
do a good job illustrating.

If I understand your point correctly you say the probability is the
same regardless of the number of "pirates" who know your treasure
exists. According to you the probability of it being found is only
based on the type of lock the wealthy person put on the treasure when
they buried it. Is that correct?

Relating this to perslec, someone may code the most secure script and
think their script is great because it has all the best built-in
security measures. One needs to use common sense to minimize the risk
of breaking into your script from multiple entry points. That's exactly
how hackers operate. They know great programmers write great scripts,
but that is their weakness, since they only focus on the script and not
the enviroment it is placed in.

But, then, your posting history does tell us something:

http://tinyurl.com/5nzcp

Is referencing this really neccessarry?

 

[Chris Mattern]

I do not have hard facts to prove the analogy true so consider this
case. A wealthy person hides a treasure on an island. The probability
of it being found is proportional to the number of people that know
about it. Therefore the security measures to secure the treasure are
proportional to the number of people who know it exists. This the
principle I am trying to get accross, which perhaps my analogy did not
do a good job illustrating.

And how many wealthy people do you know who keep their valuables in
secret locations on deserted islands, as opposed to those who
keep them in a safe deposit box in a bank, where *everyone* knows
valuables are kept?

If I understand your point correctly you say the probability is the
same regardless of the number of "pirates" who know your treasure
exists. According to you the probability of it being found is only
based on the type of lock the wealthy person put on the treasure when
they buried it. Is that correct?

No, his point is that it is very difficult to regulate how many
"pirates" know about your treasure, and that it is very difficult
to keep "pirates" from finding out about your treasure. Therefore
security measures that depend on nobody knowing where you stashed
the loot should be, at best, secondary measures to the *real* security.

Relating this to perslec, someone may code the most secure script and
think their script is great because it has all the best built-in
security measures. One needs to use common sense to minimize the risk
of breaking into your script from multiple entry points. That's exactly
how hackers operate. They know great programmers write great scripts,
but that is their weakness, since they only focus on the script and not
the enviroment it is placed in.

But what you're proposing is stashing the script away where it can't
be run. It's not very useful that way. If it's a script for use
on the system, it needs to be accessible to the people who use it
(You're the *only* person who uses it? It's not a very useful
script, then.) If it's a CGI script, it can't be runnable only
by your userid, because the webserver won't run it under your
userid--or if the webserver *is* running CGI scripts under your
userid, then you have bigger security issues to worry about.
And what have you gained? Unless it's a set-id script, the
other user can't do anything with the script that he couldn't
do from the command line. It just doesn't make much sense
95% of the time.

Is referencing this really neccessarry?

Probably not; the link is dead, so we can't find out what the Perl
advice Sinan thought was amusing was.

--
Christopher Mattern

"Which one you figure tracked us?"
"The ugly one, sir."
"...Could you be more specific?"

 

[Tad McClellan]

I disagree with a few things in perlsec relating to "Protecting your
program", namely these two paragraphs:

First of all, however, you can't take away read permission, because the
source code has to be readable in order to be compiled and interpreted.
(That doesn't mean that a CGI script's source is readable by people on
the web, though.) So you have to leave the permissions at the socially
friendly 0755 level. This lets people on your local system only see
your source.

Some people mistakenly regard this as a security problem. If your
program does insecure things, and relies on people not knowing how to
exploit those insecurities, it is not secure. It is often possible for
someone to determine the insecure things and exploit them without
viewing the source. Security through obscurity, the name for hiding
your bugs instead of fixing them, is little security indeed.
=======================================

If you are concerned about security you why are you going to let people
on your local system see your source?

Because if it is properly secured, then it won't matter if they see it.

Security is not a black and white issue. No script on this planet is
100% secure. It is all about reducing your probablity of being hacked.

Security by obscurity is very helpful in reducing your risks. The
perlsec makes it sounds like it has no effect on protecting it.

Because it is not "protected" by obscurity.

Obscurity only reduces the odds, it is still not "protected" it
is merely "hidden" (which might be Good Enough in some situations).

If you had said "reducing the risks" instead of "protecting" you
would have been on safer ground.

"protected" has a much strong meaning than "hidden" does.

I
suggest perslec either eliminate any comments about security by
obscurity since that really has nothing to do with perl anyways. Or
they should be more realistic about what it really means.

Got a patch for review?

Don't have one, I didnt think so.

 

[Tad McClellan]

Probably not; the link is dead, so we can't find out what the Perl
advice Sinan thought was amusing was.

Message-ID: <[email protected]>

 

[Tad McClellan]

Is referencing this really neccessarry?

You make your reputation, and then you live with the reputation you've made.

 

[el_roachmeister]

Because it is not "protected" by obscurity.

Obscurity only reduces the odds, it is still not "protected" it
is merely "hidden" (which might be Good Enough in some situations).

Dictionary
pro·tect (prə-tĕkt') pronunciation
tr.v., -tect·ed, -tect·ing, -tects.

1. To keep from being damaged, attacked, stolen, or injured; guard

Obscurity accomplishes this, therefore obscurity protects.

 

[el_roachmeister]

The more obscure you make your script, the fewer the number of pirates
who can find it. The fewer the number of pirates means the less chance
of one of them cracking it. I really don't see what is wrong in this
logic?

Whether obscurity is the primary or secondary way to secure your code
entirely depends on the situation. In majority of cases it will not be
the best way to secure it, but any script that is secure is only one
way is very not secure at all. This is where I feel perslec needs to
either eliminate the reference to obscurity or give it the proper
credit it is due in the greater scheme of things.

 

[Tad McClellan]

Dictionary
pro·tect (pr?-t?kt') pronunciation
tr.v., -tect·ed, -tect·ing, -tects.

1. To keep from being damaged, attacked, stolen, or injured; guard

Obscurity accomplishes this,

No it doesn't. That is the point being made in the docs.

Obscurity does not "keep from being damaged" it only reduces the odds
of it being damaged.

Having 10 people who can break in instead of 1000 people who
can break in is not "keeping it from damage".

Thanks for providing the definition that supports my position.

therefore obscurity protects.

Uh huh.

 

[GreenLeaf]

A wealthy person hides a treasure on an island.

How much wealthy is irrelevant. Where do *you* prefer to keep *your*
money? Bank or Island? )

And why?

 

[GreenLeaf]

Obscurity accomplishes this, therefore obscurity protects.

It does not "accomplish" anything. It reduces the *chance* of a security
breach. Any security that *relies* on chance is almost as good as no
security.

An old saying I vaguely remember: "First you must tie your camels and
*then* pray the gods" (that they don't stray away).

 

[el_roachmeister]

How much wealthy is irrelevant. Where do *you* prefer to keep *your*
money? Bank or Island? )

And why?

I would "prefer" to keep it in a bank located on an island ;-)

 

[el_roachmeister]

Obscurity does not "keep from being damaged" it only reduces the odds

of it being damaged.

For that matter nothing can "absolutely" keep anything from being
damaged. Life is all about probabilities and risk. No input guarantees
a certain output, whether it's perl code or anything else. So obscurity
is not protection and neither is "correct" perl code.

Having 10 people who can break in instead of 1000 people who
can break in is not "keeping it from damage".

Again using your logic, nothing can keep it from being damaged. Or can
you name something?

 

[Chris Mattern]

The more obscure you make your script, the fewer the number of pirates
who can find it. The fewer the number of pirates means the less chance
of one of them cracking it. I really don't see what is wrong in this
logic?

What is wrong with this logic is you are proposing obscuring your script
from "pirates" by making it unusable. This may make it more secure, but
does not seem really practical.

Whether obscurity is the primary or secondary way to secure your code
entirely depends on the situation. In majority of cases it will not be
the best way to secure it, but any script that is secure is only one
way is very not secure at all. This is where I feel perslec needs to
either eliminate the reference to obscurity or give it the proper
credit it is due in the greater scheme of things.

--
Christopher Mattern

"Which one you figure tracked us?"
"The ugly one, sir."
"...Could you be more specific?"

 

[Arndt Jonasson]

Message-ID: <[email protected]>

I think he meant that the link referenced in that posting is dead. It
is for me, anyway:

 

[A. Sinan Unur]

I think he meant that the link referenced in that posting is dead. It
is for me, anyway:

Well, the relevant part was *his* post. Quoting the OP in that thread:

<quotation> ... Yeah, it may not be 100% accurate, but perl is about
getting the job done, not about splitting hairs.</quotation>

which explains his attitude towards security very well.

Incidentally, the page referenced above contained grossly incorrect
information and has been taken down due to the diligence of, and
pressure applied by, other regulars in this group.

Sinan.

 

[GreenLeaf]

But the bank analogue is flawed because nowadays, one of the features
of a bank is that the banks takes the responsibility.

It's not entirely flawed in this view. But it works _against_ what OP
wanted to show. ) Old fashioned banks are 'low-security' systems, and
current banks are 'high security' systems. When you are satisfied about
the level of security the system provides by itself, then you think of
having convenience instead of sacrificing it for some additional
'chance' security.

IMHO, the OP's argument was fundamentally correct - to combat it, you
need the argument of practical convenience/usability, hence was my
question. Next thing is highly related to the OP's argument:

In _my_ case, I won't only keep my money in bank, but would even make
some of its properties 'readable' to others. For instance, I give out my
bank account number to people whom I never trust, so they can transfer
money online. They don't have to write cheques, I don't have to cash
them - convenient for everyone. This is possible because I'm happy about
the security of the bank and don't have to resort to "nobody knows where
my money is" strategies for a "better" sense of security. And it
increases the usability of my bank account compared to the "treasure
island" strategy ).

This is analogous to some coding/implementation scenarios.