Is this a core Perl flaw?

sigzero on 2005-11-30T02:23:55

Is this a flaw in Perl or the way Webmin was coded?

sprint formats inputs and taint

n1vux on 2005-11-30T03:18:59

Using values from web-form input in a qx{ sprintf "blah %s blah", $input } without taint checking the $input first is not safe, never was, never should have been considered safe. If someone ever said "it's only a way to crash the program, no way to break in here", they were not listening to history. Running system commands with user input is always going to be a target of opportunity, you have to defend that in depth. You've got to check for buffer overrun (even if you can't see the buffer ) and ;'s and all that other good stuff -- allow the reasonable things only, don't try to check for each attack!

If Webmin does this, that's bad. But that does Not make it Perl's fault, Perl has Taint mode, tried to deal with this sort of bad behavior more than any other language. (Java tried some sandbox rules, similar to Perl's safe opcodes module, but Java didn't go so far as to taint the variables to try to force type-checking of inputs before use.)

Since webmin runs as (or can run as) the Apache or other administrator, it must be protected as a security critical resource. It should be paranoid about its inputs.

Re:

Aristotle on 2005-11-30T07:50:50

I think what’s happening is that they’re doing something like this:

printf "%${precision}d", $somenumber;

where $precision derives from user input. This exposes Perl code to all the same format string vulnerabilities that have commonly been found in C code. I’ve been pointing this out for a while now. I’m surprised that not more people have picked up on it.

The right way to write that code, in the general case, is like so:

$precision =~ s/%/%%/g; printf "%${precision}d", $somenumber;

or, in this particular case, like so:

printf "%*d", $precision, $somenumber;

The key is never to interpolate user input into format strings without first escaping percent signs.

Re:

jhi on 2005-11-30T11:32:50
> I’ve been pointing this out for a while now. I’m surprised that not more people have picked up on it.

So I assume that you have long since reported this through perlbug and/or perl5-porters and since it's a security flaw also contacted the branch maintainers (Rafael and Nicholas) directly?

Re:

sigzero on 2005-11-30T13:39:14

I think what he is saying is that it isn't a *core* Perl flaw but a flaw in programming methodology.

Core perl or methodology?

n1vux on 2005-12-03T17:12:43
Well, let's say it's both. Perl could have been more paranoid, C lib could be more paranoid, Perl script authors should be more paranoid. Unclear but I suspect this bug is only usable when Taint mode should have been wasn't? MaintPerl already has patch 26420 http://www.nntp.perl.org/group/perl.perl5.changes/14020 , so Perl is now a bit more paranoid. The Ubuntu security team reports the problem as follows. Also patched in FC4 security updates and FC3 backport. Somewhere along the line the CVE# got typo'd, 3912 vs 3962, which may someday be assigned to something else.

Ubuntu Security Notice USN-222-1 December 02, 2005
perl vulnerability
CVE-2005-3962 [typo: should be 3912 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3912
A security issue affects the following Ubuntu releases:
Ubuntu 4.10 (Warty Warthog)
Ubuntu 5.04 (Hoary Hedgehog)
Ubuntu 5.10 (Breezy Badger)
The following packages are affected:
perl-base
The problem can be corrected by upgrading the affected package to version 5.8.4-2ubuntu0.5 (for Ubuntu 4.10), 5.8.4-6ubuntu1.1 (for Ubuntu 5.04), or 5.8.7-5ubuntu1.1 (for Ubuntu 5.10). In general, a standard system upgrade is sufficient to effect the necessary changes.
Details follow:
Jack Louis of Dyad Security discovered that Perl did not sufficiently check the explicit length argument in format strings. Specially crafted format strings with overly large length arguments led to a crash of the Perl interpreter or even to execution of arbitrary attacker-defined code with the privileges of the user running the Perl program.
However, this attack was only possible in insecure Perl programs which use variables with user-defined values in string interpolations without checking their validity.

Re:

Aristotle on 2005-11-30T15:08:32

Huh? Should I also report the fact that open FH, $foo can be used for mischief if $foo derives from user input?

And this isn’t even as openly dangerous.

Cursory experimentation and a superficial browsing of the source suggests it’s not possible to corrupt perl’s stack using printf, so this isn’t a vulnerability in perl. It is very well possible to inject unexpected %ns into the format string to make an application fall over, though, so it definitely constitutes a vulnerability in Perl code. Whether the vulnerability can be used for arbitrary code injection will depend on the application.

So no, it doesn’t seem like something I should report to p5p.

Re: Format

n1vux on 2005-11-30T15:44:35
Oh, varargs , even worse than usual buffer stuff, Ouch. Thanks for the wikipedia link!
I can see where prepping the stack for a varargs hack could be hard but not impossible with only a web client to work with.
Escaping or removing all relevant magic characters e.g., % is only one of the things one must do with user input before using it. Verifying syntax is as expected and size isn't absurd is also required for safety. (Some semantic checks may even be required to protect the backend from GIGO attacks, but that's beyond this scope.) Removing all characters you don't expect is often easier and usually safer than trying to escape everything that might matter at this or next layer -- or just rejecting immediately but politely any query with nonsense characters.

Re: format strings

n1vux on 2005-12-11T02:49:49
Full details are on the front page now, P5P http://use.perl.org/article.pl?sid=05/12/06/1353226&mode=nocomment&tid=12.