Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

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 (Abbot) 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 (Cardinal) 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 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"

A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://1195867]
Approved by herveus
Front-paged by Discipulus
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chanting in the Monastery: (4)
As of 2023-11-28 19:35 GMT
Find Nodes?
    Voting Booth?

    No recent polls found