Re: Is it possible to modify __DATA__ via the DATA file handle or otherwise?

[ikegami]

DATA is a plain, ordinary file handle to the source file, but it's open for reading (not writing). I don't know how to convert a handle opened for reading into a handle opened for writing (if it's even possible), but you can open a new handle to the current file, and use tell(DATA) to find the location of the start of the data.

die("Not safe for setuid") if ${^TAINT};

open(my $fh, ">>", __FILE__)
   or die("open: $!\n");

( my $data_pos = tell(DATA) ) >= 0
   or die("tell: $!\n");

truncate($fh, $data_pos)
   or die("truncate: $!\n");

say($fh "bar")
   or die("say: $!\n");

__DATA__
foo

[LanX]

Pretty much what I had in mind, but to avoid race conditions due to parallel starts, I'd rather write to a temporary file and rename it at the end.

[haukex]

I'd rather write to a temporary file and rename it at the end

Good thing I wrote a module for that ;-)

use warnings;
use strict;
use File::Replace 'replace2';

my ($infh,$outfh) = replace2(__FILE__);
while (<$infh>) {
    last if /^__DATA__$/;
    print $outfh $_;
}
print $outfh "__DATA__\n";
print $outfh "New stuff! ".gmtime." UTC\n";
close $infh;
close $outfh;

[LanX]

Still using the tell of the DATA filehandle is the far better approach.

There is no guaranty to correctly match __DATA__ without having a full Perl parser.

[ikegami]

Or use a locking mechanism (e.g. flock).

[YenForYang]

Sorry for this dumb question, but I was wondering what/why the first line (die ...) is used (for).

[ikegami]

setuid allows a user to execute a script as the script's owner.

I believe it can be attacked as follows:

1. Create a symbolic link to the setuid script.
2. Execute the setuid script via that symbolic link.
3. Immediately replace the symbolic link with a file.
4. If you get the timing right, the setuid script will read and write the data from your file instead of from the script file. The script trusts the data since it expects to be the only one able to change it, but you actually have full access to the data.

As a variation of the above, the attack could also replace the volume on which the script resides by unmounting it and mounting a new one.