Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re^3: Authentication with /etc/shadow

by ELISHEVA (Prior)
on Feb 27, 2011 at 10:08 UTC ( #890392=note: print w/ replies, xml ) Need Help??


in reply to Re^2: Authentication with /etc/shadow
in thread Authentication with /etc/shadow

I can't help feeling there is something fundamentally inconsistent in your reply here and your response to fullermd. I'll grant that you know your client and your situation and you may be limited in your ability to explain your true requirements but... just food for thought.

You write, in reply to fullermd

The main security risk I can see is the possibility of an attacker copying my program (stealing a hard drive or system unit wouldn't work) and running it on his computer to gain access via a hole in the wall...I only need to delay an attacker a few hours and his attack becomes pointless. Though he can steal the program and run on it on his computer I am hoping he is unlikely to clone my users. I want to authenticate my system users with every pass of my program loop and shred my perlapps if any of various conditions

If security is so very important to your client, about the last thing you should be considering is an end-run around PAM. The more places security is defined, the more places changes to security protocols need to be updated, and the more long term problems. Also the more places you need to secure and protect from access. By adding a second authentication mechanism outside of PAM you are in fact increasing the number of potential attack vectors.

Second, modern versions of PAM support some pretty sophisticated user identification mechanisms, including bio-identification. Presumably, if those scripts are run on a personal computer, they have to log in at some point into the sensitive computer. I'm going to assume you are sophisticated enough to never ever put login information in the clear in your scripts, especially in a high security situation.

Why aren't you making your scripts owned by a user who can only be activated with a bio marker? Then it wouldn't matter what computer your would-be attacker ran the program on: when he tried to access the sensitive computer and reached the bio-security check, he'd be stopped dead in his tracks.

Third, if this is really so very important to your client and you really have no option but to run security checks before each and every operation, your client should be willing to provide a box with sufficient memory and CPU to handle the hit rate and security checks.

Forth, if stealing a disk won't work, how is it that these scripts are being stolen or copied in the first place? How is it that merely running the scripts on a personal computer would give someone access? That doesn't sound right at all. Have you considered front-ending the computer with these valuable scripts with a gateway computer that validates the users? Putting these scripts on a secure computer accessible only via the IP of that gateway computer or by an on-site login with bio-id? Limiting the actions those users can take?

Fifth, if your scripts can be stolen or copied, why wouldn't your user base be stolen or cloned? Seems to me that would be a much more direct way of cracking your system. Why wouldn't a serious attacker read your source code? I certainly wouldn't write off a script as not worth reading even if it contained only one line in it. Would you? I hope not. I'm not following your logic when it comes to likely cracker behavior.

Sixth, if security is essential to your client, should you even be using scripts for such sensitive operations? Might it not be wiser for both performance and security reasons to go with a compiled executable? With any scripting solution there is always a risk that an enterprising hacker can intentionally create and take advantage of time gaps between the launching of the Perl interpreter and the loading of your script to change the effective user id or wreck other havoc. If you must use scripts you might want to take a good hard look at the implementation and security checks done by Apache's mod_suexec.

Seventh, I question your logic that a pure Perl script hacking /etc/shadow would in fact be faster. If PAM is doing nothing more than a password check, my first guess is that it would be faster because you are using pre-parsed code compiled into machine code ops. With a script you have to parse and compile it with each run. Even if you are pre-loading modules and using signals or function calls for each user check, you'd still be running Perl OP codes which have to be translated into machine ops rather than machine ops. If PAM is doing more than a simple password check, then you aren't really doing a complete authentication if you by-pass PAM and as soon as your would be hacker figures that out, they'll find a backdoor through the things you aren't checking.

I don't know your situation, but based on what you've shared so far, it seems to me that you are trying to solve a problem with scripting that needs to be solved in a much more systemic way. I think you need to have a very serious talk with your client.


Comment on Re^3: Authentication with /etc/shadow
Re^4: Authentication with /etc/shadow
by fluffyvoidwarrior (Monk) on Feb 27, 2011 at 11:22 UTC
    Thanks. That's a lot to think about.

    One immediate answer to part of your post is that physically stealing something - hard drive or system unit - would be immediately noticed. Copying software would be much harder to prevent in this environment.

    Yes, chunks of it need rewriting as compiled binaries but the client moved the goalposts and wants it running next week - no time

    I have absolutely no objection to using PAM for this but it looked like a lot of overhead so I thought of a quick password hash comparison.

    Protecting user login security is almost irrelevant since unauthorised login is not possible without physical attack and is almost meaningless in this context anyway since many varied people will use this system on the premises with no personal login at all. I am not trying to safeguard that type of security. I am not trying to authenticate user logins, I am trying to detect if my system is running off the premises and prevent or delay it's use.

    One interesting point you made touches exactly on one of my major concerns - "a risk that an enterprising hacker can intentionally create and take advantage of time gaps between the launching of the Perl interpreter and the loading of your script to change the effective user id or wreck other havoc." In an attempt to counter such an approach my program checks it's effective user id on each pass. My assumption was that to crack a perlapp, this would be a likely route. My hope was that for an attacker to take this route the perlapp would have to be run and so would have a chance to fork and render itself useless.

    I am looking for roadblocks and delays in an unusual security context.

    And, sorry, I am aware that there are inconsistencies in what I am telling you. A bit like visiting the doctor and lying about your symptoms. However, your critical input is helpful nevertheless.

      I feel like I'm shooting in the dark here, but ...

      If the particular computer you are running on is an issue, why not check the BIOS serial number and manufacturer id and have your script run only if it is on the correct machine? If buying time is also concern you could generate fake output and even try to silently send an email to supervisors if it running on the wrong machine complete with the CPU info of the interloper so that follow-up actions or even prosecution would be easier. No point in letting the attacker know his/her attack even failed.

      Also do you have in place some sort of digital signing? Can you prevent scripts running if their checksum or digital signature changes? If someone can copy your scripts, might they also not be able to edit them to remove any security checks and delaying tactics you try to insert? If that is the case your EUID check solution (or for that matter a CPU check) isn't a solution at all. If you encapsulate your checks in function calls, Perl makes it dirt easy to redefine a function call. If you hard code your checks in several places in your script, you will be dealing with a maintenance problem. Furthermore, assuming your envisioned attacker is more than your average script kiddie, I'd suspect that he or she would be quite adept at using sed, vi, emacs/emacs, perl or any number of tools to do regex based global search and replace.

        Yes, checksum is a good idea, I'd already decided on hardware checks.

        Also, checking code is kept in the main loop - no function calls - for the reason you suggest and is encountered prior to any sensitive functionality. (also duplicated within the most sensitive function block in a .pm file) If any checks fail the program goes into a blind loop and never encounters the sensitive instructions

        I suppose I am, in the immediate instance, trying to rely on and beef up the limited security value of perlapp executables in order to buy myself some time to develop a better solution. My hope is that a perlapp could not be easily decrypted cold and that it would probably be run to be cracked. When it runs I may be able to get lucky.

        I know it's a less than perfect situation but it's all I've got now, this minute. I can only do the best I can with the tools I've got in the situation I find myself.

        Perl is an unbeatable problem solving and prototyping system. It has solved problems here that I doubt could have been as well done with other languages. The client is well pleased, so pleased they are insisting on going live NOW, with a Perl only setup. They have "Confidence in my ability to safeguard their interests" .... They are non-technical and have more confidence than I do...

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://890392]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (7)
As of 2014-07-23 01:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (131 votes), past polls