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

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??

We can eliminate the DBIspy threat by copying in the text of the DBI::connect sub to the caller program:

sub DBI::connect { # code from original DBI::connect }

Yes, sure. And I can read it from the script to be executed and look for functions called from the copied DBI::connect. Most trivially, the next function to attack would be the DBD's connect method. A few lines of code should be sufficient to load and patch the DBD before the script starts, very similar to my DBIspy hack.

This of course would have to be updated manually if a new version of DBI was installed.

So you are creating a maintainance nightmare here, for little or no gain.

And, we can assume that the module is write-protected from all except root.

Only if you use the system perl or a local perl installed by root. It won't be protected if perl is installed by the user running the script.

(We can assume root is not compromised).

Now, that's a very bold statement.

With physical access to the machine, root is compromised within minutes on a standard installation of many Linux distributions. Simply because the boot loader does not prevent me from temporarily adding init=/bin/sh rw to the kernel's command line. After that, I have a root shell without a password prompt and can modify any file on the system. Or, I could reboot and run my own Linux from a CD or a USB stick to modify any file on the system. (So yes, you should prevent physical access, add BIOS and boot loader passwords, and encrypt all disks, if secret data is stored on a machine.)

Without physical access, there are still many ways to get root access. Linux has security problems, like any other system. To make things worse, CPU bugs like Meltdown und Spectre hardware bugs can help gaining root access.

But luckily, I don't need root access.

Also, instead of the inode we can use checksums.

Yes, but they won't help you against LD_PRELOAD. The perl script is unmodified, but I will still get the secret.

Heck, I could even break checksum tests from within perl, with a perl loader script that has the following behaviour:

  1. Create a backup copy of, including a-time and m-time (lstat).
  2. Completely replace the content of with an attack script.
  3. exec("",@ARGV), running the attack script.

The attack script does the following:

  1. Restore content from the backup copy. Note: at this point, perl has completely read the attack script from and no longer cares about the content of
  2. Restore the original a-time and m-time of (utime). Now, looks sane and unmodified again, and it is. It will pass any checksum test. But perl is running my attack code.
  3. Remove the backup copy.
  4. Run any code from required to execute secret-keeper (e.g. set up environment variables, file handles, ...)
  5. Run the unmodified, secret-revealing binary, and print out the secret revealed: print qx(./secret-keeper);

secret-keeper has no chance to detect that attack. My loader script is no longer running. Its last action, exec(""), removed all traces from memory. It will look like was started directly by my shell.'s inode and content seem to be unmodified. This is also true for any module might load. Whatever action the original did before running secret-keeper, my attack script has done the same in the fourth step.


Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

In reply to Re^3: Hide DBI password in scripts by afoken
in thread Hide DBI password in scripts by danielgr

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?

What's my password?
Create A New User
Domain Nodelet?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (6)
As of 2023-12-05 21:52 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (29 votes). Check out past polls.