Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Perl Security Testing

by zentara (Archbishop)
on Jul 24, 2017 at 14:02 UTC ( #1195867=perlmeditation: print w/replies, xml ) Need Help??

Hi, the Test Driven Development, for software and for pancakes node interested me, and I went off on a tangent from talexb's original meditation. So I post a new meditation, with my reply as a starter.

Original reply: ##########################

I'm a total amateur compared to you fellows, but I do find when I write my code, for the first draft, I almost always print out arrays and variables after everytime I use them. I almost always get things wrong the first time thru, so my method is very helpful to me.

It's my guess is that the reason TDD failed is that the Test that you didn't account for, is the one that causes the bug, ( if any).

What is more worring to me is the security vulnerabilities which Perl5 is susceptible to.

For instance, could a normal or guest user on your machine, with access to Perl scripts, cause a buffer-overflow of some sort, and gain root access? I'm sure the NSA would pay for that information. :-)

How safe is Perl out there in the wild? Are systems being hacked thru Perl? As far as know, Perl has been very safe in my limited use. I guess security is the number one test.

So what do you experts feel, know, and or are hiding concerning Perl's security, assuming the scripts are written and run correctly? Was there ever a real buffer overflow exploit? etc

Should I worry about other users on my linux box getting root escalation if I let them login?


I'm not really a human, but I play one on earth. ..... an animated JAPH

Replies are listed 'Best First'.
Re: Perl Security Testing
by karlgoethebier (Prior) on Jul 24, 2017 at 18:34 UTC
    "...a normal or guest user on your machine, with access to Perl scripts..."

    My 2 ˘: A guest/user with access to my machine was considered as a severe security risk in the company i was with. It was strictly verboten. We were advised to log out always. No open terminals with root access, no papers with passwords on the desk etc. Many attacks etc. are internal. Not a Perl problem. But in daily business things look a bit different. It's not very convenient to be so strict. And that's the real problem.

    Best regards, Karl

    «The Crux of the Biscuit is the Apostrophe»

    perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

      Social engineering is almost(?) always the greatest risk. At my last workplace we were required to close the door on someone behind us, no matter how close, so they would have to use their own key card to get in. It is VERY HARD to close the door in the face of a fellow employee you know even though they might have been fired that morning for all you know.

        It is VERY HARD to close the door in the face of a fellow employee you know even though they might have been fired that morning for all you know.

        Yes, it is very hard. Where I'm, now, even the head of security sometimes holds the door for fellow employees.

        One place I used to work had revolving doors so only one person per card "swipe" could get through.

        (There was also a door for handicap access at the main entrance. It was activated by the security guard.)

        We had the same problem when they tried implementing that policy at my $job--. Management "solved" the problem by installing what they called "fast lanes" that all the employees had various alternate derogatory names for instead (they were anything but fast). The lanes were basically a sensor for your badge, two glass panels that met in the center and slid open left and right when a badge was scanned, and motion sensors to make sure only one person walked through. The problem was the sensor would get it wrong all the time, people would frequently have to do things like push equipment carts through (setting off alarms), and you could only scan in if you weren't logged as inside any company building and scan out if you were inside THAT building. Massive problems all the time, alarms always going off, if security wasn't present such as anytime after 5:00 there was no way to get in a building if the system wasn't working (as if people weren't already upset about working late).

        One day when the entire system had crashed (that happened quite a bit), there was a blue screen of death on the LCD on top of the badge scanner noting that it was running Windows CE. All the Software Engineers who had experience doing embedded projects based on both Linux and Windows CE for the company of course had a good laugh saying things like, "well, that's your problem right there." My immediate manager at the time, who was awesome, jokingly said things like, "I wonder which executive's brother-in-law owns the company that does these fast lane things," and, "I'm pretty sure this 'security' talk is all a ruse and they are just starting to log lists of all the employees who dare to not work a 45+ hour work week every week."

        On the plus side, a few of us did become pretty good friends with one of the security people, who after you got a beer or two in him would lament that, "yep, my job is pretty much ridiculous... but hey, if this is what somebody wants to pay me for."

        Just another Perl hooker - My customers appreciate that I keep my code clean but my comments dirty.

        Just pretend its a bathroom door

        Also report the guy to OSHA guy, walking face first is dangerous

Re: Perl Security Testing
by marto (Bishop) on Jul 25, 2017 at 14:15 UTC
Re: Perl Security Testing
by Anonymous Monk on Jul 24, 2017 at 19:23 UTC
    Bugs in perl are only a security problem if you have a Perl program running with elevated privileges. One way of doing that is with setuid, but suidperl has a rocky security history and seems not to be used very much any more. Another way is if you allow users to run Perl scripts with sudo.

      …This is a strange answer and on its face seems quite wrong. Bugs in Perl could be serious problems regardless of privileges unless one takes the most pedantic and unlikely view where a DB security hole isn’t a problem since no user has permission to update the DB. Even then, there have been bugs now and then that allow trivial DoS and such. Having a site like Amazon.com down for 1 minute is millions of dollars. That is a huge problem.

        Yes, I suppose I shouldn't have assumed you would read the rest of the thread for context. If you are going to give someone shell access, there are a million ways they could DoS you, so don't give people shell accounts on an important server. But that doesn't have anything to do with perl bugs.

        Not entirely sure where you're going with the DB thing. If you have a Perl program that mediates access to a database that's not accessible any other way, then yes, a perl bug could compromise your database. But in that situation, the program has "elevated privileges" in a sense, even if that isn't implemented with OS-level permissions.

        a site

        What "a site"?

        One name is not one "a site"

Re: Perl Security Testing
by sundialsvc4 (Abbot) on Jul 25, 2017 at 13:23 UTC

    My attitude toward programming languages is more or less the same as my attitude towards chain saws:   respect the tool, but don’t be afraid of it.   (And, if you are not absolutely certain of what you are doing with the thing ... don’t.)

    You should always be careful to keep the operating system (and language processor) up-to-date, applying all security-related patches as soon as they become available, and you should be aware of any CVE postings that might relate to particular things that your programs set out to do.   But beyond that, there is nothing magical about Perl nor any other programming-language tool, and nothing intrinsically dangerous about it.   If an un-patched vulnerability exists, any language can be used to attempt to exploit it.

    As others have quite-rightly said, the greatest vulnerability to any computer system lies between two ears.   Hire trustworthy people, after performing background checks (don’t assume!), pay them well, and construct good software-development workflows according to best practice.   Include formal and pro-active testing into the development process, with engineers continuously testing one another’s work.   Practice the “principle of least privilege,” with developer accounts that cannot issue commands such as (Unix/Linux) sudo.   And, so on.

        Just keep down-voting, mein enemy.   Just keep down-voting.

        (Maybe “the usual seven” could write a short Perl script to query all 4,329 of my posts so-far, and, if all of you ran this script to down-vote every single one of my posts, then maybe you will finally succeed in down-voting me completely off the island ...   Woo, hoo!)

        Otherwise, please listen up . . .

        Otherwise, I stand behind my original comments without further comment.   The OP knows little about security, is blanched by the number of CVE reports that have been logged with regards to Perl, and really does want information and assurance.   Not too much of interest has so-far been said in this thread, hence my comment.   First, that there is nothing particularly special ... nor, categorically “vulnerable,” about Perl.   And, that most interesting exploitable-things occur at the operating system level, not the application.   Merely overflowing a buffer will not get you root, and so on.

        And, in my second paragraph, underscoring the human(!) factor.   It has usually been my experience over these many, many years ... and, believe it or not, it’s getting close to forty ... that security breaches which were initially ascribed to “external” sources, almost always turned out to be “internal.”   My client-before-this also had the experience of realizing ex post facto that he had unwittingly hired a convicted felon on probation.

        I will also, incidentally, stand behind all of my previous, cited by you, posts, as well.   Not the way that you would have responded to the same thread?   Goody for you.   There is(!) “more than one way to do™” a great many things in this world – including, replying to a thread.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://1195867]
Approved by herveus
Front-paged by Discipulus
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (9)
As of 2017-10-19 07:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My fridge is mostly full of:

















    Results (252 votes). Check out past polls.

    Notices?