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"?
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: The "Perl Security Problem"?
by dave_the_m (Monsignor) on Dec 08, 2005 at 11:38 UTC | |
|
Re^2: The "Perl Security Problem"?
by Perl Mouse (Chaplain) on Dec 08, 2005 at 12:28 UTC |