Perl has a potential buffer overflow problem. So does C, and in my opinion, any language based on C.
Those are two different problems! C, on the language level, doesn't have a buffer overflow problem - it doesn't have anything to overrun. However, given the standard libraries, it's very easy to create programs written in C that have a buffer overflow problem.
In Perl, it's quite the opposite. It's very hard to write a program in Perl that has a buffer overflow problem - because Perl hides all the details that can lead to a buffer overflow problem for you. However, Perl needs perl to be able to run. And perl, being written in C, can suffer from a buffer overflow problem.
My major complaint with the line of thinking in this article -- that security should be built in at a fairly high level (and Perl is a high level language) -- is that it, by inference, absolves the O/S of responsibility for not permitting buffer overflows to cause problems. My experience on various flavors of MVS and VM was that any attempt by an application program to access memory outside of its data allocation resulted in immediate termination; data could not be executed as "code" nor could somebody else's memory be accessed.
Careful here. With languages like Perl, you cannot shift all the responsibility to the OS. Remember that for the OS, the entire Perl program is 'data'. Nothing of it is 'code', the only 'code' the OS knows is perl. With a language that runs on a VM, you can go wrong twice. You can have a buffer overflow in the implementation of the VM (as in the recently discovered bug) - here the OS could have a role in preventing exploits. However, the architecture of the VM itself may allow a buffer overflow, making it possible for an attacker to execute arbitrary code within the VM. It won't violate any rules the OS is upholding, but it can be as damaging to your system.
| [reply] |
I don't know the guts of the MVS or VM implementations of Perl. From my memory of working on these systems, I believe a Perl program would be run as a user process. As such, the user's Perl program would be data to the Perl interpreter, and the memory used to store the variables would be distinct from the memory used to store the instructions generated from the user's program. Both would be distinct from the perl interpreter, itself. Buffer overflow would almost certainly cause the user's process to be immediately aborted with the dreaded 0C4 error, which was, if I remember, not catchable: control would absolutely not be returned to the application.
added in update The VM to which I'm referring is IBM's mainframe OS.
| [reply] |