in reply to The "Perl Security Problem"?

It's not a Perl problem, it's a printf problem. Same would happen in C if used in teh same way by allowing users to provide the format string (or part of it) to a printf. It comes down to hysteria over a programming bug in a specific piece of software. It is not a Perl bug at all, just a fault in the way Perl was used.

The bug allows a user to provide the equivelent of:

printf "%999999d";

which can take a while and use a bunch of memory, even if it doesn't crash the system.

Update:

My initial reaction was to inflamatory retoric in the press surounding statements such as: "If remote code execution is successful, it would lead to a full remote root compromise in a standard configuration". While it is true that an attack is possible in principle that could result in such exploitation, in practice such an attack path is so tricky to exploit that the risk is very low.

The efix wrap problem is already being fixed (see advisories here for example). That reduces the chances of a code execution exploit, but doesn't fix the DoS attack which is dead easy to access - only improved Perl coding can fix that.

At the end of the day any sufficently powerfull system is capable of giving you a very red face. Anyone care to say that Perl isn't a "sufficiently powerfull system"?


DWIM is Perl's answer to Gödel

Replies are listed 'Best First'.
Re^2: The "Perl Security Problem"?
by dave_the_m (Monsignor) on Dec 08, 2005 at 11:38 UTC
    No, there is a bug in perl involving %n and wrapped-around integers that in theory allows buffer overrruns and execution of arbitrary code. Of course this is only exploitable if (like Webmin), a network or setuid program is stupid enough to allow the user to specify the 1st arg to printf

    Dave.

Re^2: The "Perl Security Problem"?
by Perl Mouse (Chaplain) on Dec 08, 2005 at 12:28 UTC
    No. If Perl would not have the problem, then the problem in webmin would be as "innocent" as you describe above.

    However, the fault in the code of webmin (allowing untrusted users to supply the first argument to (s)printf) is much more serious due to the possibility of exploiting a buffer overrun/integer truncation error in Perl.

    There is a bug in Perl, and it is good that it is addressed. It's very unprofessional, and IMO, bad for the name of Perl, to not look at this seriously and instantly dismiss it as "not a Perl problem".

    Luckely, people on p5p aren't the zealots like you find here, and there they did look further. The result, no false claims being made, and a serious bug getting fixed.

    Perl --((8:>*