|
Re: How to answer "Perl is not secure" objections?
by perrin (Chancellor) on Sep 06, 2007 at 18:52 UTC
|
Is he a Java guy? If so, he's probably thinking of how Java can prevent programs from accessing certain things (e.g. the filesystem). However, since any non-trivial Java program needs to access the filesystem, this type of permission will be granted immediately. It's more relevant for things like applets than it is for programs you would write in-house.
In terms of things to read, here are three good ones:
The most important point to make, IMO, is that security is a feature of programmers and their process, not of languages. There is no reason to think that a .NET or Java program that accessed a database and some files is more secure than a Perl program that does the same.
| [reply] |
|
|
Is he a Java guy?
No, he's upper management. We're beyond the pale of tech-savvy at this point. The guy believes this because someone he trusts (probably a vendor) told him so. What I'm looking for is essentially literature that talks about how secure Perl is, or speaks to other big-name orgs using Perl for "high-risk" data like financial transactions. Something digestible for the upper-manglement set.
<–radiant.matrix–>
Ramblings and references
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet
| [reply] |
|
|
| [reply] |
|
|
Well, Amazon.com and TicketMaster.com run millions of dollars of business through their websites, which are written in perl. That seems like a pretty solid case to me.
| [reply] |
|
|
As was told during the latest YAPC::EU job fair, VERISIGN uses Perl!If I remember well, they have about a million lines of Perl code in their applications and they are still actively seeking Perl programmers (see Perl Jobs). If Perl was inherently insecure, should a company like Verisign use it?
CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James
| [reply] |
Re: How to answer "Perl is not secure" objections?
by mr_mischief (Monsignor) on Sep 06, 2007 at 19:50 UTC
|
Perl, as a language, is much more secure than C or any other language that can have buffer overruns. http://www.computeruser.com/articles/2202,5,36,1,0201,03.html is a magazine article on buffer overruns and mentions Perl and Java as technologies to use to avoid the whole class of issues.
CERT's advisories page lists 31 advisories that in some way mention Perl. It has 2 for C#, 13 for Visual Basic, 56 for IIS, and 65 for Apache. Guess what? Nearly all of the Perl mentions are example exploits written in Perl of security issues in other projects. So you're seeing far fewer security advisories for your language than for the platform you'll be using to serve it. That should give some perspective.
.NET is not a convenient search term for CERT's database. Over at SecurityFocus, on the search by vendor page http://www.securityfocus.com/bid, Microsoft's .NET framework has 16 vulnerabilities listed as far back as 2002, with only two marked as 'retired'. To be fair, many of these only list past versions, but still have not been retired. Some of them are as new as July. Perl 5.8.0 from the perl5porters has 0.
On the BugTraq archive, I currently see no reference to Perl in the most recent five pages. PHP is the only language I noticed, with 5 vulnerabilities listed on page 1. The Linux kernel, vim, emacs, tar, OpenBSD, VMWare, Kerberos, postfix, and Thunderbird make the five most recent pages. Again, your programming language of choice has better numbers than the platform you'd use to host the code.
| [reply] |
Re: How to answer "Perl is not secure" objections?
by Joost (Canon) on Sep 06, 2007 at 18:29 UTC
|
'Perl has bindings into OS calls that bypass OS security'.
The only way I can read that is as "our OS is insecure".
Either there are legitimate bindings in the OS to bypass normal security for good reasons, and those hooks have the usual protection (i.e. you need to be root / of a specific group to call them), or there are hooks in the OS that just break security and it doesn't matter what language you're using - you could probably break them using a shell script.
| [reply] |
|
|
'Perl has bindings into OS calls that bypass OS security'.
The only way I can read that is as "our OS is insecure".
Quite. For instance, I wrote BSD::Sysctl, a module to allow you to manipulate FreeBSD sysctl kernel variables. If you're an ordinary user, you can only read the values. If you try to set a value... nothing happens (apart from an error condition returned by the kernel system call).
You have to have superuser privileges in order to change a variable. So if you're already root, everything becomes insecure!.
I'm sure if someone figured out how to set sysctl variables as an ordinary user in Perl, that the technique used would be completely language-independent (that is, the result of an exposed flaw in the OS).
• another intruder with the mooring in the heart of the Perl
| [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in. |
Re: How to answer "Perl is not secure" objections?
by starX (Chaplain) on Sep 06, 2007 at 18:19 UTC
|
| [reply] |
|
|
I agree about discovering the source of the myth but I disagree with your approach. It would be much better to have his managers ask the question -- they will be much more familiar with Manager^3 and doing it that way avoids going over anyone's head.
| [reply] |
|
|
| [reply] |
|
|
Aye that's where the ugly bits and pieces of company and office politics rear their monstrous heads.
CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James
| [reply] |
Re: How to answer "Perl is not secure" objections?
by mr_mischief (Monsignor) on Sep 07, 2007 at 18:13 UTC
|
| [reply] |
|
|
Thanks for the NSA reference! I casually mentioned it in a meeting where Manager^3 was present, and I think that nugget may have sealed the deal and kept us from tanking a successful project. Thank you so much!
Updates:
- 20070912 : tanking, not "taking". Whoops. ;-)
<–radiant.matrix–>
Ramblings and references
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet
| [reply] |
Re: How to answer "Perl is not secure" objections?
by kwaping (Priest) on Sep 06, 2007 at 18:51 UTC
|
| [reply] |
|
|
Of course, large projects should never be run setuid anyway. Any setuid program in any language should be as small as possible, do as little as needs to be done setuid, then hand off to non-setuid executables.
| [reply] |
|
|
Regardless of the problems that running SUID programs (and SUID interpreted scripts in particular) can cause, note that you need to have root permissions in order to make anything SUID root.
I might as well claim that all languages are insecure because I could code something destructive and run it using sudo.
These kinds of issues should, for the most part, be solved by using sane system administrator (to make the policies) and a sane OS (to enforce the policies).
| [reply]
[d/l] |
|
|
Re: How to answer "Perl is not secure" objections?
by zentara (Archbishop) on Sep 06, 2007 at 20:17 UTC
|
because 'Perl has bindings into OS calls that bypass OS security'.I would press him to prove that point. It sounds like he is on a weak OS (Windows :-) ), that uses "voluntary cooperation" to maintain security.
Maybe he is thinking of a "limited cgi runtime environment plugin" like Java has. I wish Perl could get a Browser plugin like Java's. That is about the only disadvantage that Perl has. I'm seeing alot of pages with dynamic graphing apps, using the Java Browser Plugin. Then again, a combination of a perl cgi and flash animation is about as good as Java's plugin.
| [reply] |
|
|
Java on the server side usually doesn't have the same kind of sandboxing as Java on the browser, so you have a good point but the comparison for server-side work may not hold. I've often wished I could use Perl on the user's browser rather than JavaScript, ActionScript, or HaXe. One thing that might be nice is if we could have a Perl to Flash compiler similar to what HaXe has.
As for securing Perl more on the server, a perl with a small default @INC can be done easily enough. There are taint mode and Safe.pm to help with boxing in data and code. The installed modules could be kept minimal. Perl supports chroot (although only root can do that).
It should be possible (I'm not saying 'easy') to run both Apache and perl (or Apache with mod_perl) chrooted in the first place if security is at such a high priority. That's a pretty language-independent way to help with security. Things such as ulimit and a good IDS help no matter the language, too.
One thing to keep in mind is that the ability of the programmer to do something doesn't mean it's possible for the site's end user. Any system written in any language which does stupid things with end-user data poses a security risk, no matter the sandbox restrictions. XSS proves the server itself doesn't even have to be vulnerable to cause a security issue -- it can create a security issue for the user even if it is entirely protected.
| [reply] |
|
|
While we are on the subject, of a "Perl browser plugin" , like the libjavaplugin_oji.so in our browser's plugin directory; what has stopped the Perl developers from doing this? From my limited understanding, the java plugin is just a java interpreter with the functions which pose a security risk removed, leaving only simple computational and display functions, and which limits display in the parent's (browser's) allocated window.When I build Perl, I see the mini and micro Perl interpreters, which are limited versions. Would it be that hard to modify those to be a secure browser plugin? Then maybe add a chopped-down Tk or Gtk2 display engine to it? Now I wish I studied c in more depth. :-)
| [reply] |
|
|
Re: How to answer "Perl is not secure" objections?
by perlhaq (Scribe) on Sep 06, 2007 at 22:02 UTC
|
Perl is installed by default on OpenBSD (i.e., in the base system, not as a port or package). Perhaps you can add this as a bullet item on your list... | [reply] |
|
|
Granted, this is arguing from authority, but if something's secure enough for Theo de Raadt, just how insecure can it be? He is not known for a relaxed attitude about this.
| [reply] |
Re: How to answer "Perl is not secure" objections?
by derby (Abbot) on Sep 06, 2007 at 21:30 UTC
|
Hmmmm ... I think public ridicule and humiliation are your best bet. I would suggest setting up a fake blog that describes a similar situation (make sure you date it for about two or three years ago). Seed it with a bunch of comments that don't specifically answer the red-herring question of security but answers that ridicule the question. Once you have that up and running, submit it to digg or reddit and have your friends and coworkers upvote it. Once it's on the front page, just casually mention to manager and manager^2 what you've found during your *research*. Hopefully that will flow up (or down) and manager^3 will see the question as pretty irrelevant.
Okay ... it's either that or just tell manager^3 you think his question is silly -- you want a new job anyways.
Update: Just humor people ... I think perrin's answer is probably the best so far.
| [reply] |
Re: How to answer "Perl is not secure" objections?
by tirwhan (Abbot) on Sep 07, 2007 at 00:13 UTC
|
'Perl has bindings into OS calls that bypass OS security'
That sentence makes no sense at all. The 'bindings' Perl has to 'OS call's (read: system calls) are subject to all the normal security restrictions the OS imposes. Regardless of whether you program in Shell, Perl, Java, C or whatever (well, perhaps not Logo), you will be able to access these system calls, subject to the OS's restrictions. So it all comes down to the question of "is your OS secure" and has nothing at all to do with the programming language chosen.
| [reply]
[d/l] |
|
|
| [reply] |
Re: How to answer "Perl is not secure" objections?
by moritz (Cardinal) on Sep 07, 2007 at 12:02 UTC
|
You have to distinguish between perl (the compiler/interpreter) and Perl (the language).
As for the program, I'd like to point you to the Common Vulnerabilities and Exposures List, search for Products -> Perl (don't enter 'perl' in the search box, it will find 'properly' as well).
Now compare these results to other interpreters and virtual maschines.
As for the language: you don't have to mess with your memory on your own (like C), you have tainting, no insecure register_globals (or whatever that stuff is called in PHP).
| [reply] |
|
|
| [reply] |
Re: How to answer "Perl is not secure" objections?
by dk (Chaplain) on Sep 07, 2007 at 08:04 UTC
|
I'd say this is a matter of trust. If manager^3 trusts other peoples' opinions more than of his own perl guru, well, anything you dig up is doomed not to be weighed anyway. Also, seeking an article that specifically debunks an arbirtatry remark about anything (in your case, about Perl's insecurity), I think, is not really a sufficient strategy by itself, because "fools ask questions that wise men cannot answer".
Following this, if I'd be confronted with "Perl is insecure" I'd answer "this is not true" without further explanations; if the other side would be then interested in a dialog, then definitely articles, examples, and documentations can be discussed. Or, simply put, now you are prepared to discuss articles with a reasonable person, and I'm saying that it might not necessarily be so. | [reply] |
Re: How to answer "Perl is not secure" objections?
by lyklev (Pilgrim) on Sep 06, 2007 at 21:47 UTC
|
There is some truth in the manager^3's fear: if you are running Perl through mod_perl on apache without any security in mind, the application runs with the privileges of the web server. If that is root, you have a problem.
As far as I remember though, Red Hat locked apache down by changing to some "nobody/nogroup" user after starting. If it is RH Enterprise 4 or later, SELinux might be used to further lock down the server. To such an extent that it might be a pain to get mod_perl running at all.
The bottom line is that mod_perl can be a security hole if the system has bad administration. With good administration (chroot, changing user/group after startup), mod_perl can be perfectly secure. It can never bypass OS security, but it can use the permissions it was granted. | [reply] |
|
|
the application runs with the privileges of the web server. If that is root, you have a problem.
No, you have two problems - the first of which is solved by firing your system administrator.
Red Hat locked apache down by changing to some "nobody/nogroup"
No, apache has done that from (very nearly if not) the start. Various distributions will change the username and/or group, but the net effect is that apache needs to be launched as root to bind to a privileged port (< 1024) and then drops privileges to as unprivileged a user as possible.
--chargrill
s**lil*; $*=join'',sort split q**; s;.*;grr; &&s+(.(.)).+$2$1+; $; =
qq-$_-;s,.*,ahc,;$,.=chop for split q,,,reverse;print for($,,$;,$*,$/)
| [reply]
[d/l] |
Re: How to answer "Perl is not secure" objections?
by runrig (Abbot) on Sep 07, 2007 at 00:18 UTC
|
M^3: Perl has bindings into OS calls that bypass OS security
radiantmatrix: Name one.
| [reply] |
Re: How to answer "Perl is not secure" objections?
by Anonymous Monk on Sep 06, 2007 at 23:36 UTC
|
Hi radiantmatrix,
manager^2 and manager^3 are squaring and cubing the 'r' respectively. I think you meant:
(manager)^2 and (manager)^3
The lone manager is understood to have an exponent of 1.
;-D
~DigitalKitty
Too lazy to log in.
| [reply]
[d/l]
[select] |
|
|
How does the xor operator result in exponentiation? Did you mean ** instead??
:-P
| [reply] |
|
|
| [reply]
[d/l] |
Re: How to answer "Perl is not secure" objections?
by pajout (Curate) on Sep 07, 2007 at 11:30 UTC
|
My experience is that the crucial point of security is quality of code. The programming language can only slightly help, but cannot guarantee some reasonable security.
From my perspective, why m^3 does not specify the security requirements of particular applications? It would spare his time when he will not concentrate on technical specialities, for instance, programming language...
| [reply] |