`chr()` loses tainting

[leonerd]

While in practice it's hard to see how to use this as an exploit, nonetheless it remains the case that the chr() core op loses tainting of its value, whereas symmetrically ord() preserves it.

$ perl -T -MTaint::Util -E 'taint my $c = "0"; my $n = ord $c; say "ord() TAINTED" if tainted $n'
ord() TAINTED

But

$ perl -T -MTaint::Util -E 'taint my $n = 48; my $c = chr $n; say "chr() TAINTED" if tainted $c'

no output.

This fact is not mentioned in perlsec nor in perldoc -f chr.

I express no opinion on whether this is a bug in chr() that needs fixing, or simply a note needs adding to the documentation somewhere to explain that this is the case.

[Ovid]

The only exploit I could see is someone sending a stream of numbers, getting them converted to characters, and having that evaled. Unlikely, but not impossible? Seems like chr should be tainted out of an abundance of caution.

Edit: or used as a filename, or many other use cases. I wasn't thinking this through, which, I suppose, it what black hats want.

[iabyn]

On Tue, Apr 23, 2024 at 07:42:52AM -0700, Paul Evans wrote:

I express no opinion on whether this is a bug in chr() that needs fixing, or simply a note needs adding to the documentation somewhere to explain that this is the case.

Smells like a bug to me.

-- Fire extinguisher (n) a device for holding open fire doors.

[khwilliamson]

I agree with @iabyn